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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nazri Ramliy <ayiehere@xxxxxxxxx> writes:

> During "git rebase -i", when the commit headers are shown in the editor
> for action (pick/squash/etc), the whitespace (if any) at the beginning
> of commit headers are stripped out due to the use of "read shortsha1 rest"
> for reading the output of "git rev-list".
>
> The missing beginning whitespace do not pose any harm but this could be

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.

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.  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?

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?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]