Re: Commit dropped when swapping commits with rebase -i -p

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

 



On 16/09/17 14:45, Sebastian Schuberth wrote:

On Sat, Sep 16, 2017 at 12:41 PM, Andreas Heiduk <asheiduk@xxxxxxxxx> wrote:

Therefore I would avoid "definitive wording" like "will drop" and use
vague wording along "there are various dragons out there" like this:

     The todo list presented by `--preserve-merges --interactive` does
     not represent the topology of the revision graph.  Editing

I tried to avoid this introducing sentence from the original wording
as it reads like from a scientific research paper instead of from a
user's manual.

     commits and rewording their commit messages should work fine.
     But reordering, combining or dropping commits of a complex topology

There is no need for complex topology. If you reorder the two most
recent commits in a linear history, one gets dropped.

     can produce unexpected and useless results like missing commits,
     wrong merges, merges combining two unrelated histories and
     similar things.

"can produce" is much too soft, IMO. Reordering commits goes wrong,
period. Like wise "unexpected and useless results" is inappropriate.
The results are wrong in case of reordering, and wrong results are of
course unexpected and useless.

I agree that the wording needs to be explicit that bad things will happen. It should spell out that if commits or reordered, or the fixup or squash commands are used then commits will be dropped and if commits are deleted from the list or the drop command is used other commits other than the intended ones will be dropped as well.




[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