From: Johannes Sixt <j.sixt@viscovery.net>
Date: Thu, 17 Dec 2009 11:40:05 GMT
Subject: Re: [PATCH] Let format-patch and rebase ignore trivial merges.
Message-ID: <4B2A1895.2000803@viscovery.net>
In-Reply-To: <20091217093547.GA25451@pcpool00.mathematik.uni-freiburg.de>

Bernhard R. Link schrieb:
> * Johannes Sixt <j.sixt@viscovery.net> [091216 17:53]:
>> Bernhard R. Link schrieb:
>>> --prune-tree makes rev-list without paths equivalent to
>>> "git rev-list $options -- ." (or .. or ../.. and so on,
>>> if you are in some subdirectory).
>>> This is the new default for format-patch and rebase
>> Why do you need a new option when you can just add "-- ." to the rev-list
>> invocation?
> 
> I want the default for format-patch changed.

I do not see why format-patch would have to be changed. The case that you
outline (a merge -s ours happened and you want to follow only one parent)
is rare enough and even more rarly will somebody want to apply
format-patch to such a history.

But I guess that you are actually not interested in format-patch per se,
but rather in rebase (which uses format-patch).

> For this I think it is easiest to add a new rev_info flag, as otherwise
> format-patch would need to duplicate parsing the rev_list options
> and either duplicate applying revs->prune_data or changing the argv for
> setup_revisions with some special casing of bare repository and non-bare
> repository cases.

I haven't looked at the code, but wouldn't it be matter of "if we do not
have any pathspec, add '.'" *after* all options are parsed?

> And when there is that option, I think it is more robust to use that
> in merge -m and merge -i, as "-- ." only does the right thing by chance
> because both only work with a non-bare repository and have
> cd_to_toplevel.

git rev-list -- . works in a bare repository, too. If you hard-code "-- ."
in the rev-list invocations in git-rebase[--interactive], then it cannot
be said that this works "by chance" due to cd_to_toplevel.

-- Hannes