How do I resolve merge conflicts in my Git repository?
Try:
git mergetool
It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.
As per Josh Glover's comment:
[This command]
doesn't necessarily open a GUI unless you install one. Running git mergetool for me resulted in vimdiff being used. You can install
one of the following tools to use it instead: meld, opendiff,
kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse,
ecmerge, p4merge, araxis, vimdiff, emerge.
Below is a sample procedure using vimdiff to resolve merge conflicts, based on this link.
Run the following commands in your terminal
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false
This will set vimdiff as the default merge tool.
Run the following command in your terminal
git mergetool
You will see a vimdiff display in the following format:
╔═══════╦══════╦════════╗
║ ║ ║ ║
║ LOCAL ║ BASE ║ REMOTE ║
║ ║ ║ ║
╠═══════╩══════╩════════╣
║ ║
║ MERGED ║
║ ║
╚═══════════════════════╝
These 4 views are
LOCAL: this is the file from the current branch
BASE: the common ancestor, how this file looked before both changes
REMOTE: the file you are merging into your branch
MERGED: the merge result; this is what gets saved in the merge commit and used in the future
You can navigate among these views using ctrl+w. You can directly reach the MERGED view using ctrl+w followed by j.
More information about vimdiff navigation is here and here.
You can edit the MERGED view like this:
If you want to get changes from REMOTE
:diffg RE
If you want to get changes from BASE
:diffg BA
If you want to get changes from LOCAL
:diffg LO
Save, Exit, Commit, and Clean up
:wqa save and exit from vi
git commit -m "message"
git clean Remove extra files (e.g. *.orig). Warning: It will remove all untracked files, if you won't pass any arguments.
Here's a probable use case, from the top:
You're going to pull some changes, but oops, you're not up to date:
git fetch origin
git pull origin master
From ssh://gitosis#example.com:22/projectname
* branch master -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.
So you get up-to-date and try again, but have a conflict:
git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master
From ssh://gitosis#example.com:22/projectname
* branch master -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.
So you decide to take a look at the changes:
git mergetool
Oh my, oh my, upstream changed some things, but just to use my changes...no...their changes...
git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"
And then we try a final time
git pull origin master
From ssh://gitosis#example.com:22/projectname
* branch master -> FETCH_HEAD
Already up-to-date.
Ta-da!
I find merge tools rarely help me understand the conflict or the resolution. I'm usually more successful looking at the conflict markers in a text editor and using git log as a supplement.
Here are a few tips:
Tip One
The best thing I have found is to use the "diff3" merge conflict style:
git config merge.conflictstyle diff3
This produces conflict markers like this:
<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a
feature/topic branch.
>>>>>>>
The middle section is what the common ancestor looked like. This is useful because you can compare it to the top and bottom versions to get a better sense of what was changed on each branch, which gives you a better idea for what the purpose of each change was.
If the conflict is only a few lines, this generally makes the conflict very obvious. (Knowing how to fix a conflict is very different; you need to be aware of what other people are working on. If you're confused, it's probably best to just call that person into your room so they can see what you're looking at.)
If the conflict is longer, then I will cut and paste each of the three sections into three separate files, such as "mine", "common" and "theirs".
Then I can run the following commands to see the two diff hunks that caused the conflict:
diff common mine
diff common theirs
This is not the same as using a merge tool, since a merge tool will include all of the non-conflicting diff hunks too. I find that to be distracting.
Tip Two
Somebody already mentioned this, but understanding the intention behind each diff hunk is generally very helpful for understanding where a conflict came from and how to handle it.
git log --merge -p <name of file>
This shows all of the commits that touched that file in between the common ancestor and the two heads you are merging. (So it doesn't include commits that already exist in both branches before merging.) This helps you ignore diff hunks that clearly are not a factor in your current conflict.
Tip Three
Verify your changes with automated tools.
If you have automated tests, run those. If you have a lint, run that. If it's a buildable project, then build it before you commit, etc. In all cases, you need to do a bit of testing to make sure your changes didn't break anything. (Heck, even a merge without conflicts can break working code.)
Tip Four
Plan ahead; communicate with co-workers.
Planning ahead and being aware of what others are working on can help prevent merge conflicts and/or help resolve them earlier -- while the details are still fresh in mind.
For example, if you know that you and another person are both working on different refactoring that will both affect the same set of files, you should talk to each other ahead of time and get a better sense for what types of changes each of you is making. You might save considerable time and effort if you conduct your planned changes serially rather than in parallel.
For major refactorings that cut across a large swath of code, you should strongly consider working serially: everybody stops working on that area of the code while one person performs the complete refactoring.
If you can't work serially (due to time pressure, maybe), then communicating about expected merge conflicts at least helps you solve the problems sooner while the details are still fresh in mind. For example, if a co-worker is making a disruptive series of commits over the course of a one-week period, you may choose to merge/rebase on that co-workers branch once or twice each day during that week. That way, if you do find merge/rebase conflicts, you can solve them more quickly than if you wait a few weeks to merge everything together in one big lump.
Tip Five
If you're unsure of a merge, don't force it.
Merging can feel overwhelming, especially when there are a lot of conflicting files and the conflict markers cover hundreds of lines. Often times when estimating software projects we don't include enough time for overhead items like handling a gnarly merge, so it feels like a real drag to spend several hours dissecting each conflict.
In the long run, planning ahead and being aware of what others are working on are the best tools for anticipating merge conflicts and prepare yourself to resolve them correctly in less time.
Identify which files are in conflict (Git should tell you this).
Open each file and examine the diffs; Git demarcates them. Hopefully it will be obvious which version of each block to keep. You may need to discuss it with fellow developers who committed the code.
Once you've resolved the conflict in a file git add the_file.
Once you've resolved all conflicts, do git rebase --continue or whatever command
Git said to do when you completed.
Merge conflicts happens when changes are made to a file at the same time. Here is how to solve it.
git CLI
Here are simple steps what to do when you get into conflicted state:
Note the list of conflicted files with: git status (under Unmerged paths section).
Solve the conflicts separately for each file by one of the following approaches:
Use GUI to solve the conflicts: git mergetool (the easiest way).
To accept remote/other version, use: git checkout --theirs path/file. This will reject any local changes you did for that file.
To accept local/our version, use: git checkout --ours path/file
However you've to be careful, as remote changes that conflicts were done for some reason.
Related: What is the precise meaning of "ours" and "theirs" in git?
Edit the conflicted files manually and look for the code block between <<<<</>>>>> then choose the version either from above or below =====. See: How conflicts are presented.
Path and filename conflicts can be solved by git add/git rm.
Finally, review the files ready for commit using: git status.
If you still have any files under Unmerged paths, and you did solve the conflict manually, then let Git know that you solved it by: git add path/file.
If all conflicts were solved successfully, commit the changes by: git commit -a and push to remote as usual.
See also: Resolving a merge conflict from the command line at GitHub
For practical tutorial, check: Scenario 5 - Fixing Merge Conflicts by Katacoda.
DiffMerge
I've successfully used DiffMerge which can visually compare and merge files on Windows, macOS and Linux/Unix.
It graphically can show the changes between 3 files and it allows automatic merging (when safe to do so) and full control over editing the resulting file.
Image source: DiffMerge (Linux screenshot)
Simply download it and run in repo as:
git mergetool -t diffmerge .
macOS
On macOS you can install via:
brew install caskroom/cask/brew-cask
brew cask install diffmerge
And probably (if not provided) you need the following extra simple wrapper placed in your PATH (e.g. /usr/bin):
#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$#"
Then you can use the following keyboard shortcuts:
⌘-Alt-Up/Down to jump to previous/next changes.
⌘-Alt-Left/Right to accept change from left or right
Alternatively you can use opendiff (part of Xcode Tools) which lets you merge two files or directories together to create a third file or directory.
Check out the answers in Stack Overflow question Aborting a merge in Git, especially Charles Bailey's answer which shows how to view the different versions of the file with problems, for example,
# Common base version of the file.
git show :1:some_file.cpp
# 'Ours' version of the file.
git show :2:some_file.cpp
# 'Theirs' version of the file.
git show :3:some_file.cpp
If you're making frequent small commits, then start by looking at the commit comments with git log --merge. Then git diff will show you the conflicts.
For conflicts that involve more than a few lines, it's easier to see what's going on in an external GUI tool. I like opendiff -- Git also supports vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge out of the box and you can install others: git config merge.tool "your.tool" will set your chosen tool and then git mergetool after a failed merge will show you the diffs in context.
Each time you edit a file to resolve a conflict, git add filename will update the index and your diff will no longer show it. When all the conflicts are handled and their files have been git add-ed, git commit will complete your merge.
I either want my or their version in full, or want to review individual changes and decide for each of them.
Fully accept my or theirs version:
Accept my version (local, ours):
git checkout --ours -- <filename>
git add <filename> # Marks conflict as resolved
git commit -m "merged bla bla" # An "empty" commit
Accept their version (remote, theirs):
git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"
If you want to do for all conflict files run:
git merge --strategy-option ours
or
git merge --strategy-option theirs
Review all changes and accept them individually
git mergetool
Review changes and accept either version for each of them.
git add <filename>
git commit -m "merged bla bla"
Default mergetool works in command line. How to use a command line mergetool should be a separate question.
You can also install visual tool for this, e.g. meld and run
git mergetool -t meld
It will open local version (ours), "base" or "merged" version (the current result of the merge) and remote version (theirs). Save the merged version when you are finished, run git mergetool -t meld again until you get "No files need merging", then go to Steps 3. and 4.
See How Conflicts Are Presented or, in Git, the git merge documentation to understand what merge conflict markers are.
Also, the How to Resolve Conflicts section explains how to resolve the conflicts:
After seeing a conflict, you can do two things:
Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.
Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit to seal the deal.
You can work through the conflict with a number of tools:
Use a mergetool. git mergetool to launch a graphical mergetool which will work you through the merge.
Look at the diffs. git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.
Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.
Look at the originals. git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.
You can also read about merge conflict markers and how to resolve them in the Pro Git book section Basic Merge Conflicts.
For Emacs users which want to resolve merge conflicts semi-manually:
git diff --name-status --diff-filter=U
shows all files which require conflict resolution.
Open each of those files one by one, or all at once by:
emacs $(git diff --name-only --diff-filter=U)
When visiting a buffer requiring edits in Emacs, type
ALT+x vc-resolve-conflicts
This will open three buffers (mine, theirs, and the output buffer). Navigate by pressing 'n' (next region), 'p' (prevision region). Press 'a' and 'b' to copy mine or theirs region to the output buffer, respectively. And/or edit the output buffer directly.
When finished: Press 'q'. Emacs asks you if you want to save this buffer: yes.
After finishing a buffer mark it as resolved by running from the teriminal:
git add FILENAME
When finished with all buffers type
git commit
to finish the merge.
Bonus:
In speaking of pull/fetch/merge in the previous answers, I would like to share an interesting and productive trick,
git pull --rebase
This above command is the most useful command in my Git life which saved a lot of time.
Before pushing your newly committed change to remote server, try git pull --rebase rather git pull and manual merge and it will automatically sync the latest remote server changes (with a fetch + merge) and will put your local latest commit at the top in the Git log. No need to worry about manual pull/merge.
In case of a conflict, just use
git mergetool
git add conflict_file
git rebase --continue
Find details at: What does “git pull –rebase” do?
Simply, if you know well that changes in one of the repositories is not important, and want to resolve all changes in favor of the other one, use:
git checkout . --ours
to resolve changes in the favor of your repository, or
git checkout . --theirs
to resolve changes in favor of the other or the main repository.
Or else you will have to use a GUI merge tool to step through files one by one, say the merge tool is p4merge, or write any one's name you've already installed
git mergetool -t p4merge
and after finishing a file, you will have to save and close, so the next one will open.
There are three steps:
Find which files cause conflicts by the command
git status
Check the files, in which you would find the conflicts marked like
<<<<<<<<head
blablabla
Change it to the way you want it, and then commit with the commands
git add solved_conflicts_files
git commit -m 'merge msg'
Please follow the following steps to fix merge conflicts in Git:
Check the Git status:
git status
Get the patchset:
git fetch (checkout the right patch from your Git commit)
Checkout a local branch (temp1 in my example here):
git checkout -b temp1
Pull the recent contents from master:
git pull --rebase origin master
Start the mergetool and check the conflicts and fix them...and check the changes in the remote branch with your current branch:
git mergetool
Check the status again:
git status
Delete the unwanted files locally created by mergetool, usually mergetool creates extra file with *.orig extension. Please delete that file as that is just the duplicate and fix changes locally and add the correct version of your files.
git add #your_changed_correct_files
Check the status again:
git status
Commit the changes to the same commit id (this avoids a new separate patch set):
git commit --amend
Push to the master branch:
git push (to your Git repository)
CoolAJ86's answer sums up pretty much everything. In case you have changes in both branches in the same piece of code you will have to do a manual merge. Open the file in conflict in any text editor and you should see following structure.
(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too
<<<<<<<<<<<
(Code not in conflict here)
Choose one of the alternatives or a combination of both in a way that you want new code to be, while removing equal signs and angle brackets.
git commit -a -m "commit message"
git push origin master
You could fix merge conflicts in a number of ways as other have detailed.
I think the real key is knowing how changes flow with local and remote repositories. The key to this is understanding tracking branches. I have found that I think of the tracking branch as the 'missing piece in the middle' between me my local, actual files directory and the remote defined as origin.
I've personally got into the habit of 2 things to help avoid this.
Instead of:
git add .
git commit -m"some msg"
Which has two drawbacks -
a) All new/changed files get added and that might include some unwanted changes.
b) You don't get to review the file list first.
So instead I do:
git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.
This way you are more deliberate about which files get added and you also get to review the list and think a bit more while using the editor for the message. I find it also improves my commit messages when I use a full screen editor rather than the -m option.
[Update - as time has passed I've switched more to:
git status # Make sure I know whats going on
git add .
git commit # Then use the editor
]
Also (and more relevant to your situation), I try to avoid:
git pull
or
git pull origin master.
because pull implies a merge and if you have changes locally that you didn't want merged you can easily end up with merged code and/or merge conflicts for code that shouldn't have been merged.
Instead I try to do
git checkout master
git fetch
git rebase --hard origin/master # or whatever branch I want.
You may also find this helpful:
git branch, fork, fetch, merge, rebase and clone, what are the differences?
If you want to merge from branch test to master, you can follow these steps:
Step 1: Go to the branch
git checkout test
Step 2:
git pull --rebase origin master
Step 3: If there are some conflicts, go to these files to modify it.
Step 4: Add these changes
git add #your_changes_files
Step 5:
git rebase --continue
Step 6: If there is still conflict, go back to step 3 again. If there is no conflict, do following:
git push origin +test
Step 7: And then there is no conflict between test and master. You can use merge directly.
Using patience
For a big merge conflict, using patience provided good results for me. It will try to match blocks rather than individual lines.
If you change the indentation of your program for instance, the default Git merge strategy sometimes matches single braces { which belongs to different functions. This is avoided with patience:
git merge -s recursive -X patience other-branch
From the documentation:
With this option, merge-recursive spends a little extra time to avoid
mismerges that sometimes occur due to unimportant matching lines
(e.g., braces from distinct functions). Use this when the branches to
be merged have diverged wildly.
Comparison with the common ancestor
If you have a merge conflict and want to see what others had in mind when modifying their branch, it's sometimes easier to compare their branch directly with the common ancestor (instead of our branch). For that you can use merge-base:
git diff $(git merge-base <our-branch> <their-branch>) <their-branch>
Usually, you only want to see the changes for a particular file:
git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
git log --merge -p [[--] path]
Does not seem to always work for me and usually ends up displaying every commit that was different between the two branches, this happens even when using -- to separate the path from the command.
What I do to work around this issue is open up two command lines and in one run
git log ..$MERGED_IN_BRANCH --pretty=full -p [path]
and in the other
git log $MERGED_IN_BRANCH.. --pretty=full -p [path]
Replacing $MERGED_IN_BRANCH with the branch I merged in and [path] with the file that is conflicting. This command will log all the commits, in patch form, between (..) two commits. If you leave one side empty like in the commands above git will automatically use HEAD (the branch you are merging into in this case).
This will allow you to see what commits went into the file in the two branches after they diverged. It usually makes it much easier to solve conflicts.
As of December 12th 2016, you can merge branches and resolve conflicts on github.com
Thus, if you don't want to use the command-line or any 3rd party tools that are offered here from older answers, go with GitHub's native tool.
This blog post explains in detail, but the basics are that upon 'merging' two branches via the UI, you will now see a 'resolve conflicts' option that will take you to an editor allowing you to deal with these merge conflicts.
Merge conflicts could occur in different situations:
When running git fetch and then git merge
When running git fetch and then git rebase
When running git pull (which is actually equal to one of the above-mentioned conditions)
When running git stash pop
When you're applying git patches (commits that are exported to files to be transferred, for example, by email)
You need to install a merge tool which is compatible with Git to resolve the conflicts. I personally use KDiff3, and I've found it nice and handy. You can download its Windows version here:
https://sourceforge.net/projects/kdiff3/files/
BTW, if you install Git Extensions there is an option in its setup wizard to install Kdiff3.
Then setup the Git configuration to use KDiff3 as its mergetool:
$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false
$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false
(Remember to replace the path with the actual path of the KDiff3 EXE file.)
Then every time you come across a merge conflict, you just need to run this command:
$ git mergetool
Then it opens Kdiff3, and first tries to resolve the merge conflicts automatically. Most of the conflicts would be resolved spontaneously and you need to fix the rest manually.
Here's what Kdiff3 looks like:
Then once you're done, save the file and it goes to the next file with a conflict and you do the same thing again until all the conflicts are resolved.
To check if everything is merged successfully, just run the mergetool command again. You should get this result:
$ git mergetool
No files need merging
I always follow the below steps to avoid conflicts.
git checkout master (Come to the master branch)
git pull (Update your master to get the latest code)
git checkout -b mybranch (Check out a new a branch and start working on that branch so that your master always remains top of trunk.)
git add . and git commit and git push (on your local branch after your changes)
git checkout master (Come back to your master)
Now you can do the same and maintain as many local branches you want and work simultaneous by just doing a git checkout to your branch whenever necessary.
I understood what a merge conflict was, but when I saw the output of git diff, it looked like nonsense to me at first:
git diff
++<<<<<<< HEAD
+ display full last name boolean in star table
++=======
+ users viewer.id/star.id, and conversation uses user.id
+
++>>>>>>> feat/rspec-tests-for-cancancan
But here is what helped me:
Everything between <<<<<<< and ======= is what was in one file, and
Everything between ======= and >>>>>>> is what was in the other file
So literally all you have to do is open the file with the merge conflicts and remove those lines from either branch (or just make them the same), and the merge will immediately succeed. Problem solved!
GitLens for Visual Studio Code
You can try GitLens for Visual Studio Code. The key features are:
3. Easily resolve conflicts
I already like this feature:
2. Current Line Blame.
3. Gutter Blame
4. Status Bar Blame
And there are many features. You can check them here.
This answer is to add an alternative for those Vim users like me that prefers to do everything within the editor.
TL;DR
Tpope came up with this great plugin for Vim called fugitive. Once installed, you can run :Gstatus to check the files that have conflict and :Gdiff to open Git in a three-way merge.
Once in the three-way merge, fugitive will let you get the changes of any of the branches you are merging in the following fashion:
:diffget //2, get changes from original (HEAD) branch:
:diffget //3, get changes from merging branch:
Once you are finished merging the file, type :Gwrite in the merged buffer.
Vimcasts released a great video explaining these steps in detail.
I am using Microsoft's Visual Studio Code for resolving conflicts. It's very simple to use. I keep my project open in the workspace. It detects and highlights conflicts. Moreover, it gives GUI options to select whatever change I want to keep from HEAD or incoming.
git fetch <br>
git checkout **your branch**<br>
git rebase master<br>
In this step you will try to fix the conflict using your preferred IDE.
You can follow this link to check how to fix the conflict in the file.
git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master (push like a drafts)<br>
Now everything is fine and you will find your commit in Gerrit.
Try Visual Studio Code for editing if you aren't already.
After you try merging (and land up in merge conflicts), Visual Studio Code automatically detects the merge conflicts.
It can help you very well by showing the changes made to the original one and if you should accept incoming or
current change (meaning original one before merging)'.
It helped me and it can work for you too!
PS: It will work only if you've configured Git with with your code and Visual Studio Code.
A safer way to resolve conflicts is to use git-mediate (the common solutions suggested here are quite error prone imho).
See this post for a quick intro on how to use it.
For those who are using Visual Studio (Visual Studio 2015 in my case)
Close your project in Visual Studio. Especially in big projects, Visual Studio tends to freak out when merging using the UI.
Do the merge in a command prompt.
git checkout target_branch
git merge source_branch
Then open the project in Visual Studio and go to Team Explorer → Branch. Now there is a message that says Merge is pending and conflicting files are listed right below the message.
Click the conflicting file and you will have the option to Merge, Compare, Take Source, and Take Target. The merge tool in Visual Studio is very easy to use.
In short:
How can I use Hg to synchronize repositories between two computers using a flash drive as intermediary?
With more detail:
I often develop code on computers that aren't networked in any way, and I transfer files between these machines using a USB flash drive. Now I would like to develop some software across these machines using Hg repositories on each machine that I can frequently sync-up using the flash drive transfer mechanism.
I'm slightly familiar with Hg, as I use it in the most simple way possible for versioning only my own work on independent machines, but am uncertain as to exactly what I should do to use it to synchronize repositories between two computers using a flash drive as intermediary. Maybe, for example, I need to create a temporary repository on the flash drive (using “clone”) from which I then sync to (using “push” and “pull”), and do this by A→flash, flash→B, B→flash, flash→A? The more specificity in your answer regarding the sequence of actions and commands, the more useful to me.
Finally, how do I get this process started? Do I need to do something so Hg knows these are all part of one code base? For example, each of my current repositories on the different computers was created independently from a time before I started using Hg, and although all the code is similar, independent changes have been made to each, and the repositories know nothing about each other. If what I need to do with this is different than what I need to do for the ongoing case once I have everything unified, spelling this process out for me as well would also help.
In case it's important, these machines can be running any of Windows, Mac, or Linux, and my versions of Mercurial are slightly different on each machine (though the Mercurial versions could be unified if needed).
What you have described above in terms of using the flash drive as an intermediate storage location should work. My process would be:
initial setup
create repo on computer A (using hg init)
clone the repo from computer A to flash drive
hg clone C:/path/to/repo/A X:/path/to/flash/drive/repo
clone the repo from flash drive to computer B
hg clone X:/path/to/flash/drive/repo C:/path/to/repo/B
working process
edit/commit to repo on computer A
push from computer A to flash drive
hg push X:/path/to/flash/drive/repo
pull from flash drive to computer B
hg pull X:/path/to/flash/drive/repo
edit/commit repo on computer B
push from computer B to flash drive (same commands as above)
pull from flash drive to computer A (same commands as above)
Finally, how do I get this process
started? Do I need to do something so
Hg knows these are all part of one
code base?
Mercurial knows if two arbitrary repositories have a common ancestor by looking at the SHA1 hash keys of the commits in each repo. In other words, assuming both repos have at least one common hash key in their histories, Mercurial will attempt to merge them. In your specific case, where both repos are initially un-versioned, Mercurial will need some help. The best thing to do would be to get to a place where both repos are identical and then perform your hg init. Mercurial should handle sharing from this point on.
When working offline on different machines. It is better to use the bundle command that comes with Mercurial. So echoing what dls wrote but a slight change process.
Initial setup as mentioned by dls.
or
Go to your Mercurial repository top directory
Create bundle: hg bundle --base null ../project.hg
Copy the project.hg file to your other computer
Create a directory there
Make it an Mercurial repository : hg init
Incorporate the bundle: hg pull <path/project.hg>
hg update
Check hg log, both the repository will show same base revisions and tip
Workflow using bundle
I use a slightly different workflow. I keep these repositories as distinct repositories.
I mention them as repo1 and repo2.
Suppose that the current tip of repo1 is 4f45839f613c.
You make changes and commit them in repo1
Create a bundle of the changes :
Command : This bundle contains all changes since the specified base version.
hg bundle --base 4f45839f613c changes.bundle
Take it to repo2 by copying the bundle.
You can simply pull the bundle to repo2 :
Command :
hg pull changes.bundle
If the bundle contains changes that are already present in repo2, then these will be ignored when pulling. As long as the bundle doesn't grow to large, this allows to use the bundle command with the same --base revision again and again to create bundles including further changes.
About bundles: these are (very well) compressed.
creates a (compressed) backup of the repository
hg bundle --base null backup.bundle
[Edit : Adding some links on this topic]
http://blog.experimentalworks.net/2010/09/review-remote-changes-offline-in-mercurial/
https://www.mercurial-scm.org/wiki/Bundle
[Edit: What I think is advantage of using bundle]
Bundles can be created offline, copied or sent via mail. Using push to repo on flash drive, requires it to be connected. Bundles are easier since it does not maintain that the two repo from which you push and pull have to be available at the same time.
Apart from that, bundles can also be of two types : Changesets and Incremental. Changeset bundles are complete standalone bundles. You can also use bundles for backup as a single file.
I'm new to Launchpad and Bazaar, and I'm trying to figure out what the best way is to submit bug fixes. I'm using some reasonably popular open-source software that's hosted on Launchpad, but it's not very stable. I've created my own branch of the project to stabilize it and apply just the bug fixes we need without adding other changes from ongoing development.
When I file bugs and then figure out how to fix them myself, I push the fix to our stable branch. How should I publish the fix back to the main project? I could create a patch file and attach it to the bug, or I could propose a merge for our stable branch.
If I fix multiple bugs, can I make a separate merge proposal for each one, or are they cumulative?
Update: It looks like the OpenERP project's official documentation now has guidelines for making merge proposals. I'll also leave my version here because it has some different details.
After playing with Bazaar and Launchpad for a few days and submitting a few patches and merge proposals, I thought I'd write a summary of what I found. Launchpad and Bazaar provide some powerful tools, particularly for community-driven projects, but I don't think new users are likely to fall into the pit of success yet. There are several ways to make the process slow and frustrating, so I hope this walk through helps some people avoid a few mistakes.
Here's the work flow I've learned for working on bug fixes and submitting merge proposals back to the team for a project that's hosted on Launchpad. I'm working on a GNU/Linux workstation, but I assume the Bazaar commands would be equivalent on other platforms. In this example, I'm working on one of the projects in the OpenObject project group called OpenObject Addons. The maintainer's user name is openerp. I'll put my workspace in the ~/workspace folder.
If you want to learn more about any of the commands here, use bzr help plus the command name.
Create a shared repository
Because I'm going to be creating a branch for each feature I want to contribute back to the project, I don't want to have a separate copy of the project's entire history for each branch. To avoid that, I create a shared repository and then create each branch within that. One thing to be careful of is that your repository format has to match the official branch's format to make some of the later steps work.
Check the repository format on the official branch:
bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0
Get the code
Now create a workspace folder that will hold any local branches on your machine - I just name it after the project. Then create a shared repository in it using the format you found on the official branch.
cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .
The next step is to check out the source code from the official branch. It's usually called trunk, but you might prefer to work with a stable release branch that is just being used for bug fixes. In this example, I'm going to work on the 5.0 release branch.
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x
That step is probably the slowest in the whole process for a large project, because you're copying all the code plus all the history for the entire project onto your hard drive. Note that I name the branch after the feature I'm going to work on.
Create a branch
At this point you can experiment with building and running the code on your local workstation. You can make changes to the code, but you don't have anywhere to commit them yet, because you're probably not allowed to commit directly into the official branch. To publish your code changes you need to create a public branch. If you're new to Launchpad, you'll need to create an account and register a public key first.
Once you've set up your account, you can publish your own branch as a copy of the official branch, and start working with it. The lp-login command tells bazaar what account name to use on the launchpad site, and the whoami command tells bazaar what name to use on each revision you commit. The e-mail address you use in whoami should match one of the e-mail addresses you configured for your Launchpad account.
cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <donkirkby#example.com>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x
You switch to the new branch so that commits will be recorded in your local history and in your public branch. You might want to learn about the difference between a checkout and a branch. Making this a stacked branch means that it's very fast to create because it only contains the history that's not in the official branch. This blog post makes it sound like branches of public projects should default to stacked, but that hasn't worked for me. Notice that I named the branch after some feature I want to add. As bialix suggested, I create a separate branch for each feature that I will eventually propose merging back into the official branch.
Commit and make a merge proposal
Now that you have a branch, you can make code changes and commit them.
cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."
You can commit from anywhere within the branch structure, and it commits the entire branch by default. Run bzr help commit for details. You might also find bzr status and bzr diff useful.
Once you're happy with the changes and you've committed everything to your feature branch, you can go to the Launchpad web site and create a merge proposal. Here's a handy shortcut that you can run to launch the branch's web page:
cd ~/workspace/openobject-addons/feature-x
bzr lp-open
Once you create the merge proposal, Launchpad will generate a diff for it. It's well worth reviewing that diff. Sometimes I've selected the wrong branch as a target, and I only noticed because the diff had way more changes than I expected. There's also a bzr send command for merge proposals, but I haven't used it.
There's an e-mail interface for shepherding your proposal through the process, or you can just use the web site.
It's also useful to attach the branch to the bug so that other people can use it like a patch on their own systems.
Ongoing changes
If you work on several features and the maintainer isn't very speedy at reviewing your proposals, it's probably worth setting up your own mainline branch. This branch collects all your features together and it holds the code that you would run on your servers. It's also useful if the official branch isn't very stable and you want to stabilize a branch for your production environment. Then you can decide when to upgrade to the latest, and when to take specific patches for bugs that are hurting your users.
The first step is to create another branch that is stacked on the official branch:
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main
Now there are two sources of changes you'll need to merge from. First, merging from a feature or bug fix branch:
cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"
Of course, if you still have a local copy of the feature branch, it will be faster to do a local merge:
cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"
Second, you'll occassionally want to merge the latest and greatest from the official branch:
cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"
After using --remember when you merge from the official branch, you can just use bzr merge on its own to merge from the official branch. If the project uses tags to mark release points, you can view a list of tags and merge from a tag.
cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2
Such policy (using merge proposals or patches) should be defined by core developers or maintainers of the project itself. But as general rule using separate branches for each fix is preferable way over just plain patches.
Because plain patches may become out-of-date when trunk branch development moving forward. When you keep the branch for the fix then you can update your fix according to recent changes in trunk.
Fixes in branches are simpler to analyze, because other developers can see all your intermediate steps for fixing the problem, or how your fix has evolved over the time as trunk changed.
Also patches attached to bug reports often tend to be missed or forgotten. While the list of all active merge proposals is prominently shown on "Branches" page of every project.
Merging your fix from your branch means the history (and annotations) will keep your name as path author, not the core dev who applied your patch.
Keep all fixes in one branch is not good for using it in merge proposal. But it's useful per se for testing all your fixes or using it as stable branch (e.g. for dogfooding). So I'd suggest to use separate (feature) branches for each separate fix, file for them separate merge proposals, and merge these branches into your stable branch as you doing today. This way you can get full freedom over applying additional changes to each your fix and then merge it again to your stable branch.
If you need to split your existing stable branch to several separate branches you can use the recipe from John Meinel described in his blog: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html