Carl Worth [off-list ref] writes:
1) I think the patch should come after the traditional status summary,
not before. If something is obviously "wrong" (non-updated file,
etc.) that will be more obvious in the summary, so it's good to
present that up front, and not bury it after the patch, (which
might make it initially invisible without scrolling).
Maybe. A time for a quick poll.
2) Using the "^---$" separator to separate the the edited contents
into a commit message and ignored content seems risky to me.
Moving the patch after the summary (as discussed above) would help
greatly in avoiding the clobbered separator, but wouldn't address
the separator-appears-in-commit-message problem.
That is a good argument for (1). Since the diff output never
has '^---$' in itself, instead of discarding everything after
the first '^---$', we could change the log cleanser to discard
after the _last_ '^---$'. But coding this sanely is much
trickier with sed ;-).
Dear diary, on Fri, Feb 10, 2006 at 10:09:41PM CET, I got a letter
where Junio C Hamano [off-list ref] said that...
Carl Worth [off-list ref] writes:
quoted
1) I think the patch should come after the traditional status summary,
not before. If something is obviously "wrong" (non-updated file,
etc.) that will be more obvious in the summary, so it's good to
present that up front, and not bury it after the patch, (which
might make it initially invisible without scrolling).
Maybe. A time for a quick poll.
It makes more sense to me. (Not that I'd be ever going to use the
command, though. ;)
quoted
2) Using the "^---$" separator to separate the the edited contents
into a commit message and ignored content seems risky to me.
We do it for the mails (and Cogito for cg-mkpatch output) and it seems
to work out just fine.
quoted
Moving the patch after the summary (as discussed above) would help
greatly in avoiding the clobbered separator, but wouldn't address
the separator-appears-in-commit-message problem.
That is a good argument for (1). Since the diff output never
has '^---$' in itself,
$ echo -- >a; >b; diff -u a b
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
On Fri, 10 Feb 2006, Junio C Hamano wrote:
Carl Worth [off-list ref] writes:
quoted
1) I think the patch should come after the traditional status summary,
not before. If something is obviously "wrong" (non-updated file,
etc.) that will be more obvious in the summary, so it's good to
present that up front, and not bury it after the patch, (which
might make it initially invisible without scrolling).
Maybe. A time for a quick poll.
I think I agree. Especially if doing "git commit -v", the _top_ of the
status message is what you'd normally be most aware of. I think.
Especially if the patch is large, you'd grow bored looking at it long
before you saw what followed.
Linus