Is "* -text" in any way different than "-text" (without the * asterisk)? All
of my .gitattributes files have "-text" (no * asterisk) and I haven't noticed
any difference but could I be missing something subtle?
~Ross
of not touching the input is preferable
and expected for a plumbing command like "commit-tree".
Signed-off-by: Ross Kabus
---
Fixed up commit message with feedback from Junio.
builtin/commit-tree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/commit-tree.c b/builtin
On Thu, Sep 7, 2017 at 9:35 PM, Junio C Hamano wrote:
> commit-tree: do not complete line in -F input
>
> "git commit-tree -F ", unlike "cat | git
> commit-tree" (i.e. feeding the same contents from the standard
> input), added a missing final newline when the input ended in an
>
to the "-F"
input. The issue is somewhat muddled by the fact that git-commit
does pass the message through its --cleanup option, which may add
such a newline. But for commit-tree to match "commit --cleanup=verbatim",
we should not do so here.
Signed-off-by: Ross Kabus
Gmail mangled that patch of course...
Ross Kabus
Software Engineer
www.aerotech.com | 412-968-2833
On Tue, Sep 5, 2017 at 4:57 PM, Ross Kabus wrote:
> From: Ross Kabus
> Date: Tue, 5 Sep 2017 13:54:52 -0400
> Subject: [PATCH] commit-tree: don't append a newline with -F
>
>
From: Ross Kabus
Date: Tue, 5 Sep 2017 13:54:52 -0400
Subject: [PATCH] commit-tree: don't append a newline with -F
This change makes it such that commit-tree -F never appends a newline
character to the supplied commit message (either from file or stdin).
Previously, commit-tree -F would a
On Tue, Sep 5, 2017 at 11:36 AM, Jeff King wrote:
> So I'd argue that "git commit -F" is doing a reasonable
> thing, and "commit-tree -F" should probably change to match it (because
> it's inconsistent, and because if anything the plumbing commit-tree
> should err more on the side of not touching
On Sat, Sep 2, 2017 at 4:33 AM, Jeff King wrote:
> But I am confused by your "inconsistent with git commit porcelain"
> comment. The porcelain git-commit definitely _does_ add a newline if one
> isn't present (and in fact runs the whole thing through git-stripspace
> to clean up whitespace odditi
Hello,
When doing git commit-tree to manually create a commit object, it can be seen
that the resulting commit's message has an extra appended newline (\n) that
was not present in the input for either argument -m or -F. This is both
undesirable and inconsistent with the git commit porcelain comman
9 matches
Mail list logo
