37b65ce36b
There are three conflict types that represent two (possibly entirely unrelated) files colliding at the same location: * add/add * rename/add * rename/rename(2to1) These three conflict types already share more similarity than might be immediately apparent from their description: (1) the handling of the rename variants already involves removing any entries from the index corresponding to the original file names[*], thus only leaving entries in the index for the colliding path; (2) likewise, any trace of the original file name in the working tree is also removed. So, in all three cases we're left with how to represent two colliding files in both the index and the working copy. [*] Technically, this isn't quite true because rename/rename(2to1) conflicts in the recursive (o->call_depth > 0) case do an "unrename" since about seven years ago. But even in that case, Junio felt compelled to explain that my decision to "unrename" wasn't necessarily the only or right answer -- search for "Comment from Junio" in t6036 for details. My initial motivation for looking at these three conflict types was that if the handling of these three conflict types is the same, at least in the limited set of cases where a renamed file is unmodified on the side of history where the file is not renamed, then a significant performance improvement for rename detection during merges is possible. However, while that served as motivation to look at these three types of conflicts, the actual goal of this new function is to try to improve the handling for all three cases, not to merely make them the same as each other in that special circumstance. === Handling the working tree === The previous behavior for these conflict types in regards to the working tree (assuming the file collision occurs at 'foo') was: * add/add does a two-way merge of the two files and records it as 'foo'. * rename/rename(2to1) records the two different files into two new uniquely named files (foo~HEAD and foo~$MERGE), while removing 'foo' from the working tree. * rename/add records the two different files into two different locations, recording the add at foo~$SIDE and, oddly, recording the rename at foo (why is the rename more important than the add?) So, the question for what to write to the working tree boils down to whether the two colliding files should be two-way merged and recorded in place, or recorded into separate files. As per discussion on the git mailing lit, two-way merging was deemed to always be preferred, as that makes these cases all more like content conflicts that users can handle from within their favorite editor, IDE, or merge tool. Note that since renames already involve a content merge, rename/add and rename/rename(2to1) conflicts could result in nested conflict markers. === Handling of the index === For a typical rename, unpack_trees() would set up the index in the following fashion: old_path new_path stage1: 5ca1ab1e 00000000 stage2: f005ba11 00000000 stage3: 00000000 b0a710ad And merge-recursive would rewrite this to new_path stage1: 5ca1ab1e stage2: f005ba11 stage3: b0a710ad Removing old_path from the index means the user won't have to `git rm old_path` manually every time a renamed path has a content conflict. It also means they can use `git checkout [--ours|--theirs|--conflict|-m] new_path`, `git diff [--ours|--theirs]` and various other commands that would be difficult otherwise. This strategy becomes a problem when we have a rename/add or rename/rename(2to1) conflict, however, because then we have only three slots to store blob sha1s and we need either four or six. Previously, this was handled by continuing to delete old_path from the index, and just outright ignoring any blob shas from old_path. That had the downside of deleting any trace of changes made to old_path on the other side of history. This function instead does a three-way content merge of the renamed file, and stores the blob sha1 for that at either stage2 or stage3 for new_path (depending on which side the rename came from). That has the advantage of bringing information about changes on both sides and still allows for easy resolution (no need to git rm old_path, etc.), but does have the downside that if the content merge had conflict markers, then what we store in the index is the sha1 of a blob with conflict markers. While that is a downside, it seems less problematic than the downsides of any obvious alternatives, and certainly makes more sense than the previous handling. Further, it has a precedent in that when we do recursive merges, we may accept a file with conflict markers as the resolution for the merge of the merge-bases, which will then show up in the index of the outer merge at stage 1 if a conflict exists at the outer level. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> |
||
---|---|---|
.github | ||
block-sha1 | ||
builtin | ||
ci | ||
compat | ||
contrib | ||
Documentation | ||
ewah | ||
git-gui | ||
gitk-git | ||
gitweb | ||
mergetools | ||
negotiator | ||
perl | ||
po | ||
ppc | ||
refs | ||
sha1collisiondetection@232357eb2e | ||
sha1dc | ||
t | ||
templates | ||
vcs-svn | ||
xdiff | ||
.clang-format | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
.travis.yml | ||
.tsan-suppressions | ||
abspath.c | ||
aclocal.m4 | ||
advice.c | ||
advice.h | ||
alias.c | ||
alias.h | ||
alloc.c | ||
alloc.h | ||
apply.c | ||
apply.h | ||
archive-tar.c | ||
archive-zip.c | ||
archive.c | ||
archive.h | ||
argv-array.c | ||
argv-array.h | ||
attr.c | ||
attr.h | ||
banned.h | ||
base85.c | ||
bisect.c | ||
bisect.h | ||
blame.c | ||
blame.h | ||
blob.c | ||
blob.h | ||
branch.c | ||
branch.h | ||
builtin.h | ||
bulk-checkin.c | ||
bulk-checkin.h | ||
bundle.c | ||
bundle.h | ||
cache-tree.c | ||
cache-tree.h | ||
cache.h | ||
chdir-notify.c | ||
chdir-notify.h | ||
check_bindir | ||
check-builtins.sh | ||
check-racy.c | ||
checkout.c | ||
checkout.h | ||
color.c | ||
color.h | ||
column.c | ||
column.h | ||
combine-diff.c | ||
command-list.txt | ||
commit-graph.c | ||
commit-graph.h | ||
commit-reach.c | ||
commit-reach.h | ||
commit-slab-decl.h | ||
commit-slab-impl.h | ||
commit-slab.h | ||
commit.c | ||
commit.h | ||
common-main.c | ||
config.c | ||
config.h | ||
config.mak.dev | ||
config.mak.in | ||
config.mak.uname | ||
configure.ac | ||
connect.c | ||
connect.h | ||
connected.c | ||
connected.h | ||
convert.c | ||
convert.h | ||
copy.c | ||
COPYING | ||
credential-cache--daemon.c | ||
credential-cache.c | ||
credential-store.c | ||
credential.c | ||
credential.h | ||
csum-file.c | ||
csum-file.h | ||
ctype.c | ||
daemon.c | ||
date.c | ||
decorate.c | ||
decorate.h | ||
delta-islands.c | ||
delta-islands.h | ||
delta.h | ||
detect-compiler | ||
diff-delta.c | ||
diff-lib.c | ||
diff-no-index.c | ||
diff.c | ||
diff.h | ||
diffcore-break.c | ||
diffcore-delta.c | ||
diffcore-order.c | ||
diffcore-pickaxe.c | ||
diffcore-rename.c | ||
diffcore.h | ||
dir-iterator.c | ||
dir-iterator.h | ||
dir.c | ||
dir.h | ||
editor.c | ||
entry.c | ||
environment.c | ||
exec-cmd.c | ||
exec-cmd.h | ||
fast-import.c | ||
fetch-negotiator.c | ||
fetch-negotiator.h | ||
fetch-object.c | ||
fetch-object.h | ||
fetch-pack.c | ||
fetch-pack.h | ||
fmt-merge-msg.h | ||
fsck.c | ||
fsck.h | ||
fsmonitor.c | ||
fsmonitor.h | ||
generate-cmdlist.sh | ||
gettext.c | ||
gettext.h | ||
git-add--interactive.perl | ||
git-archimport.perl | ||
git-bisect.sh | ||
git-compat-util.h | ||
git-cvsexportcommit.perl | ||
git-cvsimport.perl | ||
git-cvsserver.perl | ||
git-difftool--helper.sh | ||
git-filter-branch.sh | ||
git-instaweb.sh | ||
git-merge-octopus.sh | ||
git-merge-one-file.sh | ||
git-merge-resolve.sh | ||
git-mergetool--lib.sh | ||
git-mergetool.sh | ||
git-p4.py | ||
git-parse-remote.sh | ||
git-quiltimport.sh | ||
git-rebase--am.sh | ||
git-rebase--interactive.sh | ||
git-rebase--merge.sh | ||
git-rebase--preserve-merges.sh | ||
git-rebase.sh | ||
git-remote-testgit.sh | ||
git-request-pull.sh | ||
git-send-email.perl | ||
git-sh-i18n.sh | ||
git-sh-setup.sh | ||
git-stash.sh | ||
git-submodule.sh | ||
git-svn.perl | ||
GIT-VERSION-GEN | ||
git-web--browse.sh | ||
git.c | ||
git.rc | ||
gpg-interface.c | ||
gpg-interface.h | ||
graph.c | ||
graph.h | ||
grep.c | ||
grep.h | ||
hash.h | ||
hashmap.c | ||
hashmap.h | ||
help.c | ||
help.h | ||
hex.c | ||
http-backend.c | ||
http-fetch.c | ||
http-push.c | ||
http-walker.c | ||
http.c | ||
http.h | ||
ident.c | ||
imap-send.c | ||
INSTALL | ||
interdiff.c | ||
interdiff.h | ||
iterator.h | ||
json-writer.c | ||
json-writer.h | ||
khash.h | ||
kwset.c | ||
kwset.h | ||
levenshtein.c | ||
levenshtein.h | ||
LGPL-2.1 | ||
line-log.c | ||
line-log.h | ||
line-range.c | ||
line-range.h | ||
linear-assignment.c | ||
linear-assignment.h | ||
list-objects-filter-options.c | ||
list-objects-filter-options.h | ||
list-objects-filter.c | ||
list-objects-filter.h | ||
list-objects.c | ||
list-objects.h | ||
list.h | ||
ll-merge.c | ||
ll-merge.h | ||
lockfile.c | ||
lockfile.h | ||
log-tree.c | ||
log-tree.h | ||
ls-refs.c | ||
ls-refs.h | ||
mailinfo.c | ||
mailinfo.h | ||
mailmap.c | ||
mailmap.h | ||
Makefile | ||
match-trees.c | ||
mem-pool.c | ||
mem-pool.h | ||
merge-blobs.c | ||
merge-blobs.h | ||
merge-recursive.c | ||
merge-recursive.h | ||
merge.c | ||
mergesort.c | ||
mergesort.h | ||
midx.c | ||
midx.h | ||
name-hash.c | ||
notes-cache.c | ||
notes-cache.h | ||
notes-merge.c | ||
notes-merge.h | ||
notes-utils.c | ||
notes-utils.h | ||
notes.c | ||
notes.h | ||
object-store.h | ||
object.c | ||
object.h | ||
oidmap.c | ||
oidmap.h | ||
oidset.c | ||
oidset.h | ||
pack-bitmap-write.c | ||
pack-bitmap.c | ||
pack-bitmap.h | ||
pack-check.c | ||
pack-objects.c | ||
pack-objects.h | ||
pack-revindex.c | ||
pack-revindex.h | ||
pack-write.c | ||
pack.h | ||
packfile.c | ||
packfile.h | ||
pager.c | ||
parse-options-cb.c | ||
parse-options.c | ||
parse-options.h | ||
patch-delta.c | ||
patch-ids.c | ||
patch-ids.h | ||
path.c | ||
path.h | ||
pathspec.c | ||
pathspec.h | ||
pkt-line.c | ||
pkt-line.h | ||
preload-index.c | ||
pretty.c | ||
pretty.h | ||
prio-queue.c | ||
prio-queue.h | ||
progress.c | ||
progress.h | ||
prompt.c | ||
prompt.h | ||
protocol.c | ||
protocol.h | ||
quote.c | ||
quote.h | ||
range-diff.c | ||
range-diff.h | ||
reachable.c | ||
reachable.h | ||
read-cache.c | ||
README.md | ||
ref-filter.c | ||
ref-filter.h | ||
reflog-walk.c | ||
reflog-walk.h | ||
refs.c | ||
refs.h | ||
refspec.c | ||
refspec.h | ||
RelNotes | ||
remote-curl.c | ||
remote-testsvn.c | ||
remote.c | ||
remote.h | ||
replace-object.c | ||
replace-object.h | ||
repository.c | ||
repository.h | ||
rerere.c | ||
rerere.h | ||
resolve-undo.c | ||
resolve-undo.h | ||
revision.c | ||
revision.h | ||
run-command.c | ||
run-command.h | ||
send-pack.c | ||
send-pack.h | ||
sequencer.c | ||
sequencer.h | ||
serve.c | ||
serve.h | ||
server-info.c | ||
setup.c | ||
sh-i18n--envsubst.c | ||
sha1-array.c | ||
sha1-array.h | ||
sha1-file.c | ||
sha1-lookup.c | ||
sha1-lookup.h | ||
sha1-name.c | ||
sha1dc_git.c | ||
sha1dc_git.h | ||
shallow.c | ||
shell.c | ||
shortlog.h | ||
sideband.c | ||
sideband.h | ||
sigchain.c | ||
sigchain.h | ||
split-index.c | ||
split-index.h | ||
strbuf.c | ||
strbuf.h | ||
streaming.c | ||
streaming.h | ||
string-list.c | ||
string-list.h | ||
sub-process.c | ||
sub-process.h | ||
submodule-config.c | ||
submodule-config.h | ||
submodule.c | ||
submodule.h | ||
symlinks.c | ||
tag.c | ||
tag.h | ||
tar.h | ||
tempfile.c | ||
tempfile.h | ||
thread-utils.c | ||
thread-utils.h | ||
tmp-objdir.c | ||
tmp-objdir.h | ||
trace.c | ||
trace.h | ||
trailer.c | ||
trailer.h | ||
transport-helper.c | ||
transport-internal.h | ||
transport.c | ||
transport.h | ||
tree-diff.c | ||
tree-walk.c | ||
tree-walk.h | ||
tree.c | ||
tree.h | ||
unicode-width.h | ||
unimplemented.sh | ||
unix-socket.c | ||
unix-socket.h | ||
unpack-trees.c | ||
unpack-trees.h | ||
upload-pack.c | ||
upload-pack.h | ||
url.c | ||
url.h | ||
urlmatch.c | ||
urlmatch.h | ||
usage.c | ||
userdiff.c | ||
userdiff.h | ||
utf8.c | ||
utf8.h | ||
varint.c | ||
varint.h | ||
version.c | ||
version.h | ||
versioncmp.c | ||
walker.c | ||
walker.h | ||
wildmatch.c | ||
wildmatch.h | ||
worktree.c | ||
worktree.h | ||
wrap-for-bin.sh | ||
wrapper.c | ||
write-or-die.c | ||
ws.c | ||
wt-status.c | ||
wt-status.h | ||
xdiff-interface.c | ||
xdiff-interface.h | ||
zlib.c |
Git - fast, scalable, distributed revision control system
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.
See Documentation/gittutorial.txt to get started, then see
Documentation/giteveryday.txt for a useful minimum set of commands, and
Documentation/git-.txt for documentation of each command.
If git has been correctly installed, then the tutorial can also be
read with man gittutorial
or git help tutorial
, and the
documentation of each command with man git-<commandname>
or git help <commandname>
.
CVS users may also want to read Documentation/gitcvs-migration.txt
(man gitcvs-migration
or git help cvs-migration
if git is
installed).
The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just "subscribe git" in the body to majordomo@vger.kernel.org. The mailing list archives are available at https://public-inbox.org/git/, http://marc.info/?l=git and other archival sites.
Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.
The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks