Re: [RFC] Add "edit" action for interactive rebase?

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

 



On Mon, Sep 10, 2012 at 2:28 PM, Johannes Sixt <j6t@xxxxxxxx> wrote:
> Did you think about what can go wrong? For example, starting with this
> todo sheet:
>
>   exec false
>   pick 1234567

Ah, that's definitely a problem.

I was going to say we probably just to check the "done" file, same as
the one we do for a fresh "rebase -i", but it turns out the "exec
false" will fool the "has_action" check for a fresh "rebase -i" too.
Heh.

Maybe we should improve the check for a fresh "rebase -i" case, then
we can do the same check for this case. Maybe we can grep for a "pick"
in "done" file? Or we can check if there's anything in "rewritten"?
Though I'm not sure if any of those is really foolproof. Or should we
just ignore this case and assume the user knows what s/he's doing?

Incidentally, if the starting todo file is:
    pick A
    exec false
    pick B

If the user then changes the "pick B" to "squash B", it should be a
valid I think, and "rebase -i" should handle that properly. It should,
because that's the same thing as:
    pick C (which results in a conflict and stopped)
    squash D

OT: That "exec false" !
I ran into numerous occasions where I wanted to manually do something
before the "first commit after upstream", such as creating a new
commit or merge.  And I only had two ways of doing it:
1. to rebase against "upstream^", and then mark the upstream as edit
2. insert a "exec bash" in front of the "first commit"
But "exec false" will work much much nicer. :)
--
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]