summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-03-24diff --check: honor conflict-marker-size attributeLibravatar Junio C Hamano2-14/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-17rerere: honor conflict-marker-size attributeLibravatar Junio C Hamano3-2/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-17rerere: prepare for customizable conflict marker lengthLibravatar Junio C Hamano1-10/+44
This still uses the hardcoded conflict marker length of 7 but otherwise prepares the codepath to deal with customized marker length. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16conflict-marker-size: new attributeLibravatar Junio C Hamano1-25/+34
This can be specified to set the length of the conflict marker (usually 7) to a non-default value per path. Only the callers of ll_merge() that are aware of the per-path attributes are modified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16rerere: use ll_merge() instead of using xdl_merge()Libravatar Junio C Hamano1-4/+1
This allows us to pay attention to the attribute settings and custom merge driver the user sets up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16merge-tree: use ll_merge() not xdl_merge()Libravatar Junio C Hamano2-11/+9
ll_merge() interface was designed to merge contents under git control while taking per-path attributes into account. Update the three-way merge implementation used by merge-tree to use it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16xdl_merge(): allow passing down marker_size in xmparam_tLibravatar Junio C Hamano2-8/+18
This allows the callers of xdl_merge() to pass marker_size (defaults to 7) in xmparam_t argument, to use conflict markers of non-default length. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16xdl_merge(): introduce xmparam_t for merge specific parametersLibravatar Junio C Hamano6-12/+17
So far we have only needed to be able to pass an option that is generic to xdiff family of functions to this function. Extend the interface so that we can give it merge specific parameters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16git_attr(): fix function signatureLibravatar Junio C Hamano9-14/+19
The function took (name, namelen) as its arguments, but all the public callers wanted to pass a full string. Demote the counted-string interface to an internal API status, and allow public callers to just pass the string to the function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10rerere forget path: forget recorded resolutionLibravatar Junio C Hamano4-0/+161
After you find out an earlier resolution you told rerere to use was a mismerge, there is no easy way to clear it. A new subcommand "forget" can be used to tell git to forget a recorded resolution, so that you can redo the merge from scratch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10rerere: refactor rerere logic to make it independent from I/OLibravatar Junio C Hamano1-35/+76
This splits the handle_file() function into in-core part and I/O parts of the logic to create the preimage, so that we can compute the conflict identifier without having to use temporary files. Earlier, I thought the output from handle_file() should also be refactored, but it is always about writing preimage (or thisimage) that is used for later three-way merge, so it is saner to keep it to always write to FILE *. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25rerere: remove silly 1024-byte line limitLibravatar Junio C Hamano1-9/+10
Ever since 658f365 (Make git-rerere a builtin, 2006-12-20) rewrote it, it kept this line-length limit regression, even after we started using strbuf in the same function in 19b358e (Use strbuf API in buitin-rerere.c, 2007-09-06). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: teach "update-index --unresolve" to use resolve-undo infoLibravatar Junio C Hamano3-1/+20
The update-index plumbing command had a hacky --unresolve implementation that was written back in the days when merge was the only way for users to end up with higher stages in the index, and assumed that stage #2 must have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute the stage #1 information. There were several issues with this approach: - These days, merge is not the only command, and conflicts coming from commands like cherry-pick, "am -3", etc. cannot be recreated by looking at MERGE_HEAD; - For a conflict that came from a merge that had renames, picking up the same path from MERGE_HEAD and HEAD wouldn't help recreating it, either; - It may have been Ok not to recreate stage #1 back when it was written, because "diff --ours/--theirs" were the only availble ways to review conflicts and they don't need stage #1 information. "diff --cc" that was invented much later is a lot more useful way but it needs stage #1. We can use resolve-undo information recorded in the index extension to solve all of these issues. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: "checkout -m path" uses resolve-undo informationLibravatar Junio C Hamano5-0/+77
Once you resolved conflicts by "git add path", you cannot recreate the conflicted state with "git checkout -m path", because you lost information from higher stages in the index when you resolved them. Since we record the necessary information in the resolve-undo index extension these days, we can reproduce the unmerged state in the index and check it out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: allow plumbing to clear the informationLibravatar Junio C Hamano2-0/+17
At the Porcelain level, operations such as merge that populate an initially cleanly merged index with conflicted entries clear the resolve-undo information upfront. Give scripted Porcelains a way to do the same, by implementing "update-index --clear-resolve-info". With this, a scripted Porcelain may "update-index --clear-resolve-info" first and repeatedly run "update-index --cacheinfo" to stuff unmerged entries to the index, to be resolved by the user with "git add" and stuff. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: basic testsLibravatar Junio C Hamano2-1/+130
Make sure that resolving a failed merge with git add records the conflicted state, committing the result keeps that state, and checking out another commit clears the state. "git ls-files" learns a new option --resolve-undo to show the recorded information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: record resolved conflicts in a new index extension sectionLibravatar Junio C Hamano8-1/+160
When resolving a conflict using "git add" to create a stage #0 entry, or "git rm" to remove entries at higher stages, remove_index_entry_at() function is eventually called to remove unmerged (i.e. higher stage) entries from the index. Introduce a "resolve_undo_info" structure and keep track of the removed cache entries, and save it in a new index extension section in the index_state. Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and "reset" are signs that recorded information in the index is no longer necessary. The data is removed from the index extension when operations start; they may leave conflicted entries in the index, and later user actions like "git add" will record their conflicted states afresh. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25builtin-merge.c: use standard active_cache macrosLibravatar Junio C Hamano1-3/+2
Instead of using the low-level index_state interface, use the bog standard active_cache and active_nr macros to access the cache entries when using the default one. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-23Git 1.6.6Libravatar Junio C Hamano3-4/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-23git svn: add test for a git svn gc followed by a git svn mkdirsLibravatar Robert Zeh1-0/+40
git svn gc will compress the unhandled.log files that git svn mkdirs reads, causing git svn mkdirs to skip directory creation. [ew: trivial whitespace cleanups] Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
2009-12-23git svn: branch/tag commands detect username in URLsLibravatar Eric Wong1-1/+2
svn+ssh:// repositories often have userinfo embedded in the URL which were stripped out of the "git-svn-id:" trailers. Since the SVN::Client::copy function takes userinfo into account when matching URLs for SVN repositories, we need to retrieve the full URL with embedded userinfo in it to avoid mismatched URLs. Tested-by: Florian Köberle <florian@fkoeberle.de> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-22Merge branch 'maint'Libravatar Junio C Hamano2-3/+23
* maint: Prevent git blame from segfaulting on a missing author name
2009-12-22git svn: lookup new parents correctly from svn:mergeinfoLibravatar Eric Wong1-1/+2
This appears to be a trivial case where array indices were being passed to git rev-list, instead of the contents stored in the array itself. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-22Prevent git blame from segfaulting on a missing author nameLibravatar David Reiss2-3/+23
The human-readable author and committer name can be missing from commits imported from foreign SCM interfaces. Make sure we parse the "author" and "committer" line a bit more leniently and avoid segfaulting by assuming the name always exists. Signed-off-by: David Reiss <dreiss@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-21git-svn: Remove obsolete MAXPARENT checkLibravatar Andrew Myrick1-6/+0
Change git-svn not to impose a limit of 16 parents on a merge. This limit in git-svn artificially prevents cloning svn repositories that contain commits with more than 16 merge parents. The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it it in git-svn. Signed-off-by: Andrew Myrick <amyrick@apple.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: detect cherry-picks correctly.Libravatar Sam Vilain2-25/+66
The old function was incorrect; in some instances it marks a cherry picked range as a merged branch (because of an incorrect assumption that 'rev-list COMMIT --not RANGE' would work). This is replaced with a function which should detect them correctly, memoized to limit the expense of dealing with branches with many cherry picks to one 'merge-base' call per merge, per branch which used cherry picking. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: exclude already merged tips using one rev-list callLibravatar Sam Vilain1-4/+48
The old function would have to check all mentioned merge tips, every time that the mergeinfo ticket changed. This involved 1-2 rev-list operation for each listed mergeinfo line. If there are a lot of feature branches being merged into a trunk, this makes for a very expensive operation for detecting the new parents on every merge. This new version first uses a single 'rev-list' to figure out which commit ranges are already reachable from the parents. This is used to eliminate the already merged branches from the list. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: fix some mistakes with interpreting SVN mergeinfo commit rangesLibravatar Sam Vilain2-10/+4
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas git commit ranges are exclusive on the left hand side. Also, the end points of the commit ranges may not exist; they simply delineate ranges of commits which may or may not exist. Fix these two mistakes. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: memoize conversion of SVN merge ticket info to git commit rangesLibravatar Sam Vilain1-37/+54
Each time the svn mergeinfo ticket changes, we look it up in the rev_map; when there are a lot of merged branches, this will result in many repeated lookups of the same information for subsequent commits. Arrange the slow part of the function so that it may be memoized, and memoize it. The more expensive revision walking operation can be memoized separately. [ew: changed "next" to "return" for function exit] Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: expand the svn mergeinfo test suite, highlighting some failuresLibravatar Sam Vilain3-172/+860
As shown, git-svn has some problems; not all svn merges are correctly detected, and cherry picks may incorrectly be detected as real merges. These test cases will be marked as _success once the relevant fixes are in. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21update release notes for git svn in 1.6.6Libravatar Eric Wong1-0/+2
Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git svn: fix --revision when fetching deleted pathsLibravatar Eric Wong1-1/+5
When using the -r/--revision argument to fetch deleted history, calling SVN::Ra::get_log() from an SVN::Ra object initialized to track the deleted URL will fail. This regression was introduced in: commit 4aacaeb3dc82bb6479e70e120053dc27a399460e "fix shallow clone when upstream revision is too new" We now ignore errors from SVN::Ra::get_log() here because using --revision will always override the value of $head here if (and only if) we're tracking deleted directories. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-20Git 1.6.6-rc4Libravatar Junio C Hamano2-8/+9
Hopefully the last rc before the final one. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-19Merge branch 'maint'Libravatar Junio C Hamano3-5/+57
* maint: rebase -i: abort cleanly if the editor fails to launch technical-docs: document hash API api-strbuf.txt: fix typos and document launch_editor()
2009-12-19rebase -i: abort cleanly if the editor fails to launchLibravatar Björn Gustavsson1-1/+1
If the user's configured editor is emacsclient, the editor will fail to launch if emacs is not running and the git command that tried to lanuch the editor will abort. For most commands, all you have to do is to start emacs and repeat the command. The "git rebase -i" command, however, aborts without cleaning the "$GIT_DIR/rebase-merge" directory if it fails to launch the editor, so you'll need to do "git rebase --abort" before repeating the rebase command. Change "git rebase -i" to terminate using "die_abort" (instead of with "die") if the initial launch of the editor fails. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-19t9146: use 'svn_cmd' wrapperLibravatar Eric Wong1-1/+1
Using 'svn' directly may not work for all users. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-19git svn: make empty directory creation gc-awareLibravatar Eric Wong2-11/+58
The "git svn gc" command creates and appends to unhandled.log.gz files which should be parsed before the uncompressed unhandled.log files. Reported-by: Robert Zeh Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-17technical-docs: document hash APILibravatar Stephen Boyd1-2/+48
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-17api-strbuf.txt: fix typos and document launch_editor()Libravatar Stephen Boyd1-2/+8
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16Git 1.6.6-rc3Libravatar Junio C Hamano2-7/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16Merge branch 'maint' to sync with 1.6.5.7Libravatar Junio C Hamano10-8/+91
* maint: Git 1.6.5.7 worktree: don't segfault with an absolute pathspec without a work tree ignore unknown color configuration help.autocorrect: do not run a command if the command given is junk Illustrate "filter" attribute with an example
2009-12-16Git 1.6.5.7Libravatar Junio C Hamano4-3/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16worktree: don't segfault with an absolute pathspec without a work treeLibravatar Junio C Hamano2-2/+20
If a command is run with an absolute path as a pathspec inside a bare repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen() on NULL, which is the result of get_git_work_tree(), and segfaulted. It should just fail instead. Currently the function returns NULL even inside .git/ in a repository with a work tree, but that is a separate issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16ignore unknown color configurationLibravatar Jeff King4-3/+26
When parsing the config file, if there is a value that is syntactically correct but unused, we generally ignore it. This lets non-core porcelains store arbitrary information in the config file, and it means that configuration files can be shared between new and old versions of git (the old versions might simply ignore certain configuration). The one exception to this is color configuration; if we encounter a color.{diff,branch,status}.$slot variable, we die if it is not one of the recognized slots (presumably as a safety valve for user misconfiguration). This behavior has existed since 801235c (diff --color: use $GIT_DIR/config, 2006-06-24), but hasn't yet caused a problem. No porcelain has wanted to store extra colors, and we once a color area (like color.diff) has been introduced, we've never changed the set of color slots. However, that changed recently with the addition of color.diff.func. Now a user with color.diff.func in their config can no longer freely switch between v1.6.6 and older versions; the old versions will complain about the existence of the variable. This patch loosens the check to match the rest of git-config; unknown color slots are simply ignored. This doesn't fix this particular problem, as the older version (without this patch) is the problem, but it at least prevents it from happening again in the future. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-15help.autocorrect: do not run a command if the command given is junkLibravatar Johannes Sixt1-2/+5
If a given command is not found, then help.c tries to guess which one the user could have meant. If help.autocorrect is 0 or unset, then a list of suggestions is given as long as the dissimilarity between the given command and the candidates is not excessively high. But if help.autocorrect was non-zero (i.e., a delay after which the command is run automatically), the latter restriction on dissimilarity was not obeyed. In my case, this happened: $ git ..daab02 WARNING: You called a Git command named '..daab02', which does not exist. Continuing under the assumption that you meant 'read-tree' in 4.0 seconds automatically... The patch reuses the similarity limit that is also applied when the list of suggested commands is printed. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-14Illustrate "filter" attribute with an exampleLibravatar Nanako Shiraishi1-0/+19
The example was taken from aa4ed402c9721170fde2e9e43c3825562070e65e (Add 'filter' attribute and external filter driver definition). Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-12bash: Support new 'git fetch' optionsLibravatar Björn Gustavsson1-2/+12
Support the new options --all, --prune, and --dry-run for 'git fetch'. As the --multiple option was primarily introduced to enable 'git remote update' to be re-implemented in terms of 'git fetch' (16679e37) and is not likely to be used much from the command line, it does not seems worthwhile to complicate the code (to support completion of multiple remotes) to handle it. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Update Release Notes for 1.6.6 to remove old bugfixesLibravatar Junio C Hamano1-16/+0
These three have already been backported to 1.6.5.5 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Sync with 1.6.5.6Libravatar Junio C Hamano7-179/+37
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Git 1.6.5.6Libravatar Junio C Hamano4-3/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>