Why is the file I expect to be present missing after the final merge commit in Mercurial? - merge

I ran into a situation in Mercurial at work where I would expect a file to exist, but it doesn't and I'd like to better understand why. I've put together a repro of the issue. In this repro I would expect the file foo.txt to exist on default after the final merge, since one parent of the merge does not have the file present because it was removed earlier, and the other parent is adding it back because of a commit that happened after the commit that removed the file. Instead, the file remains deleted, why?
Here's an image of the sequence of commits:
And here's the actual commands to go from an empty directory, to having a Mercurial repo in this state.
hg init
echo foo > foo.txt
echo bar > bar.txt
hg add foo.txt bar.txt
hg commit -m "Add foo.txt and bar.txt"
hg branch feature
hg remove foo.txt
hg commit -m "Remove foo.txt"
echo barbar > bar.txt
hg commit -m "Modify bar.txt"
hg update default
echo baz > baz.txt
hg add baz.txt
hg commit -m "Add baz.txt"
hg update feature
hg merge default
hg commit -m "Merge default"
echo foo > foo.txt
hg add foo.txt
hg commit -m "Restore foo.txt"
hg update default
echo bazbaz > baz.txt
hg commit -m "Modify baz.txt"
hg update 0
hg merge 2
hg commit -m "Merge feature"
hg merge
hg commit -m "Merge"
hg merge feature
hg commit -m "Merge feature"
State of the working directory after the final merge:
> ls
bar.txt baz.txt
EDIT:
This appears to affect hg versions 5.9.3 and 6.3.2 but not 5.0.2
EDIT:
Based on discussion on the libera.chat #mercurial channel, modifying the sequence of commands in the repro to include an edit to the file after its creation does not change the outcome. foo.txt is still not present. https://gist.github.com/OneGeek/6fa5dcd4c2b3db6649310de1167449f9

I just pasted the steps from the repro into a terminal here and tried it (twice), and it doesn't reproduce the problem as described: foo.txt exists.
The end result is a working directory that has:
C:\Users\abcde\source\test>dir
...
Directory of C:\Users\abcde\source\test
01/29/2023 04:08 PM <DIR> .
01/29/2023 04:07 PM <DIR> ..
01/29/2023 04:08 PM <DIR> .hg
01/29/2023 04:07 PM 0 .hgignore
01/29/2023 04:08 PM 9 bar.txt
01/29/2023 04:08 PM 9 baz.txt
01/29/2023 04:08 PM 6 foo.txt
4 File(s) 24 bytes
The graph in THG looks the same as in the question.
I happen to be using HG 5.0.2 on Windows.

Related

create a commit of changes between two branches

I created branch br1 from default a few months back. I have been committing and pushing changes to br1 since then. Every now and then pulling in changes from default as follows:
hg up br1
hg merge default
// create a commit, push
I want to create a commit message of all the changes I made to br1 over the last few months. branch br1 and default are clean in my workspace, aka no uncommitted changes, no un-pushed commit. At this point, br1 is out of sync with default by 1 week. I did the following steps:
hg up default
hg merge br1
// At this point, "hg stat" shows files that I did not modify in br1. :(
// So, if I created a commit message at this point, it would be no good.
// I am not sure why these addition file modifications showed up.
I figured the issue might be because br1 is out of sync from default by a week. I performed the following set of steps in a clean workspace:
hg up br1
hg merge default
// created a commit -**ch1**, but did **NOT push**
hg up default
hg merge br1
// At this point, "hg stat" shows the same additional files as my pervious
// attempt. :(
Question:
- Does "hg merge" disregards commit that are not pushed?
- Do I need to push ch1 for these additional files to not to show up? Is this the reason for the additional files showing up when do a "hg merge br1"?
- Is there a way I can tell hg to take the ch1 into account when doing the merge from br1.
Thank you,
Ahmed.
well, since you didn't provide a working example, I'll have to build one from scratch, so forgive me for the bunch of command lines below
explanation at the end, because only makes sense if you follow the example steps
preparing the stage
# create a new dir an initialize the repository
mkdir hgtrial
cd hgtrial
hg init
# create an empty file and make first commit on default branch
echo . > dummy.txt
hg add dummy.txt
hg commit -m "1st commit"
# add info and make a second commmit also on default branch
echo abc >> dummy.txt
hg commit -m "2nd commit"
# create a new branch and make an empty commit on it
hg branch br1
hg commit -m "my new branch"
# work on br1
echo def >> dummy.txt
hg commit -m "def on br1"
# work on default (make br1 out of sync)
hg up default
echo ghi >> dummy.txt
hg commit -m "ghi on default"
echo jkl >> dummy.txt
hg commit -m "jkl on default"
# sync br1 by pulling default
hg up br1
hg merge default
# solve merge conflicts (abc def ghi jkl)
hg commit -m "br1 <- default"
# continue working on br1 (without touching dummy.txt)
echo 123 > another.txt
hg add another.txt
hg commit -m "another file"
echo 456 >> another.txt
hg commit -m "456"
# work on default (make br1 out of sync)
hg up default
echo yes-yes > one-more.txt
hg add one-more.txt
hg commit -m "yes-yes, on default"
echo no-no >> one-more.txt
hg commit -m "no-no, on default"
now the issue (notice we are standing on default branch)
# now the problem (scenario 1)
hg merge br1
hg stat
# dummy.txt is modified, trying to bring "def" from br1 into default
# abort
# checkout clean br1 (drop merge in progress)
hg up -C br1
hg merge default
hg commit -m "br1 <- default"
# the problem again (scenario 2)
hg up default
hg merge br1
hg stat
# dummy.txt is modified, trying to bring "def" from br1 into default
# SAME THING!
why?
because at some point "def" change was made in br1 and default never knew about it, so even when you haven't touch dummy.txt in a long while, you have synced default into br1, but no the other way around, therefore default has a lot to catch up with
EDIT: added screenshot with this scenario in TortoiseHg

