Re: [Core GIT] Long-term cherrypicking
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.
Show 6 quoted lines
> 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)...
Show 8 quoted lines
> 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. ;-)
Show 5 quoted lines
> [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.
Petr Baudis
