Re: git-rebase skips automatically no more needed commits

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

On Fri, 9 Sep 2011, Martin von Zweigbergk wrote:

> On Fri, 9 Sep 2011, Francis Moreau wrote:
> 
> > please let me know when you submitting your work, I'm interested to see it.
> 
> Will do. It's not really that much work [...]

It seems to be a little less straight-forward than I had first
expected.

We want to get all commits in $oldbase..$branch that do not share
patch-id with commits in $oldbase..$newbase. These are the commits
prefixed by '+' in 'git cherry $newbase $branch $oldbase'. However,
just getting the list of commits is not enough, because we currently
don't explicitly provide a list of commits to create patches from, but
instead run something like 'git format-patch --ignore-if-in-upstream
--stdout | git am --rebasing'.

I can see a few different solutions.

 1. Teach git-format-patch a --stdin option that makes it read the
    list of commits from the command line. git-format-patch currently
    itself walks the history, so I'm not sure how such an option
    should interact with current option. The options should probably
    be mutually exclusive.

 2. Somehow modify git-rebase--am.sh not to depend on format-patch. In
    [1], Junio mentions rewriting git-rebase--am.sh "to have
    format-patch avoid the cost of actually generating the patch text"
    and "when using "am" for rebasing we do not really care anything
    but the commit object names". If all we need is the commit name,
    why would we not use cherry-pick/sequencer instead of git-am?
    Sorry if this makes no sense; I'm not familiar with the git-am
    code.

 3. If I'm reading the code correctly, 'git cherry $upstream $branch
    $limit' does one walk to find patch-ids for "$upstream
    ^$branch". It then walks "$branch ^$upstream ^$limit" and removes
    the commits that have the same patch-id as a commit found in the
    first walk. Since format-patch uses the revision walking
    machinery, we could make it possible to ask git-rev-list directly
    what git-cherry does, i.e. to ask for "commits in a..b that don't
    share patch-id with commits in c..d". We could even make it more
    generic by allowing queries like "commits in
    $rev_list_expression_1 that don't share patch-id with commits in
    $rev_list_expression_2".

I'm not sure which option is better. Option 1 seems easiest to
implement. Option 3 seems a bit harder, but may bring more value. I'm
just not sure if teaching rev-list about patch-ids is generally useful
or if it would feel more like a hack for this specific case. Option 2
is less clear to me and I would probably need more input before
implementing, but I trust Junio that it would be a good long-term
solution.

I will be moving soon and I don't know how much time I will have to
implement any of this. Still, I would be happy to hear your
opinions. Maybe I'm just missing something and there is even a simple
solution to my problem.


Martin


[1] http://thread.gmane.org/gmane.comp.version-control.git/180976/focus=181085