Re: [Core GIT] Long-term cherrypicking

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Wed, Sep 21, 2005 at 10:57:04PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> You solved this by 'git cherry' to go
> beyond M, which is a valid workaround, but then the problem
> becomes how to find where to stop.

When forking your branch, record that in a tag. When running git-cherry
with the tag as base, take the earliest cherrypick found and find the
LCA of the two corresponding commits. Reset the tag to that.

> I am assuming the reason this is a cherry-pick problem is
> because S does not necessarily send everything out, and whenever
> S does 'format-patch L' to generate a list of patches, only a
> subset of them is actually sent out.  If that is the case, how
> about maintaining another branch T on the S side, which is
> private to S?

That is not the case, this is a cherry-pick problem since L dropped some
of the patches (if the git's definition of "cherry-pick problem" isn't
something different to what I'd expect)...

> T starts out as the same commit as the head of L.  Whenever S
> has merge-worthy commits, run 'git-cherry-pick' to copy them
> over to T, and 'format-patch L' is run in T, not in S, to
> generate patches to be sent out.
> 
> T being a private tree allows you to rebase every once in a
> while to L [*3*], so that already applied patches are dropped
> from it.

...nevertheless your solution still seems to apply and sounds good to
me, thanks. I wonder why this didn't occur to me. :-) Perhaps it could
be noted in the tutorial?

The disadvantage is that this seems as a lot of work. You have to
explicitly cherry-pick each commit, and the fact that you have a
floating (continuously rebased) tree means that you can conveniently
keep it only on just one machine. [*1*]

The advantage is that it is easy to "forget" commits which were dropped
altogether or applied modified. You could put together some filter and
grep -v, but that's ugly and doesn't scale.

Well, I guess that if you are going to do this all, it really gets
visible that this rebasing stuff is really quite an ugly hack and that
you are probably much better off with something like StGIT. ;-)

> [Footnote]
> 
> *1* I am assuming that merge M would not be made any more
> difficult by having A and A' on both sides.  Is it a problem in
> practice?

That's something Karsten Keil would be more qualified to reply to, but
unfortunately you removed him from the Cc list. ;-)


*1* I find the fast-forward restriction more and more annoying in this
context, actually, and I'm seriously considering dropping it from Cogito
altogether. GIT seems to care a lot about it, but Cogito doesn't so far,
it would only have problems fast-forwarding your master to catch up with
the branch you are merging, trying to do a tree merge instead. But

	if old_ref == master then master = new_ref

would solve that. Can it ever really hurt?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.