Git with broken hash generation to generate collisions between object IDs. Don't use this!
https://undefinedbehavior.de/posts/commit-vandalism/
ec39d83a55
If there are modified files present in the working directory then we should not let the user perform a pull as it may fail due to the modified files being uncommitted but needing to be merged at the file level. Yes there are many cases where a merge will complete successfully even though there are modified or untracked files sitting in the working directory. But users generally shouldn't be attempting merges like that, and if they are they probably are advanced enough to just use the command line and bypass this little safety check. We also no longer run a rescan after a successful pull has completed. Usually this is unnecessary as a successful pull won't leave modified files laying around. Instead we just update our HEAD and PARENT values with the new commit, if there is one. Unfortunately this does let the user get into an insane state as there are bugs in core Git's git-pull and git-merge programs where the exit status is sent back as a 0 rather than non-0 when a failure is detected. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
||
---|---|---|
git-citool | ||
git-gui | ||
TODO |