From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: git-format-patch little gripe
Date: Fri, 03 Nov 2006 21:53:58 +0100 [thread overview]
Message-ID: <eiga89$ho$1@sea.gmane.org> (raw)
In-Reply-To: 20061103195253.9244.qmail@web31814.mail.mud.yahoo.com
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> One thing we talked about but nobody stepped up to code [*1*] is
>> to give "git-format-patch --stdin" that reads list of commits,
>> and runs "git-diff-tree --pretty --stat --summary -p $commit".
>> With that, we could do something like:
>>
>> git rev-list linus..orinoco | git format-patch --stdin
>
> That'd be swell to have.
>
>> Your "git-format-patch --single $commit" is a shorthand for a
>> degenerated special case of that pattern.
>
> Yes, except that I'd have to paste the sha-1 into the terminal
> rather than on the command line. This again proves that the current
> git-format-patch <sha-1> to mean "<sha-1>..HEAD" is horribly broken.
First, you could have behavior you wanted by using additional option
--single, i.e. git-format-patch --single <sha-1> would mean
git-format-patch <sha-1>^..<sha-1>
But I agree that it is somewhat counter-intuitive that for all
other commands which use revision list <sha-1> means lineage
of <sha-1> while for git-format-patch it means <sha-1>..HEAD
... and we have <sha-1>.. shortcut (two characters more) to mean
the same.
Another command with non-obvious UI is git-format-branch, which
is not CLI equivalent of gitk/qgit (doesn't accept revision range
for example).
>> You cannot do patch-id based filtering with this form, but I see
>> that "single" is often wanted on the list and #git, and people
>> who want it do not care about patch-id based filtering at all.
>
> The reason it is wanted is because it is _intuitive_. This is
> what engineers (of different backgrounds) tend to intuitively think
> and assume given git's structure and the nature and meaning of
> what an <sha-1> is in git, only to be surprised later when that
> assumption is completely broken by git-format-patch.
Intuiveness is in the eye of beholder :-)
>> And I do not think it is that "they do not realize how much they
>> would be missing without patch-id filtering", in this case. So
>> the above command line would probably be Ok.
>
> I do not think they'd be missing _anything_. After all,
> "git-format-patch <sha-1>..HEAD" is also intuitive.
And we have <sha-1>.. shortcut.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
next prev parent reply other threads:[~2006-11-03 20:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-03 9:07 git-format-patch little gripe Luben Tuikov
2006-11-03 9:22 ` Martin Langhoff
2006-11-03 9:59 ` Luben Tuikov
2006-11-03 11:17 ` Junio C Hamano
2006-11-03 17:32 ` Carl Worth
2006-11-03 17:51 ` Jakub Narebski
2006-11-03 19:52 ` Luben Tuikov
2006-11-03 20:53 ` Jakub Narebski [this message]
2006-11-03 22:26 ` Junio C Hamano
2006-11-03 22:35 ` Carl Worth
2006-11-03 23:16 ` Jeff King
2006-11-03 23:37 ` Jakub Narebski
2006-11-04 0:44 ` Linus Torvalds
2006-11-04 1:05 ` Jakub Narebski
2006-11-03 18:50 ` Jeff King
2006-11-03 20:37 ` Luben Tuikov
2006-11-25 15:30 ` Sean
[not found] ` <20061125103033.2ea742d3.seanlkml@sympatico.ca>
2006-11-25 15:39 ` Jeff King
2006-11-25 15:42 ` Sean
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='eiga89$ho$1@sea.gmane.org' \
--to=jnareb@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.