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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
