Wed, 03 Dec 2014 14:03:20 -0800 merge: make 'keep' message more descriptive
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 14:03:20 -0800] rev 23482
merge: make 'keep' message more descriptive Most merge action messages don't describe the action itself, they describe the reason the action was taken. The only exeption is the 'k' action, for which the message is just "keep" and instead there is a code comment folling it that says "remote unchanged". Let's move that comment into the merge action message.
Thu, 04 Dec 2014 23:08:27 -0500 addremove: restore the relative path printing when files are named
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:08:27 -0500] rev 23481
addremove: restore the relative path printing when files are named This fixes the previously mentioned issue with 3778884197f0, and undoes its corresponding test change. The test change demonstrates the correctness when a file is specified (i.e. the glob is required on Windows because relative paths use '\' and absolute paths use '/'). It is admittedly very subtle, but there will be a more robust test in the addremove -S v3 series.
Thu, 04 Dec 2014 23:04:55 -0500 match: introduce uipath() to properly style a file path
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:04:55 -0500] rev 23480
match: introduce uipath() to properly style a file path Several methods print files relative to the repo root, unless files are named on the command line, in which case they are printed relative to cwd. Since the check relies on the 'pats' parameter, which needs to be replaced by a matcher when adding subrepo support, this logic gets folded into the matcher to tidy up the callers. Prior to 3778884197f0, this style decision was based off of whether or not the 'pats' list was empty. That change altered the check to test match.anypats() instead, in order to make paths printed consistent when -I/-X is specified. That however, changed the style when a file is given to the command. So now we test the pattern list to get the old behavior for files, as well as test -I/-X to get the consistency for patterns.
Fri, 05 Dec 2014 12:10:56 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 05 Dec 2014 12:10:56 -0600] rev 23479
merge with stable
Sun, 16 Nov 2014 23:41:44 -0800 update: don't overwrite untracked ignored files on update stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 16 Nov 2014 23:41:44 -0800] rev 23478
update: don't overwrite untracked ignored files on update When looking for untracked files that would conflict with a tracked file in the target revision (or the remote side of a merge), we explcitly exclude ignored files. The code was added in 7e30f5f2285f (merge: refactor unknown file conflict checking, 2012-02-09), but it seems like only unknown, not ignored, files were considered since the beginning of time. Although ignored files are mostly build outputs and backup files, we should still not overwrite them. Fix by simply removing the explicit check.
Tue, 02 Dec 2014 17:11:01 -0800 update: add tests for untracked local file stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 17:11:01 -0800] rev 23477
update: add tests for untracked local file We don't seem to have any tests for updating to another revision when there are untracked files on the local side that conflict with the those on the remote side, so let's add tests. This shows how we overwrite untracked ignored files when updating to a revision that tracks the file.
Wed, 03 Dec 2014 11:02:52 -0800 merge: don't overwrite conflicting file in locally renamed directory
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 11:02:52 -0800] rev 23476
merge: don't overwrite conflicting file in locally renamed directory When the local side has renamed a directory from a/ to b/ and added a file b/c in it, and the remote side has added a file a/c, we end up overwriting the local file b/c with the contents of remote file a/c. Add a check for this case and use the merge ('m') action in this case instead of the directory rename get ('dg') action.
Wed, 03 Dec 2014 10:56:07 -0800 merge: don't ignore conflicting file in remote renamed directory
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 10:56:07 -0800] rev 23475
merge: don't ignore conflicting file in remote renamed directory When the remote side has renamed a directory from a/ to b/ and added a file b/c in it, and the local side has added a file a/c, we end up moving a/c to b/c without considering the remote version of b/c. Add a check for this case and use the merge ('m') action in this case instead of the directory rename ('dm') action.
Sun, 23 Nov 2014 15:08:50 -0800 merge: duplicate 'if f in copied' into each branch
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 15:08:50 -0800] rev 23474
merge: duplicate 'if f in copied' into each branch
Sun, 23 Nov 2014 14:09:10 -0800 merge: branch code into {n1 and n2, n1, n2} top-level cases
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 14:09:10 -0800] rev 23473
merge: branch code into {n1 and n2, n1, n2} top-level cases There are three high-level cases that are of interest in manifestmerge(): 1) The file exists on both sides, 2) The file exists only on the local side, and 3) The file exists only on the remote side. Let's make this clearer in the code. The 'if f in copied' case will be broken up into the two applicable branches in the next patch.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip