Re: Heads up: rebase -i -p will be made sane again

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

 



Hi,

On Tue, 27 Jan 2009, Stephen Haberman wrote:

> > So I adapted my code to find the "dropped" merges in 
> > git-rebase--interactive, too, for now, but I guess the proper fix is 
> > something like this:
> 
> So, if C, as a merge commit, doesn't get a patch id anymore (right?),
> does that mean that C is included with A and D in the cherry-picking
> on top of UPSTREAM (because with no patch id it cannot be recognized
> as a duplicate)?

Yep, it gets into the list.  But not with a "pick" command, as a merge it 
will get a "merge" command.

> So then C' is an empty-commit? This would be fine, I think, or can you 
> detect that C is a noop somehow without patch ids?

Actually, there are three possible outcomes:

- it tries to merge an ancestor of HEAD or HEAD itself -> noop

- it tries to merge which results in a fast-forward -> fine

- it tries to merge and a proper merge is necessary -> may conflict

Ciao,
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