Mercurial show diff against 2 parents or base during merge

Our teem recently faced with merge that removes one leaf of merge and we "lost" changes (as if you perform hg merge --tool internal:local).
This happen because we don't experienced with hg merge command.
hg diff shown only one difference, but not other.
BASE --- HEAD1 --- MERGE
\---- HEAD2 --/
Suppose in HEAD1 I merge HEAD2 but has not yet commit changes.
HEAD2 diff against MERGE I see by hg diff. It is -r BASE:HEAD2 patch.
How can I see diff between current local merge state with HEAD1 as if we merge from HEAD2
How can I see diff between current local merge state with BASE?
Thanks #Vince for suggestion. I reread hg help diff and hg help revset and get that I want.
Assume that you at MERGE before commit and perform merge from HEAD1.
To compare diff against HEAD1 use one of:
hg diff
hg diff -r .
hg diff -r HEAD1
Check:
hg log -r .
To compare diff against HEAD1 use one of:
hg diff -r HEAD2
If you have only 2 heads in current branch last expression can be written without HEAD2 name:
hg diff -r 'branch(.) & head() - .'
Check:
hg log -r 'branch(.) & head() - .'
To compare against BASE:
hg log -r 'ancestor(HEAD1, HEAD2)'
If you have only 2 heads in current branch last expression can be written without HEAD1/HEAD2 names::
hg diff -r 'ancestor(branch(.) & head())'
Check:
hg log -r 'ancestor(branch(.) & head())'
I wander if there are any shortcut for second parent of current merge. For first - just dot sign...
UPDATE Hm... p1() and p2() are awesome! I rewrote my examples in way that they have no concrete names HEAD1/HEAD2:
hg diff -r 'p1()'
hg diff -r 'p2()'
hg diff -r 'ancestor(p1(), p2())'

What does hg copy do?

We recently did a hg copy of a directory in our repository. We thought it
does something like cp -a and hg add and maybe flag somehow that
this file has been copied from another file inside the repo (so hg
annotate shows the original committer). But it now seems that hg
copy does more or different stuff than that. I couldn't really find
much on how exactly copy works. So:
What exactly does hg copy do and what special treatment does this
cause in the future?
If it turns out to do "the wrong thing(tm)" for our case, how do I
unflag the file as beeing a copy of another file?
(This question was asked on the Mercurial mailinglist, you may want to follow the original thread too.)
What exactly does hg copy do and what special treatment does this
cause in the future?
It adds new files and marks them as copies of the old files. Because they are copies, a change made in the original file will be merged into copy. Time flows from left to right:
(init) --- (edit a.txt) ---- (a.txt edit is copied to b.txt)
\ /
(hg copy a.txt b.txt)
If it turns out to do 'the wrong thing(tm)' for our case, how do I
unflag the file as beeing a copy of another file?
This mechanism only kicks in when you merge. If b.txt is not present in the
common ancestor revision (init in the above graph), then Mercurial will
do a search backwards to see if b.txt is copied from somewhere else.
Let us continue the above graph in abbreviated form:
(i) -- (edit a) -- (a edit copied to b) -- (edit a) -- (merge)
\ / /
(copy a b) --/------- (edit b) ------------------/
The question is how the final merge is done. The common ancestor point
is now the copy a b node and here both a and b are present. This means
that there wont be any search for copies! So the second edit to a wont
be merged into b.
To double-check, I tried it out:
$ hg init
$ echo a > a
$ hg add a
$ hg commit -m init
$ hg copy a b
$ hg commit -m "copy a b"
This was the copy, b now contains a only.
$ hg update 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo aa >> a
$ hg commit -m "edit a"
created a new head
$ hg merge
merging a and b to b
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m "a edit copied to b"
This was the first merge and the edit to a has been copied into b:
$ cat b
a
aa
We now make changes in parallel:
$ echo aaa >> a
$ hg commit -m "edit a again"
$ hg update 3
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo bbb >> b
$ hg commit -m "edit b"
created new head
$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
There are no further copying done:
$ cat a
a
aa
aaa
$ cat b
a
aa
bbb
As for disabling this... you can't really explicitly disable the copy
detection. But as I hope to have illustrated above, it wont "bother" you
again after the first merge.
If the first merge is a problem, then you can use hg resolve --tool
internal:local to reset the files back to their state before you
started the merge. So with
$ hg resolve --tool internal:local b
we could have brought b back to just containing one line with a.
How do I unflag the file as being a copy of another file?
If you revert a hg copy, the copied-to file remains in your working directory afterwards, untracked. You just have to add it normally.
The copied-from file isn't affected at all.
% hg copy file new-file
% hg status -C
A new-file
__file
% hg revert new-file
% hg add new-file
% hg status -C
A new-file
Reference: Mercurial: The definitive guide

