Re: [PATCHv3] git-rebase--interactive.sh: extend "edit" command to be more useful

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

 



Kevin Ballard wrote:
> On Dec 3, 2010, at 12:06 AM, Jonathan Nieder wrote:

>> Maybe something like
>> 
>> 	rebase-i: treat "edit" without sha1 as a request to amend previous commit
>> 
>> would make the meaning more obvious in a shortlog.
>
> That seems a bit misleading, though. This command really has nothing to do with
> amending the previous commit.

Okay, maybe

	rebase-i: extend "edit" to allow stopping without a commit to amend

Or something else entirely; I only meant that "to be more useful" is
a bit vague (it could be cut out without loss of meaning).

>> Maybe this can be done without relying on details of --pretty=oneline
>> format?
>> 
>> 			sha1=$(git rev-parse --short HEAD)
>> 			rest=$(git show -s --format=%s HEAD)
>
> Does this not similarly assume that rev-parse and show will not fail? Or was
> the above comment only meant to point out this potential issue without
> suggesting that it needed to be fixed?

Yes, that's right.  The exit status from rev-list is ignored
throughout the script; making that more robust is a separate topic.

BTW this suggestion about avoiding --pretty=oneline was nonsense ---
the output format from

	git rev-list --pretty=oneline

is guaranteed to stay the same because rev-list is plumbing.  Sorry
for the noise.

Good night,
Jonathan
--
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]