Re: [PATCH 2/2] rebase -i: Preserve whitespace at beginning of commit header in $GIT_EDITOR

[Nazri Ramliy <ayiehere@gmail.com>]

On Mon, Jul 12, 2010 at 2:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If the current code removes whitespaces at the beginning, I would actually
> say that it is cleaning up the mess while preparing the instruction sheet
> for you to edit, i.e. it is a good thing, and the patch might be making
> things worse.

Consider this situation:

	$ git log --reverse --oneline HEAD~3..
	cafebabe a commit header
	deadbeef   badly formatted commit header
	falaafe1 another commit header

Without the patch (let's call this "exhibit 1"):

	$ GIT_EDITOR=cat git rebase -i HEAD~3
	cafebabe a commit header
	deadbeef badly formatted commit header
	fa1aafe1 another commit header

With the patch (and let's call this "exhibit 2"):

	$ GIT_EDITOR=cat git rebase -i HEAD~3
	cafebabe a commit header
	deadbeef    badly formatted commit header
	fa1aafe1 another commit header

> I find it difficult to come up with good reasons to convince myself that I
> should be interested in what this patch tries to do.

I guess it boils down to your answer to this:

When you want to reword the badly formatted commit header, would you
prefer the see the output like the one shown in exhibit 1 over that of
exhibit 2 in your $GIT_EDITOR?

The example I gave has only one commit header with beginning whitespace.
What if for some reason you end up with more than a couple of commits
headers that have whitespaces at the beginning and you would like to
rebase them to fix it and what you see is the one similar to exhibit 1?

Isn't it harder to distinguish those badly formatted commits in that case?

> Here are some of the things that came to my mind while doing so.
>
> What happens if you have trailing whitespaces, excess whitespaces in the
> middle, etc. with or without this patch?  What _should_ happen in an ideal
> world?

Trailing/excess whitespaces are non issue. The intention of this patch is to
present the commit headers "as-is".

> What happens if you have a malformed commit object whose first line is
> blank (i.e. no "Subject" line),or there is _no_ commit log message
> whatsoever with or without this patch?  What _should_ happen in an ideal
> world?

When there is no commit log message the behavior is the same with or
without this patch.

I can't test for when the commit has no "Subject" line because I don't
know how to make one.  One thing for sure that in this case, with this
patch, what is shown in $GIT_EDITOR will be exactly the same as what

        $ git log $sha1_for_that_commit --format="pick %h %s"

shows.

If you agree with my arguments here then I'll proceed with modifying the
first patch in this series as per the discussion in the thread started by
1278764821-32647-1-git-send-email-ayiehere@gmail.com.

nazri