[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <453A6179.1060500@drzeus.cx>
Date: Sat, 21 Oct 2006 20:05:45 +0200
From: Pierre Ossman <drzeus-list@...eus.cx>
To: Linus Torvalds <torvalds@...l.org>
CC: Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists