Messages in this thread | | | Date | Sat, 21 Oct 2006 20:05:45 +0200 | From | Pierre Ossman <> | Subject | Re: Git training wheels for the pimple faced maintainer |
| |
Linus Torvalds wrote: > On Sat, 21 Oct 2006, Pierre Ossman wrote: > >>> HOWEVER! The above obviously only really works correctly if "master" is a >>> strict subset of "for-linus". >>> >> Ah, that's a bit of a gotcha. Any nice tricks to keep track of where you >> where in sync with upstream last? Create a dummy branch/tag perhaps? >> > > You don't need to. Git keeps track of the fork-point, and you can always > get it with > > git merge-base a b > > where "a" and "b" are the two branches. > > HOWEVER. If you have _merged_ since (ie your branch contains merges _from_ > the branch that you are tracking), this will give you the last > merge-point (since that's the last common base), and as such a "diff" from > that point will _ignore_ your changes from before the merge. See? >
This sounds sufficent. My idea was to freeze my outgoing branches (and possible topic branches that are "done"). I would like to keep my development branches up to date though.
In other words, I have a branch "linus" which keeps your current tree. From this I'll fork off branches for things going upstream. Until these have been merged, I won't do any more syncs with "linus". But my development branch will keep moving with the "linus" branch.
If I read your response above and the man page for git-merge-base, it will do the right thing even if "linus" now is further in the future than the point I forked it.
> > (a) work on a "individual commit" level: > > git log -p linus..for-linus > > will show each commit that is in your "for-linus" branch but is _not_ > in your "linus" tracker branch. This does the right thing even in the > presense of merges: it will show the merge commit you did (since that > individual commit is _yours_), but it will not show the commits > merged (since those came from _my_ line of development) > >
Ah, so "git log" will not show the commits that have popped up on "linus" after "for-linus" branched off? Neat. :)
One concern I had was how to find stuff to cherry-pick when doing a stable review.
> Anyway, I hope this clarified the issue. I don't think we've actually had > a lot of problems with these things in practice. None of this is really > "hard", and a lot of it is just getting used to the model. Once you are > comfortable with how git works (and using "gitk" to show history tends to > be a very visual way to see what is going on in the presense of merges), > and get used to working with me, you'll do all of this without even > thinking about it. > > It really just _sounds_ more complicated than it really is. > >
git has a lot of these hidden features and ways of doing less-than-obvious things, so I'm just trying to broaden my repertoire by consulting those who have been using it on a more daily basis.
I am just thankful git has a reset command ;)
Thanks
-- -- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |