"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: >> 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 :) >> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html