Mercurial: Converting existing folders into sub-repos

I have a Mercurial repository that looks like this:
SWClients/
SWCommon
SWB
SWNS
...where SWCommon is a a library common to the other two projects. Now, I want to convert SWCommon into a sub-repository of SWClients, so I followed the instructions here and here. However, in contrast to the example in the first link I want my sub-repository to have the same name as the folder had at the beginning. In detail, this is what I have done:
Create a file map.txt as follows
include SWCommon
rename SWCommon .
Create a file .hgsub as follows
SWCommon = SWCommon
Then run
$ hg --config extensions.hgext.convert= convert --filemap map.txt . SWCommon-temp
...lots of stuff happens...
Then
$ cd SWCommon-temp
$ hg update
101 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ..
$ mv SWCommon SWCommon-old
$ mv SWCommon-temp SWCommon
$ hg status
abort: path 'SWCommon/SWCommon.xcodeproj/xcuserdata/malte.xcuserdatad/xcschemes/SWCommon.xcscheme' is inside nested repo 'SWCommon'
...which is indeed the case, but why is that a reason to abort? The other strange thing is that if I do not do that last 'mv' above and I execute an 'hg status' then, I end up with lots of 'missing' files in SWCommon as you would expect. The example in the link never makes it this far and basically stops on the hg update above? How do you make it work in practice?
Not currently possible. You could create a new repo converting the original one like:
$ hg --filemap excludemap.txt SWClients SWClients-without-SWCommon
With a excludemap.txt like:
exclude "SWCommon"
And then add the subrepo there.
$ hg --filemap map.txt SWCommon SWClients-without-SWCommon/SWCommon
$ cd SWClients-without-SWCommon
$ hg add SWCommon
$ hg ci -m "Created subrepo"
See the mailing list thread that discusses this problem.

Mercurial: multiline commit message on the command line?

How can I specify a multiline commit message for mercurial on the command line?
hg commit -m "* add foo\n* fix bar"
does not work. The log shows:
changeset: 13:f2c6526e5911
tag: tip
date: Fri Jan 23 23:22:36 2009 +0100
files: foobar.cpp
description:
* add foo\n*fix bar
Mercurial: multiline commit message on
the command line?
Hit enter.
$ hg commit -m "Did some work
> Now I'm done"
One of the things is that only the first line shows up in hg log:
$ hg log
changeset: 0:d2dc019450a2
tag: tip
user: Aaron Maenpaa <zacherates#gmail.com>
date: Sat Jan 24 07:46:23 2009 -0500
summary: Did some work
... but if you fire up "hg view" you can see that the whole message is there.
Edited to add:
... but hg -v log shows the whole message:
$ hg -v log
changeset: 0:d2dc019450a2
tag: tip
user: Aaron Maenpaa <zacherates#gmail.com>
date: Sat Jan 24 07:46:23 2009 -0500
files: work
description:
Did some work
Now I'm done
From Windows cmd, do this command for a multiline commit.
hg commit -l con
This allows you to enter a multiple line commit message straight from the command line. To end your message, hit Enter, and on a line by itself hit Ctrl + Z and Enter again.
Why? The -l option to hg commit says to read the commit message from a file, and con specifies that the file is actually the console.
If you're doing it interactively (vs. from a script), just do hg commit without the -m flag. I'm not sure what the behavior is on Linux or Mac, but on Windows it pops up Notepad with a file that you fill out and save for a multiline message.
I know, there is already a solution for linux users, but I needed another solution for windows command line, so I was looking for it...
And I found one:
https://www.mercurial-scm.org/pipermail/mercurial/2011-November/040855.html
hg commit -l filename.txt
I hope, it's useful for someone out there ,)
[EDIT]
oO - it has already been added to the help
-l --logfile FILE read commit message from file
Here's another way that is more close to what you tried at first:
hg commit -m "$(echo -e 'foo\nbar')"
In bash (since version 2.0):
hg commit -m $'foo\nbar'
(I.e. put a dollar sign before an opening single quote to make it parse escape sequences (like \n) within the string — note that it doesn't work with double quotes.)
For Windows with PowerShell:
hg commit --message "foo`nbar"