I have been fumbling around on github, and now with some help I have managed to make my branch the local master. however, I get these lines that i guess are tracking where things have been changed. But I don't want them!! I really just want my current files to become the new master as they are.
What exactly are these lines for? And how do I suppress them?
<<<<<<< HEAD
=======
>>>>>>> master
Those lines signal merge conflicts in Git.
When you do a merge, git is generally good at automatically working out how to merge files together, however there are some cases where it cannot - for example, when both branches are adding to the same kind of area in the same file, you get a merge conflict.
In these cases, those lines will be drawn around the boundary of the conflict. The section above the ======= belongs to the HEAD ref (or whatever is displayed after <<<<<<<). The section below belongs to the master ref (or whatever is displayed after >>>>>>>).
It's up to you to delete these lines and make the according edit to the code. If you only want to take what is on the HEAD ref in the final version of the code (post-merge), then you delete everything below the ====== line - and visa versa if you want to only take what is on the master branch. Of course, you can also take both versions of the code by just removing the markers.
You can see the git manual for more information.
Related
I apologize in advance it's kind of silly question. But I just can't wrap my head around it: why NOT EVERY change I make on my current branch will cause merging conflict? If line X in my version of a file on a local branch is NOT identical to the same line in the same file on a remote branch - why NOT necessarily it will end up with a conflict? It there something special about adding/deleting lines rather than CHANGING lines of code? Please find the screenshot attachedenter image description here
I'm in the process of doing a merge, and I'm ready to commit at this point but my commit dialog in TortoiseHg is showing many files as modified but when I diff to parents it says all files are binary equal.
I do not have and have never had the eol extension enabled.
Revert changes nothing, the file is still registering as modified.
hg parents shows two parents for the file.
hg stat shows the file as modified, e.g.
c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs
M Authorization\AuthorityGroups.cs
hg diff --git shows nothing, e.g.
c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs
c:\Projects\MyProject>
I've tried this on two different machines on two separate clones and I'm seeing the same thing.
Any other thoughts for how I could diagnose or fix this?
Clearly something has changed but if it's not showing in hg diff --git how can I establish what that might be?
Update 2014/12/10:
I've done a bit more checking on the history of the two parent revisions and I think I see why it's getting confused.
We've got the original parent file added in revision 1 on default.
On the Apple branch the file has been renamed to move it to a new location.
On the Orange branch the file has been added to move it to the same new location.
So the file on both branches is binary identical and at the same location, but presumably Mercurial is flagging it as a difference to be merged because they arrived there by apparently different means.
So the question then becomes:
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history) , or do I just need to let it go through in the merge?
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history)
Well... sort of. Update to the most recent Orange commit in which the files had their old names (you can use hg bisect to find it if you're not sure exactly when it happened), do hg rename to the new names, commit, and then merge this into the current Orange head. Mercurial should be smart enough to register the files as properly renamed, and it won't cause conflicts (we know this because the more complex Apple/Orange merge didn't).
or do I just need to let it go through in the merge?
This is easier. Mercurial's merging algorithm is quite smart. It can deal with situations like this just fine.
Unless you have a third branch in which the files were never moved, the second option is unlikely to cause a problem. If you do have such a branch, you should be fine as long as you merge it into a descendant of the Apple rename (or merge from such a descendant). The major difficulty would be with merges to or from the Orange branch.
Can you diff with the reverted copy?
I was doing work in the wrong repo. They are almost the same, but have no actual relation.
I just did a pull and an update, can i then copy my changed files into the Right head and then run a diff on it or something similar and then properly merge the 2 together?
I feel an alternate option would be do something like
copy the code over and commit it, then revert back, and merge with the commit to diff what has all changed..
I have changing something like 1500 lines over 9 files, so i dont want to rewrite a bunch of code segments.
How should i handle this?
It really depends on how similar the "almost the same, but have no actual relation" repositories are.
If they extremely similar (as in files have the same names and text is almost identical), you might get by with exporting a patch at the source repo and then importing the same patch into the target repo.
In the source repo:
hg export -r tip > path\to\oops.patch
and in the target repo:
hg import path\to\oops.patch --no-commit
I used --no-commit since I assume you will need to do some cleanup first to make sure that everything looks ok.
Alternatively, you could just compare the two directories using kdiff or BeyondCompare3 and bring over the differences that you want from the source repo to the target repo and commit it that way. This would probably be my approach.
(I am intentionally ignoring the question about why you have two repositories that are that similar but don't have a shared history. For all I know, it might be the right thing to do.)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
how to ignore files in kiln/mercurial using tortoise hg “that are part of the repository”
I have a config file that I don’t wish to check in however I do wish to get updates whenever someone checks in a change to it.
In most systems I just need to uncheck the tick mark next to the config file at check-in time, however HG seems to make life a lot harder!
In parforce this even easier, I can just check the config file out in a different change list, how do I do the same in TortoiseHg?
In general, you don't. The usual way to handle this is not to put the config file in source control, but instead to put a template for it in source control. Something like config.sample. You can even tweak your run/build script to copy config.sample to config if config doesn't already exist.
There are plenty of other ways to try and get at this using mq or an alias like mycommit = commit -X config, but at its core a file is either tracked or it isn't and a file everyone has to change themselves shouldn't be.
If you uncheck the file from the file list before committing it won't go into the change set. This means it won't feature in a push (as these are per change set).
This is one feature of Tortoise that makes it useful over the command-line.
If you do a pull with an edited file, you will create multiple heads. You can merge these if you want the file to feature changes, but this might be a manual step.
Alternatively in the case of a config file it is useful to use the Patch Queue functionality of Mercurial. From the command-line this is possible thus (assuming it is changed in your working directory):
hg qnew "localConfig"
hg qrefresh
This creates a new patch queue item called "localConfigs", and puts the edited files (your config file) into the item. You can then:
hg qpop
To remove it from the patch queue (out of your change set path). Or:
hg qpush
To put it in your change set path. This is an easier way of managing file changes that you do regularly on top of keeping pace with the central repository: you pop your queue items out, pull and update, then push the queue items back on (handling any merge conflicts, though these are rare if your items are small). This way you avoid multiple heads.
https://www.mercurial-scm.org/wiki/MqExtension
We tend to use this mechanism in our office.
Note, pushing and popping acts like a stack collection; if "localConfigs" is on top of "moreLocalChanges" you will need both if you wish to push "localConfigs". My example assumes that the "localConfigs" patch is the only one in the queue. It is also disabled by default in Mercurial configuration, but comes bundled with it so you can enable it simply:
[extensions]
mq =
I understand that CVS is obsolete system in out time but my company use it.
Problem is the next. As usual when developing starts we create branch from head and start work. Some times later we re-base branch with head and merge head with branch. It is ok. But every next typically operations are with problem. Many-many files are marked as changed, but in fact files hasn't any changes! . And these files aren't become white they red. It's a problem, because we need to review all of it to be sure that file modified.
To re-base branch with head we have do (using WinCVS):
1.Click Update.. on some branch;
2.Check Create missing directories;
3.Check Get the clean copy;
4.Check Update using last check in time;
5.Select Revision to update;
6.Select Merge type.
Any ideas why this can happen?
Thanks.
Tag the HEAD after each rebase, and next time you rebase, set the root tag to the last tag you made.
Like this:
Create BRANCH from HEAD, tag HEAD with BRANCH_ROOT_1
Do some work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_1, tag HEAD with BRANCH_ROOT_2
Do some more work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_2, tag HEAD with BRANCH_ROOT_3
...
GIT and (recently) SVN do this sort of thing automatically, but with CVS you need to do it manually after each merge. It's one of many reasons CVS is to be avoided like the plague.
I would suggest checking line endings (Win/Unix).
I have seen problems with all files marked as changed because of time zone problems. For example files checked out on a server using UTC, and copied over the network to a pc using CET. Or a change in daylight savings time caused such problems.
I have always used TortoiseCVS and it's Merge command, so I don't know much about WinCVS.