From: Junio C Hamano <junkio@cox.net>
Date: Wed, 21 Sep 2005 20:57:04 GMT
Subject: Re: [Core GIT] Long-term cherrypicking
Message-ID: <7vzmq6p2an.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050921164015.GC21971@pasky.or.cz>

Let me see if I understand what you are trying to solve.

S is subsystem line of development, L is Linus line of
development, M is a merge from L into S.

A' and B' are resulting commits from e-mail patch, that contain
changes introduced to S by A and B commits, respectively.

 S:     A - B - C - M - D - ...
      /           /      
 L:  O- X - A'- Y - Z - ...

After sending off patches A and B, L accepts only A and creates
commit A'.  After a while, S pulls from L and merges at M [*1*].
In the meantime, there are other changes on both ends (C and Y).
Also note that I am not drawing commits in S that are not to
be sent to L via e-mail nor pull request -- there may be other
commits on lines between B and C, C and M, etc.

M contains changes B and C which are lacking from L.  On top of
that, a commit D is made and S wants to ask L to incorporate
changes in S but not in L (B, C and D), but finding B, C and D
is cumbersome [*2*].  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.

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?

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.


[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?

*2* Finding B for resend may be debatable -- it is more of an
inter developer communication issue.

*3* For the above workflow to work, I think the current 'git
rebase' needs to be improved much in two aspects.  (1) The
current 'cherry' uses 'git-patch-id' which shares the same
strictness with 'git-apply' and would not tolerate much fuzz
between what you send out and what got actually applied. (2)
'rebase' keeps going when a merge is not cleanly done, noting
them to sort them out by hand at the end.  This loses the order
of commits in the tree being rebased and very unwieldy.  I have
a plan to fix this in the TODO list for some time.