Ok, I’m not really git fan. Actually, I don’t like at all… But I have to use because of some projects and now, that GNOME is moving to Git, more.
Anyway, I use it. But there are some workflows I don’t get well yet. I know the basis and maybe a bit more, but I’m far from a git-poweruser.
There are some docs and interesting threads about git in GNOME, but I have to learn a lot…
The thing is I like to collaborate with some project in which official git repos I haven’t account, so I try to use Github to public and manage my branches.
Although I don’t like git so much, I do like Github. It is a very good web gui for a DCVS and has awesome features…
But here is one of my use cases:
I try to make some changes on a Debian project (live-helper) which uses a git repository. But I work with a friend on some features and changes over the main project.
My first though was: I create a mirror of the upstream project on Guthub, my friend create a “fork” (kind of “git clone” but keeping parent-child relationship on Github) and then he can make so many branches he need and develop the different features and changes.
I like to have one branch where merge all the mature features, but also keeping the upstream mirror. So I create a branch of my mirror and I’m merging there the different features.
I think until here everything is right. If there is a better way, tell me, please.
Keep going… The problem is not all the features are interesting for the upstream projects, so the merged branch is not good place for get patches or merge from. But it is our good branch which we use for our project, so we need keep as is.
But some of our features are integrated in upstream. Which is good and thing we want. The problem is we we pull the changes from upstream, there are some changes identical, but merged or committed in other order. Some times pull a changed we push to upstream make some mess in our history…
And if we like to keep updated the different feature branches from upstream to keep working on this features but with valid and new code, from where we pull those changes?
From our mirror? the merged branch? is there another magic git way?
I know this could be very confusing. I think it’s easy to explain with graphics but my artistic skills are below zero…
But this graph could help (or not…)
I hope some git guru understand some of this uses case and give me some tips to doing better.
BTW, I couldn’t find a way to make more than one fork from one branch on Github, which would have been useful…
NOTE: I have my reasons to dislike git, but it’s now the point of this post. I don’t like flames and I don’t like argue about which DCVS is better, I just like to know how to use better this tool. Thanks 🙂
Just to make sure that you know about alternatives:
http://gitorious.org/
http://repo.or.cz/
Just because githubs random 404’s when attempting to download the file as archive or commercial obnoxiousness: http://vadi2.files.wordpress.com/2009/04/screenshot_100618.png can be annoying to your future contributors.
@Vadim: I knew Gitorious already and I think that I saw before repo.or.cz and unless github is not open source it has a huge amount of free software project (or just open piece of code) there.
The thing I like from Github is how easy you can manage your branches, follow people, projects, fork from their projects and still be connectd with the mainline so both (upstream side and downstream side) can know when the other side makes something new and maybe useful for your branch. I didn’t see that in any other repository managment project.
And al my projects and contributions are free software so I have not the problem you pointing out in your screenshot. Anyone can always download, fork, merge, and so on from my branches, even request me to pull some of their changes.
The best thing is this is just with feww clicks, very visual and with a lot of good documentation.
Anyways, Github is just a service and has some issues I don’t like as well, but for me is the best web interface for this kind of systems. But I’m very open to others alternatives.
Loggerhead for Bazaar is pretty good as well, but I miss the easy way of “fork” from a branch and to have a graphical way to do merging, as github have. But at least Loggergead is open and free and is still improving.
My way to do this (from a general DVCS perspective) is to have your upstream mirror, a branch off of that for your change to be pushed and any more branches below that for you to work within. Each set of patches would be in a different branch, using parents to represent dependencies so you don’t have to cherry pick certain patches out when you want to upstream them.
@Vadim: Actually, I didn’t try for awhile Gitorious so I’ve just tried and I got very surprised because there are some many new cool features. I think I’ll give it another chance 🙂
I am not 100% sure I know what you are asking, but I’ll need to rebase all your “topic” branches onto the new upstream, and then remerge them into your master.
Email me if you need some help, it’s much easier to draw diagram in ascii 🙂
Here is my talk on git from last year. It has some diagrams on how git rebase works:
http://excess.org/article/2008/07/ogre-git-tutorial/
@Garth: I think it’s quite similar to what I do, but which parents do you use? the upstream mirror?
What happen when you made modifications over a feature which is not in upstream but in another branch? The parent will be that branch, won’t be?
But then, imagine that you did something in the branch of the branch, the branch with the new feature based in the branch which you didn’t push to upstream and that change you yes like to push to upstream?
Well, maybe this was happen to me because I use a middle branch which has merged the mirror branch with the features I was developing in different branches. But I did that because I need all those features together and I don’t know another way to do that :-/
I meant to say that *you* will have to rebase all your topic branches onto the new upstream.
@bartman: THank you very much. Probably the solution goes that way. I’ll read it your talk and then probably email you to be sure I undertand it well.
I think one of my problems (apart of the English is sometimes hard for me and I miss some concepts) is that I believe I don’t understand well the “rebase” concept…
Thanks again 🙂
The rebase changes the base of your branch, if your topic branch is based on the head (master branch) of the upstream repository when it is “assimilated” and your private branches are all based on top of the topic that was assimilated you will have no problem.
before rebase :
o-o-o-(origin/master)-o-o-o-(master)-o-o-o-(topic)
after 2 rebases:
o-o-o-(origin/master)-o-o-o-(topic)-o-o-o-(master)
after upstream assimilation :
o-o-o-o-o-o-(origin/master)(topic)-o-o-o-(master)
I like http://live.gnome.org/Empathy/Git … I think they do excellent job in explaining real world scenarios well.