Unwanted branch won't go away

[GeorgianaOnline]

Hi,

My partner and I are using TortoiseHg for source control. He somehow managed to branch his changes. I don't know how exactly. He says he just committed his changes and pulled mine and it branched. Seriously, I have no idea how he manages these things. I use the Workbench day in and day out with little issue.

Anyway, we very rarely work on the same files at the same time. We have no need for branches, and it just causes confusion and frustration having to deal with them. (He keeps having to make backups of his changes because we've accidentally wiped them out somehow more than once.) My goal in life is to have him NOT confused and frustrated by source control, which should be dead simple for us.

I have merged back to the main branch and committed, and still every time he pulls it branches his code. HOW DO I GET IT TO STOP THIS??? I've tried going to Options when committing to do the Close Branch option, but it's not there. I've also tried closing via command line, and that doesn't work.

This is not happening on my machine, by the way, so it's definitely local to his. I think we're both using 4.7.2. I have Windows 7, and he has Windows 10.

TIA for any help.

G.

[Matt Harbison]

When you say it has 2 branches after pulling, do you mean two heads with the same branch name?  Or do these branches have different names?

If you mean the former, that's normal behavior when two people are working on the same branch.  He should just commit his changes, merge with the new head he pulls, commit and push.  If you're working on different files, there won't be any merge conflicts.  If you mean the latter, he needs to update to the main branch.  You can close and merge all you want, but that's not going to change where he's committing.

[Georgiana]

I just know that on his machine, the line branches off to the right. He has to merge to get it to go back. Then he pulls again and the line goes off to the right again. 

We do NOT work on the same files. We have once or twice in the last year+, so it's rare.

With that said, it's no longer an issue, apparently. He backed up the one file he's working on and re-cloned the repository. I hate employing that as a fix, but it did solve the problem. 

We have looked at Mercurial's documentation about branches and found it fairly lacking. Can you direct us to some documentation that will help us understand what's going on if we encounter an issue like this again?

And thanks a ton for your help!

--
You received this message because you are subscribed to the Google Groups "TortoiseHg Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thg-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Harbison]

On Monday, March 25, 2019 at 9:54:35 AM UTC-4, GeorgianaOnline wrote:

I just know that on his machine, the line branches off to the right. He has to merge to get it to go back. Then he pulls again and the line goes off to the right again.

It's hard to be sure from your description if a new branch is actually involved because that's naturally what happens when you pull something.  The new commits go off to the right, and your working directory line stays to the left.  If he didn't commit anything, and doesn't have any uncommitted changes, he can just update to the head on the right.  No branches have actually been created.  If he did commit something, then just merge with what was pulled in. If he does have uncommitted changes, the dialog box will offer to shelve or discard changes.  I'd suggest cancelling out and just committing if he's struggling with this.  Then merge with what was pulled.

We do NOT work on the same files. We have once or twice in the last year+, so it's rare.

The fact that you aren't working on the same files will make the merge trivial, but it doesn't mean you can avoid it.  Commits track the *entire* repository state, not just the files you may have changed in a commit.  That's pretty much how modern version control works, AFAIK.  Even svn is like this.

 

With that said, it's no longer an issue, apparently. He backed up the one file he's working on and re-cloned the repository. I hate employing that as a fix, but it did solve the problem.

If your only branch is default, that makes sense.  The newest commit on default is what is checked out when you clone.  I agree, that's not really a fix to your problem, and it risks undoing your changes the one or two times you work on the same file if he's blindly copying files into the new clone.

 

We have looked at Mercurial's documentation about branches and found it fairly lacking. Can you direct us to some documentation that will help us understand what's going on if we encounter an issue like this again?

I've used hginit.com in the past, but it looks like that site is down.  I haven't read through all of it, but here's hginit2: https://farley.io/hginit2/  It seems like it would be a good idea to read and understand up to and including the collaborating section.  I'd also suggest enabling the blackbox extension.  That will record all of the commands and their state (though TortoiseHg might bypass this sometimes).  You referenced changes disappearing- that shouldn't happen.  So I suspect either the data is there in a commit somewhere and he updated away from it, or maybe he had uncommitted changes and discarded or reverted the files?  The blackbox log might point this out.