Change order of lines in .hgtags to alleviate merge conflicts?

Jason Harris jason at jasonfharris.com
Sun Apr 3 11:32:32 CDT 2011


On Apr 3, 2011, at 5:32 PM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
>> Hi All,
>> 
>> What would people think about changing the 'hg tag <tagname>' command
>> so that it inserted the tags in the list of tags according to the
>> changeset hash or according to the tag name.
> 
> I don't think you are aware that the .hgtags files are read from all
> heads and then merged before you see the output of 'hg tags'?
> 
> This merging uses the order of the lines in the .hgtags file and it
> described briefly here:
> 
>  http://mercurial.selenic.com/wiki/Tag#How_do_tags_work_with_multiple_heads.3F
> 
> 
> Instead of sorting the lines as you suggest, I think we should let
> Mercurial merge the .hgtags files itself, probably using the algorithm
> it already uses when merging the .hgtags files read from different
> heads. So if I do
> 
>  $ hg update branch-x
>  $ hg tag x-1.0
>  $ hg update brancy-y
>  $ hg tag y-2.0
> 
> then there is no problem -- Mercurial easily merges the two .hgtags
> files from the two heads. But if I now do
> 
>  $ hg merge branch-x
> 
> I'm bound to get an unnecessary merge conflict.
> 
> I think it is only the case shown in the first figure on the wiki page
> that should result in a genuine conflict: when two heads add conflicting
> tags.


Hi Martin!

The case I am talking about is this one:

hg init show-conflict
cd show-conflict/
echo start > file.txt
hg commit -A -m "initial commit"
hg tag first -m "add first tag"
cd ..
hg clone show-conflict other-show-conflict
cd other-show-conflict/
echo other > other.txt
hg commit -A -m "commit other"
hg tag other -m "add tag other"
cd ../clone show-conflict
echo flamingo > flamingo.txt
hg tag flamingo -m "add tag flamingo"
hg pull ../other-show-conflict
hg merge

this gives:

merging .hgtags
warning: conflicts during merge.
merging .hgtags failed!
1 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon

[Bolt:~/test2/show-conflict] show-conflict 3(5) ⌘ more .hgtags
ebd2ea76edb83078cec3d7e2f832bc5511214006 first
<<<<<<< local
b5d24a2b642f4f3b7fd40c133b03c5dbe00e52c1 flamingo
=======
ee03beaaf3eb8e7be37ffa28dfe4c375c640c220 other
>>>>>>> other

There will always be a merge conflict in such cases with the way we presently do things. If we do as greg suggests and have a 'internal:tags' and its easy to write well that would be great...

I just thought that pruning previous versions of a tag and alphabetizing by tag name was dead simple to implement and would improve merge conflicts right now (unless there was some problem with this...) and well...  finally you pointed out that 'the multiple-head tag collision resolution algorithm' is sort of dependent on this tag redundancy on different branches...

So now that I understand this algorithm here, I would change my proposal to: If two tags are on the same linear branch then you can delete the older tag and alphabetize. If the tags have been added on different branches, then you would just keep the old duplicates and append the tag with the same name to the end of the mini group of tag lines with the same tag name.

(Just ton confirm: I just want to be clear here that if you have the tag falmingo on 3 different branches like so:

.hgtags:
hash1 flamingo
hash2 flamingo
hash3 flamingo

and then if we do some  'hg update -r flamingo'  then Mercurial can't just take the last item in the list of tag lines in the .hgtags file (ie hash3). But instead mercurial has to figure out the deepest descendent of hash1, hash2, and hash3, and then it uses that. Eg if the deepest head of hash1 was 354, and the deepest head of hash2 was 563, and the deepest head of hash3 was 432, then -r flamingo would refer to hash2? Is that right? I had a quick glance at the code but it wasn't immediately obvious to me where this was happening...)

(Just offhand, it strikes me. that this seems a bit complex, I would have naively thought that just using the last relevant tag line of the .hgtags would be used... But then again it wouldn't do to go changing this behavior now.)

Thanks,
  Jas


More information about the Mercurial-devel mailing list