From: Johannes Sixt <j.sixt@viscovery.net>
To: git@vger.kernel.org
Subject: Re: [PATCH] Let format-patch and rebase ignore trivial merges.
Date: Thu, 17 Dec 2009 12:40:05 +0100 [thread overview]
Message-ID: <4B2A1895.2000803@viscovery.net> (raw)
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
next prev parent reply other threads:[~2009-12-17 11:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-16 16:45 [PATCH] Let format-patch and rebase ignore trivial merges Bernhard R. Link
2009-12-16 16:53 ` Johannes Sixt
2009-12-17 9:35 ` Bernhard R. Link
2009-12-17 11:40 ` Johannes Sixt [this message]
2009-12-17 21:48 ` Bernhard R. Link
2009-12-17 22:44 ` Junio C Hamano
2009-12-18 13:06 ` Bernhard R. Link
2009-12-18 13:22 ` Johannes Sixt
2009-12-18 14:47 ` Bernhard R. Link
2009-12-18 15:11 ` [PATCH v2] " Bernhard R. Link
2009-12-18 18:23 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B2A1895.2000803@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).