"Shawn O. Pearce" [off-list ref] writes:
Johannes Schindelin [off-list ref] wrote:
quoted
This is a patch for git-gui, so why not make that clear in the subject?
(And I have a hunch that Shawn would have liked the patch relative to
git-gui.git, not git.git...)
Indeed.
its clear in both the email and in the commit log that the change is
a git-gui change. Remember, git-gui's logs show up in the core Git
logs (as its merged with -s subtree) so having that git-gui: prefix
does help people to localize the change within the overall suite.
Thanks for the feedback on the patch.
This is my first attempt at creating a patch for git (even if it is
mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo
and conventions regarding the commit message. I just tried to follow
what was in Documentation/SubmittingPatches. I'll try to do better next
time :)
quoted
Further, there are other tools than rebase -i that like commit messages
better when terminated by a newline, and _that_ is what I would like to
read in the commit message for this patch.
Hmmph. For that reason alone I'm tempted to *not* apply Bernt's
patch.
There is nothing that requires that a commit object end with an LF.
So tools that make this assumption (that there is a trailing LF)
while processing the body of a commit message are quite simply
broken.
Forcing a LF on the end of the commit message feels wrong to me too.
This band-aid solution fixes the issue I'm dealing with for
git-rebase -i when squashing 3 or more commits created by git-gui.
I agree with Sean and think the more correct fix would be to make
git rebase -i and any other tools we encounter with similar problems
handle the case where there is no newline at the end of the commit
message.
The patch as it stands should probably not be applied.
-Bernt