summaryrefslogtreecommitdiff
path: root/merge-recursive.c
AgeCommit message (Collapse)AuthorFilesLines
2007-08-14Use xmkstemp() instead of mkstemp()Libravatar Luiz Fernando N. Capitulino1-3/+1
xmkstemp() performs error checking and prints a standard error message when an error occur. Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-14merge-recursive: do not rudely die on binary mergeLibravatar Junio C Hamano1-23/+28
When you try to merge a path that involves binary file-level merge, merge-recursive died rudely without cleaning up its own mess. A files added by the merge were left in the working tree, but the index was not written out (because it just punted and died), so it was cumbersome for the user to retry it by first running "git reset --hard". This changes merge-recursive to still warn but do the "binary" merge for such a path; leave the "our" version in the working tree, but still keep the path unmerged so that the user can sort it out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-10Start moving unpack-trees to "struct tree_desc"Libravatar Linus Torvalds1-5/+11
This doesn't actually change any real code, but it changes the interface to unpack_trees() to take an array of "struct tree_desc" entries, the same way the tree-walk.c functions do. The reason for this is that we would be much better off if we can do the tree-unpacking using the generic "traverse_trees()" functionality instead of having to the special "unpack" infrastructure. This really is a pretty minimal diff, just to change the calling convention. It passes all the tests, and looks sane. There were only two users of "unpack_trees()": builtin-read-tree and merge-recursive, and I tried to keep the changes minimal. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13-Wold-style-definition fixLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-04merge-recursive: refuse to merge binary filesLibravatar Johannes Schindelin1-0/+6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-26Ignore merged status of the file-level mergeLibravatar Alex Riesen1-1/+1
as it is not relevant for whether the result should be written. Even if no real merge happened, there might be _no_ reason to rewrite the working tree file. Maybe even more so. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Add a test for merging changed and rename-changed branchesLibravatar Alex Riesen1-0/+5
Also leave a warning for future merge-recursive explorers. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Avoid excessive rewrites in merge-recursiveLibravatar Alex Riesen1-13/+19
If a file is changed in one branch, and renamed and changed to the same content in another branch than we can skip the rewrite of this file in the working directory, as the content does not change. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-21Merge branch 'jc/attr'Libravatar Junio C Hamano1-21/+382
* 'jc/attr': (28 commits) lockfile: record the primary process. convert.c: restructure the attribute checking part. Fix bogus linked-list management for user defined merge drivers. Simplify calling of CR/LF conversion routines Document gitattributes(5) Update 'crlf' attribute semantics. Documentation: support manual section (5) - file formats. Simplify code to find recursive merge driver. Counto-fix in merge-recursive Fix funny types used in attribute value representation Allow low-level driver to specify different behaviour during internal merge. Custom low-level merge driver: change the configuration scheme. Allow the default low-level merge driver to be configured. Custom low-level merge driver support. Add a demonstration/test of customized merge. Allow specifying specialized merge-backend per path. merge-recursive: separate out xdl_merge() interface. Allow more than true/false to attributes. Document git-check-attr Change attribute negation marker from '!' to '-'. ...
2007-04-21Fix bogus linked-list management for user defined merge drivers.Libravatar Junio C Hamano1-1/+2
ll_user_merge_tail is supposed to point at the pointer to be updated to point at a newly created item. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-20Kill the useless progress meter in merge-recursiveLibravatar Shawn O. Pearce1-62/+3
The mess known as the progress meter in merge-recursive was my own fault; I put it in thinking that we might be spending a lot of time resolving unmerged entries in the index that were not handled by the simple 3-way index merge code. Turns out we don't really spend that much time there, so the progress meter was pretty much always jumping to "(n/n) 100%" as soon as the program started. That isn't a very good indication of progress. Since I don't have a great solution for how a progress meter should work here, I'm proposing we back it out entirely. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-19Fix working directory errno handling when unlinking a directoryLibravatar Linus Torvalds1-25/+29
Alex Riesen noticed that the case where a file replaced a directory entry in the working tree was broken on cygwin. It turns out that the code made some Linux-specific assumptions, and also ignored errors entirely for the case where the entry was a symlink rather than a file. This cleans it up by separating out the common case into a function of its own, so that both regular files and symlinks can share it, and by making the error handling more obvious (and not depend on any Linux-specific behaviour). Acked-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Simplify code to find recursive merge driver.Libravatar Junio C Hamano1-7/+2
There is no need to intern the string to git_attr, as we are already dealing with the name of the driver there. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Counto-fix in merge-recursiveLibravatar Junio C Hamano1-1/+4
When the configuration has variables unrelated to low-level merge drivers (e.g. merge.summary), the code failed to ignore them but did something totally senseless. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Fix funny types used in attribute value representationLibravatar Junio C Hamano1-7/+10
It was bothering me a lot that I abused small integer values casted to (void *) to represent non string values in gitattributes. This corrects it by making the type of attribute values (const char *), and using the address of a few statically allocated character buffer to denote true/false. Unset attributes are represented as having NULLs as their values. Added in-header documentation to explain how git_checkattr() routine should be called. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Allow low-level driver to specify different behaviour during internal merge.Libravatar Junio C Hamano1-0/+12
This allows [merge "drivername"] to have a variable "recursive" that names a different low-level merge driver to be used when merging common ancestors to come up with a virtual ancestor. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Custom low-level merge driver: change the configuration scheme.Libravatar Junio C Hamano1-77/+125
This changes the configuration syntax for defining a low-level merge driver to be: [merge "<<drivername>>"] driver = "<<command line>>" name = "<<driver description>>" which is much nicer to read and is extensible. Credit goes to Martin Waitz and Linus. In addition, when we use an external low-level merge driver, it is reported as an extra output from merge-recursive, using the value of merge.<<drivername>.name variable. The demonstration in t6026 has also been updated. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Allow the default low-level merge driver to be configured.Libravatar Junio C Hamano1-2/+12
When no 'merge' attribute is given to a path, merge-recursive uses the built-in xdl-merge as the low-level merge driver. A new configuration item 'merge.default' can name a low-level merge driver of user's choice to be used instead. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Custom low-level merge driver support.Libravatar Junio C Hamano1-12/+165
This allows users to specify custom low-level merge driver per path, using the attributes mechanism. Just like you can specify one of built-in "text", "binary", "union" low-level merge drivers by saying: * merge=text .gitignore merge=union *.jpg merge=binary pick a name of your favorite merge driver, and assign it as the value of the 'merge' attribute. A custom low-level merge driver is defined via the config mechanism. This patch introduces 'merge.driver', a multi-valued configuration. Its value is the name (i.e. the one you use as the value of 'merge' attribute) followed by a command line specification. The command line can contain %O, %A, and %B to be interpolated with the names of temporary files that hold the common ancestor version, the version from your branch, and the version from the other branch, and the resulting command is spawned. The low-level merge driver is expected to update the temporary file for your branch (i.e. %A) with the result and exit with status 0 for a clean merge, and non-zero status for a conflicted merge. A new test in t6026 demonstrates a sample usage. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-17Allow specifying specialized merge-backend per path.Libravatar Junio C Hamano1-7/+129
This allows 'merge' attribute to control how the file-level three-way merge is done per path. - If you set 'merge' to true, leave it unspecified, or set it to "text", we use the built-in 3-way xdl-merge. - If you set 'merge' to false, or set it to "binary, the "binary" merge is done. The merge result is the blob from 'our' tree, but this still leaves the path conflicted, so that the mess can be sorted out by the user. This is obviously meant to be useful for binary files. - 'merge=union' (this is the first example of a string valued attribute, introduced in the previous one) uses the "union" merge. The "union" merge takes lines in conflicted hunks from both sides, which is useful for line-oriented files such as .gitignore. Instead fo setting merge to 'true' or 'false' by using 'merge' or '-merge', setting it explicitly to "text" or "binary" will become useful once we start allowing custom per-path backends to be added, and allow them to be activated for the default (i.e. 'merge' attribute specified to 'true' or 'false') case, using some other mechanisms. Setting merge attribute to "text" or "binary" will be a way to explicitly request to override such a custom default for selected paths. Currently there is no way to specify random programs but it should be trivial for motivated contributors to add later. There is one caveat, though. ll_merge() is called for both internal ancestor merge and the outer "final" merge. I think an interactive custom per-path merge backend should refrain from going interactive when performing an internal merge (you can tell it by checking call_depth) and instead just call either ll_xdl_merge() if the content is text, or call ll_binary_merge() otherwise. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-17merge-recursive: separate out xdl_merge() interface.Libravatar Junio C Hamano1-21/+35
This just moves code around to make the actual call to xdl_merge() into a separate function. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10merge-recursive: handle D/F conflict case more carefully.Libravatar Junio C Hamano1-3/+26
When a path D that originally was blob in the ancestor was modified on our branch while it was removed on the other branch, we keep stages 1 and 2, and leave our version in the working tree. If the other branch created a path D/F, however, that path can cleanly be resolved in the index (after all, the ancestor nor we do not have it and only the other side added), but it cannot be checked out. The issue is the same when the other branch had D and we had renamed it to D/F, or the ancestor had D/F instead of D (so there are four combinations). Do not stop the merge, but leave both D and D/F paths in the index so that the user can clear things up. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10merge-recursive: do not barf on "to be removed" entries.Libravatar Junio C Hamano1-5/+11
When update-trees::threeway_merge() decides that a path that exists in the current index (and HEAD) is to be removed, it leaves a stage 0 entry whose mode bits are set to 0. The code mistook it as "this stage wants the blob here", and proceeded to call update_file_flags() which ended up trying to put the mode=0 entry in the index, got very confused, and ended up barfing with "do not know what to do with 000000". Since threeway_merge() does not handle case #10 (one side removes while the other side does not do anything), this is not a problem while we refuse to merge branches that have D/F conflicts, but when we start resolving them, we would need to be able to remove cache entries, and at that point it starts to matter. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07A new merge stragety 'subtree'.Libravatar Junio C Hamano1-0/+29
This merge strategy largely piggy-backs on git-merge-recursive. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. If you are pulling updates from git-gui repository into git.git repository, the root level of the former corresponds to git-gui/ subdirectory of the latter. The tree object of git-gui's toplevel is wrapped in a fake tree object, whose sole entry has name 'git-gui' and records object name of the true tree, before being used by the 3-way merge code. If you are merging the other way, only the git-gui/ subtree of git.git is extracted and merged into git-gui's toplevel. The detection of corresponding subtree is done by comparing the pathnames and types in the toplevel of the tree. Heuristics galore! That's the git way ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07Merge branch 'jc/index-output'Libravatar Junio C Hamano1-2/+2
* jc/index-output: git-read-tree --index-output=<file> _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file. Conflicts: builtin-apply.c
2007-04-05Fix bogus error message from merge-recursive error pathLibravatar Junio C Hamano1-1/+1
This error message should not usually trigger, but the function make_cache_entry() called by add_cacheinfo() can return early without calling into refresh_cache_entry() that sets cache_errno. Also the error message had a wrong function name reported, and it did not say anything about which path failed either. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-03_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.Libravatar Junio C Hamano1-2/+2
When defined, this allows plumbing commands that update the index (add, apply, checkout-index, merge-recursive, mv, read-tree, rm, update-index, and write-tree) to write their resulting index to an alternative index file while holding a lock to the original index file. With this, git-commit that jumps the index does not have to make an extra copy of the index file, and more importantly, it can do the update while holding the lock on the index. However, I think the interface to let an environment variable specify the output is a mistake, as shown in the documentation. If a curious user has the environment variable set to something other than the file GIT_INDEX_FILE points at, almost everything will break. This should instead be a command line parameter to tell these plumbing commands to write the result in the named file, to prevent stupid mistakes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31Keep rename/rename conflicts of intermediate merges while doing recursive mergeLibravatar Alex Riesen1-6/+31
This patch leaves the base name in the resulting intermediate tree, to propagate the conflict from intermediate merges up to the top-level merge. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-03Handle core.symlinks=false case in merge-recursive.Libravatar Johannes Sixt1-1/+2
If the file system does not support symbolic links (core.symlinks=false), merge-recursive must write the merged symbolic link text into a regular file. While we are here, fix a tiny memory leak in the if-branch that writes real symbolic links. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27convert object type handling from a string to a numberLibravatar Nicolas Pitre1-7/+7
We currently have two parallel notation for dealing with object types in the code: a string and a numerical value. One of them is obviously redundent, and the most used one requires more stack space and a bunch of strcmp() all over the place. This is an initial step for the removal of the version using a char array found in object reading code paths. The patch is unfortunately large but there is no sane way to split it in smaller parts without breaking the system. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-25merge-recursive: fix longstanding bug in merging symlinksLibravatar Junio C Hamano1-1/+1
Commit 3af244ca added unlink(2) before running symlink(2) to update the working tree with the merge result, but it was unlinking a wrong path. This resulted in loss of the path pointed by a symlink. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Use pretend_sha1_file() in git-blame and git-merge-recursive.Libravatar Junio C Hamano1-1/+1
git-merge-recursive wants an null tree as the fake merge base while producing the merge result tree. The null tree does not have to be written out in the object store as it won't be part of the result, and it is a prime example for using the new pretend_sha1_file() function. git-blame needs to register an arbitrary data to in-core index while annotating a working tree file (or standard input), but git-blame is a read-only application and the user of it could even lack the privilege to write into the object store; it is another good example for pretend_sha1_file(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Keep untracked files not involved in a merge.Libravatar Shawn O. Pearce1-1/+1
My earlier fix (8371234e) to delete renamed tracked files from the working directory also caused merge-recursive to delete untracked files that were in the working directory. The problem here is merge-recursive is deleting the working directory file without regard for which branch it was associated with. What we really want to do during a merge is to only delete files that were renamed by the branch we are merging into the current branch, and that are still tracked by the current branch. These files definitely don't belong in the working directory anymore. Anything else is either a merge conflict (already handled in other parts of the code) or a file that is untracked by the current branch and thus is not even participating in the merge. Its this latter class that must be left alone. For this fix to work we are now assuming that the first non-base argument passed to git-merge-recursive always corresponds to the working directory. This is already true for all in-tree callers of merge-recursive. This assumption is also supported by the long time usage message of "<base> ... -- <head> <remote>", where "<head>" is implied to be HEAD, which is generally assumed to be the current tree-ish. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-4/+4
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Convert output messages in merge-recursive to past tense.Libravatar Shawn O. Pearce1-18/+18
Now that we are showing the output messages for verbosity levels <5 after all actions have been performed (due to the progress meter running during the actions) it can be confusing to see messages in the present tense when the user is looking at a '100% done' message right above them. Converting the messages to past tense will appear more correct in this case, and shouldn't affect a developer who is debugging the application and running it at a verbosity level >=5. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Display a progress meter during merge-recursive.Libravatar Shawn O. Pearce1-7/+66
Because large merges on slow systems can take up to a minute to execute we should try to keep the user entertained with a progress meter to let them know how far we have progressed through the current merge. The progress meter considers each entry in the in-memory index to be a unit, which means a single recursive merge will double the number of units in the progress meter. Files which are unmerged after the 3-way tree merge are also considered a unit within the progress meter. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Enable output buffering in merge-recursive.Libravatar Shawn O. Pearce1-1/+39
Buffering all message output until a merge invocation is complete is necessary to prevent intereferring with a progress meter that would indicate the number of files completely merged, and how many remain. This change does not introduce a progress meter, but merely lays the groundwork to buffer the output. To aid debugging output buffering is only enabled if verbosity is lower than 5. When using verbosity levels above 5 the user is probably debugging the merge program itself and does not want to see the output delayed, especially if they are stepping through portions of the code in a debugger. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Allow the user to control the verbosity of merge-recursive.Libravatar Shawn O. Pearce1-38/+62
Junio C Hamano <junkio@cox.net> writes: > > I think the output from merge-recursive can be categorized into 5 > verbosity levels: > > 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict" > (outermost) > > 2. "Auto-merged successfully" (outermost) > > 3. The first "Merging X with Y". > > 4. outermost "Merging:\ntitle1\ntitle2". > > 5. outermost "found N common ancestors\nancestor1\nancestor2\n..." > and anything from inner merge. > > I would prefer the default verbosity level to be 2 (that is, show > both 1 and 2). and this change makes it so. I think level 3 is probably pointless as its only one line of output above level 2, but I can see how some users may want to view it but not view the slightly more verbose output of level 4. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Remove unnecessary call_depth parameter in merge-recursive.Libravatar Shawn O. Pearce1-9/+7
Because the output_indent always matches the call_depth value there is no reason to pass around the call_depth to the merge function during each recursive invocation. This is a simple refactoring that will make the code easier to follow later on as I start to add output verbosity controls. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12merge-recursive: do not report the resulting tree object nameLibravatar Junio C Hamano1-6/+3
It is not available in the outermost merge, and it is only useful for debugging merge-recursive in the inner merges. Sergey Vlasov noticed that the old code accesses an uninitialized location. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10merge-recursive: do not use on-file index when not needed.Libravatar Junio C Hamano1-123/+46
This revamps the merge-recursive implementation following the outline in: Message-ID: <7v8xgileza.fsf@assigned-by-dhcp.cox.net> There is no need to write out the index until the very end just once from merge-recursive. Also there is no need to write out the resulting tree object for the simple case of merging with a single merge base. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Speed-up recursive by flushing index only once for all entriesLibravatar Alex Riesen1-5/+2
The merge-recursive implementation in C inherited the invariant that the on-file index file is written out and later read back after any index operations and writing trees from the original Python implementation. But it was only because the original implementation worked at the scripting level. There is no need to write out the index file after handling every path. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08short i/o: fix calls to write to use xwrite or write_in_fullLibravatar Andy Whitcroft1-1/+1
We have a number of badly checked write() calls. Often we are expecting write() to write exactly the size we requested or fail, this fails to handle interrupts or short writes. Switch to using the new write_in_full(). Otherwise we at a minimum need to check for EINTR and EAGAIN, where this is appropriate use xwrite(). Note, the changes to config handling are much larger and handled in the next patch in the sequence. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Allow merging bare trees in merge-recursive.Libravatar Shawn O. Pearce1-0/+3
To support wider use cases, such as from within `git am -3`, the merge-recursive utility needs to accept not just commit-ish but also tree-ish as arguments on its command line. If given a tree-ish then merge-recursive will create a virtual commit wrapping it, with the subject of the commit set to the best name we can derive for that tree, which is either the command line string (probably the SHA1), or whatever string appears in GITHEAD_*. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Move better_branch_name above get_ref in merge-recursive.Libravatar Shawn O. Pearce1-12/+12
To permit the get_ref function to use the static better_branch_name function to generate a string on demand I'm moving it up earlier. The actual logic was not affected in this change. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-23Display 'theirs' branch name when possible in merge.Libravatar Shawn O. Pearce1-1/+16
Displaying the SHA1 of 'their' branch (the branch being merged into the current branch) is not nearly as friendly as just displaying the name of that branch, especially if that branch is already local to this repository. git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)' for each argument it gets passed, making the actual input name that resolved to the commit '%(sha1)' easily available to the invoked merge strategy. git-merge-recursive makes use of these environment variables when they are available by using '%(name)' whenever it outputs the commit identification rather than '%(sha1)'. This is most obvious in the conflict hunks created by xdl_merge: $ git mege sideb~1 <<<<<<< HEAD:INSTALL Good! ======= Oops. >>>>>>> sideb~1:INSTALL [jc: adjusted a test script and a minor constness glitch.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-23Use extended SHA1 syntax in merge-recursive conflicts.Libravatar Shawn O. Pearce1-2/+2
When we get a line-level conflict in merge-recursive and print out the two sides in the conflict hunk header and footer we should use the standard extended SHA1 syntax to specify the specific blob, as this allows the user to copy and paste the line right into 'git show' to view the complete version. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20Merge branch 'jc/clone'Libravatar Junio C Hamano1-1/+1
* jc/clone: Move "no merge candidate" warning into git-pull Use preprocessor constants for environment variable names. Do not create $GIT_DIR/remotes/ directory anymore. Introduce GIT_TEMPLATE_DIR Revert "fix testsuite: make sure they use templates freshly built from the source" fix testsuite: make sure they use templates freshly built from the source git-clone: lose the traditional 'no-separate-remote' layout git-clone: lose the artificial "first" fetch refspec git-pull: refuse default merge without branch.*.merge git-clone: use wildcard specification for tracking branches
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-7/+0
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Use preprocessor constants for environment variable names.Libravatar Junio C Hamano1-1/+1
We broke the discipline Linus set up to allow compiler help us avoid typos in environment names in the early days of git over time. This defines a handful preprocessor constants for environment variable names used in relatively core parts of the system. I've left out variable names specific to subsystems such as HTTP and SSL as I do not think they are big problems. Signed-off-by: Junio C Hamano <junkio@cox.net>