Re: when git-rebase -i fails to cherry-pick

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

 



Hi,

On Tue, 24 Jul 2007, Uwe Kleine-K?nig wrote:

> even though git-rebase -i is still young, I'm already a big fan of it.

Nice!

> I just want to suggest two minor things:
> 
> - If a cherry-pick fails, it tells me to resolve my conflicts, 'git add
>   <paths>' and to do 'git commit -c $sha1id'.
> 
>   But it doesn't tell me, how I continue to rebase after that.
> 
>   'git rebase -i --continue' works.

Actually, even "git rebase --continue" works.  And you do not really have 
to commit, either, just updating your index is fine.  In fact, if you say 
"git reset --hard", it will skip the commit.

> - If a cherry-pick of a commit to be squashed fails, the instruction to
>   do 'git commit -c $sha1id' is wrong, because then I don't get both
>   message to squash.

Yes, it is a leftover from the bad old days, when this script was called 
edit-patch-series, and I was a rebase hater.

In the meantime, somebody on IRC explained to me how rebase works, and 
that rebase lovers were quite annoyed not to be able to just resolve the 
conflicts and "git rebase --continue".

I'd appreciate if you prepared a patch with better explanations, and also 
reviewed the man page, if it is in good shape (and does not lie about the 
current behaviour).

Thanks,
Dscho

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

  Powered by Linux