Re: [BUG] git checkout <branch> allowed with uncommitted changes

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

 



Andreas Ericsson <ae <at> op5.se> writes:
> there's no reason to refuse the branch change.
> Partly because nothing will be lost

Actually, this isn't true either, because of the second bug: doing a revert
in branchA causes the changes in branchB to be lost. This can't possibly be
the intended behavior: again, it completely violates the integrity of branches
by allowing changes on one branch to impact a different branch.

Your interpretation of the manpage doubtless matches the actual behavior of git,
but I find it staggering if that truly is what was intended. It basically means
that if you have local modifications, git will Break Your Entire Tree. That
makes changing while you *do* have local mods more than a little undesirable,
to put it mildly, which is something that a literal reading of the manpage would
suggest is exactly what the "refuse to switch" is for. I guess only Linus knows
what he actually meant.  :)

Anyway, I guess it's all moot: call it a feature or call it a bug, this cross-
branch destruction is a deal-breaker for me, especially given the bug above that
actually loses data outright, rather than "only" putting multiple branches into
an incorrect state.

Thanks for your time and help.


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