preventing evil merges

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

 



Hey all,
I've be burnt by what someone on IRC referred to as "evil merges",
that is loss of history after amending a merge commit:

 git merge anotherbranch
 git add something
 git commit --amend

After the steps above the addition of "something" can't be found in
the history anymore, but the file is there. Moreover (I think but
didn't try to reproruce) a further rebase to a common ancestore of
my working branch and "anotherbranch" resulted in further loss of
the changes. The only way for me to get them back has been by 
checking out from reflog.

I've no idea about what was going on but this experience reminded me
of another one I had in the past in which we could not figure out when
some changes were added into a repository (!).

If amending a merge is so dangerous, would it make sense to require
and hard-to-type switch in order for it to really do anything ?

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