From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Add -r flag to show-diff for diff-cache/diff-tree like output.
Date: Tue, 26 Apr 2005 16:05:46 -0700 [thread overview]
Message-ID: <7vd5shm94l.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0504261534590.18901@ppc970.osdl.org> (Linus Torvalds's message of "Tue, 26 Apr 2005 15:40:37 -0700 (PDT)")
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Why not just make this the default? Who really cares about
LT> show-diff?
Me, to care enough about it to send patches in ;-).
LT> So why not just make "rational" the standard format, and then make
LT> "diff-tree-helper" warn about unmerged ("U") files?
LT> As far as I can tell, that is really what _everybody_ wants.
I do not think of a good reason to forbid people from getting a
patch out of core GIT without going through the wrapper layer,
and the code is already there. That said, I agree that scripts
usually do not use patch generating form. I checked Cogito
before doing the patch to make sure it is not affected by this,
and my JIT core tools do not use it either.
I think making the diff-tree/cache compatible output default
would be fine. The current diff-producing behaviour can be made
into an option (yes, I want to keep it).
LT> And calling "-r" "rational", when it means "recursive" for
LT> diff-tree and diff-cache doesn't sound rational to me.
Well, the truth is that -r does not stand for anything. It just
is there to match useless -r to diff-cache (the change you made
to it to accept the same command line parameters -r (and
optionally -z) people would always give diff-tree. You can call
it recursive if you want.
How about me doing the following and resubmitting?
- Make this diff-tree/cache compatible output the default.
- Take but ignore -r flag like diff-cache.
- Add U warning to diff-tree-helper.
- Add -p flag (patch) and have it cause the patch generating
behaviour.
Later I'll add -p flag to diff-cache and diff-tree, so the usage
of these three commands match. That is:
show-diff -r (useless) -z | diff-tree-helper -z
diff-cache -r (useless) -z tree | diff-tree-helper -z
diff-tree -r -z tree tree | diff-tree-helper -z
show-diff -p [-r (useless)]
diff-cache -p [-r (useless)]
diff-tree -p [-r]
With the GIT_EXTERNAL_DIFF envioronment variable, I suspect that
wrapper scripts do not have to use the diff-tree-helper but
directly use the -p form; but that will come later. Thoughts?
next prev parent reply other threads:[~2005-04-26 23:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1113400651.20848.135.camel@hades.cambridge.redhat.com>
2005-04-24 5:09 ` [GIT PATCH] Selective diff-tree Linus Torvalds
2005-04-24 6:25 ` David Woodhouse
2005-04-24 17:15 ` Linus Torvalds
2005-04-24 7:40 ` Junio C Hamano
2005-04-24 17:20 ` Linus Torvalds
2005-04-25 5:12 ` [PATCH 0/2] diff-tree/diff-cache helper Junio C Hamano
2005-04-25 5:15 ` [PATCH 1/2] Split external diff command interface to a separate file Junio C Hamano
2005-04-25 5:17 ` [PATCH 2/2] Introduce diff-tree-helper Junio C Hamano
2005-04-26 1:38 ` [PATCH 0/2] diff-tree/diff-cache helper Linus Torvalds
2005-04-26 2:08 ` Nicolas Pitre
2005-04-26 7:39 ` Junio C Hamano
2005-04-26 7:57 ` [PATCH] Diff-tree-helper take two Junio C Hamano
2005-04-26 22:27 ` [PATCH] Add -r flag to show-diff for diff-cache/diff-tree like output Junio C Hamano
2005-04-26 22:40 ` Linus Torvalds
2005-04-26 23:05 ` Junio C Hamano [this message]
2005-04-26 23:44 ` Linus Torvalds
2005-04-27 0:05 ` Junio C Hamano
2005-04-27 0:22 ` Linus Torvalds
2005-04-26 23:45 ` [PATCH] diff-cache/tree compatible output for show-diff (take 2) Junio C Hamano
2005-04-27 0:20 ` Linus Torvalds
2005-04-27 0:29 ` Linus Torvalds
[not found] ` <Pine.LNX.4.58.0504261750030.18901@ppc970.osdl.org>
2005-04-27 1:09 ` Linus Torvalds
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vd5shm94l.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).