I am using a named branch for a customer specific version. On this branch, I have some files that are customer-specific (Branding, logos,...). These files should never be merged to the default branch.
I want to make sure that these customer-specific files will never be merged in the default branch.
Is there a way to mark some files as branch specific in Mercurial?
No, not that I know of such feature. However, you can merge that branch once into default, taking care to merge into default only what you want to see merged (e.g. hg forget those customer files during the merge into default). In later merges those files you chose to forget in the default branch will be "only" show up with
remote changed customer which local deleted
use (c)hanged version, leave (d)eleted, or leave (u)nresolved? d
where you should choose 'd'. An example transcript of such exercise you can find in this paste
If those files are well-known and fairly stable, you could create a commit hook (client-side) and/or a pretxnchangegroup hook (server side) which checks those files not being present in any commit within the default branch, and which rejects the commit when any such file is committed to default.
You can use merge-patterns.
hg merge --config merge-patterns.somefile=internal:local otherbranch
Related
I have two branches in my mercurial repository that I want to merge. One is my default branch and the other is Bootstrap 3.3.7.
In my default branch I've customised the Less files. I replaced them with the vanilla ones from Bootstrap 3.3.7 and committed the changes to a new branch Bootstrap 3.3.7.
I'm currently on the default branch and want to merge Bootstrap 3.3.7 to that but when I do the merge instead of having merge conflicts that I can manually resolve (thereby preserving my edits), mercurial simply takes the file versions from my default branch, ignoring Bootstrap 3.3.7 files, even though I know there should be conflicts.
How do I do the merge so that I have the option of picking which changes I want.
In the attached screenshot I've filtered my repository to the relevant branches but my working directory is Rev 7097 on the default branch.
Using gitHub (and Eclipse Egit, and SourceTree) with a forked repo, how can I make a pull request that just contains a few select files I want pulled?
This question asks almost the same thing, but addresses 'cherry-picking' a single or group of commits. I seem to need to have a pull request with just a few files from within a larger commit.
I tend to make a lot of changes to a lot of files putting in debugging code then find a solution that may involve only a change to a file or two. I don't commit very frequently so I don't have have a commit that contains only the changes that fix the problem (and I like keeping the debugging hooks in my copy of the code.)
I'd like SourceTree or eGit/Eclipse to: 1) show me which files are different between two commits and 2) let me select which files to include in a pull request. Perhaps I could do some selective merge files in my current master head and the master of the upstream repo?
I think what you want to do is to check out a number of files from a given commit / tree / revision.
To do this use:
git checkout [tree-ish] -- [paths]
[tree-ish] is a git-ism that basically means a commit, tag or branch, or something that refers to one of those. So if you have a remote remotes/foo/bar and you want baz.c from that revision, you do:
git checkout remotes/foo/bar -- baz.c
A 'pull request' is not a git thing, but a github thing. You will need to do a git remote add to add the repo you want to pull, then use git fetch or git remote update to pull the relevant information, then use the appropriate branch name in the above to get the file(s) you want.
The situation:
Several branches I constantly have to merge between them. Each branch has a special file that identifies the branch (with certain settings for commit mails, plugin options and more, doesn't matter here).
The problem:
Whenever I merge one branch to the other and this special file has been changed it will obviously overwrite the merge target file. But I don't want this to happen. Those files must be version controlled in their branches as they are an essential part of it, but they should not be merged at all as they contain branch specific information.
The question:
Is it possible (and how) to exclude a specific file from a merge? I'd like a solution that doesn't requier me to specify this on each merge as a paramter, but if there's nothing else then I bite the bullet.
The only way to exclude a file from a merge is to revert it right after the merge, before you commit, for example:
cd /path/to/repo/trunk
bzr merge ../branchA
bzr revert file/to/exclude
bzr commit -m 'merged from branchA'
Later, when you merge again from branchA, the bzr revert step in the middle is only necessary if the file changed in branchA since the last merge. So if the file doesn't change very often, then "biting the bullet" might not be all that bad.
Me and my friend need to develop a project parallely. how to do this?
I created two branch worked on each leaf. Tried to merge the leaves but getting conflict error for edited file. What is the way to merge them?
I would like to know if it possible to have 2 leaves in a single branch? If so then how to create a new leaf in addition to the default leaf.
Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.
To create a new branch of development, one opens a fossil repo and executes a command like:
fossil branch new some_feature trunk
Complete example
For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:
here
is
a
file
After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...
fossil branch new some_feature trunk
Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:
here
is
a
file
folder
...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...
fossil co some_feature
From this second branch, I also edited the last line of the baseline file:
here
is
a
file
reader
...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".
To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.
fossil co trunk
Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:
fossil merge some_feature
MERGE file.txt
***** 1 merge conflicts in file.txt
WARNING: 1 merge conflicts
"fossil undo" is available to undo changes to the working checkout.
This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.
In my case the generated conflicts file, "file.txt" looked like this:
here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".
For reference, here is the event history diagram as provided by fossil for this example:
My current SubVersion workflow is like so:
The trunk is used to make small content changes and bug fixes to the main source code.
Branches are used for adding/editing enhancements and projects.
So, trunk changes are made, tested, committed and deployed pretty quickly. Whereas, enhancements and projects need additional user testing and approval.
At time, I have two branches that need testing and approval at the same time. I don't want to merge to the trunk and commit until the changes are fully tested and approved.
What I need to do is merge both branches to one working copy without any commits.
I am using Tortoise SVN, and when I try to merge the second branch, I get an error message:
Cannot merge into a working copy that has local modifications
Is there a way that I can do this without committing either merge?
You currently have the trunk and 2 branches A and B (which are both branches from the trunk). I suggest you create yet another branch called AB as follows:
Switch your working folder to the trunk, if not there already
Update the latest and make sure you have no local modifications. If you do, either commit them (to the trunk) or revert them as appropriate.
Do one last update of your working folder from the trunk. Note the revision number you have updated to (call it revision R).
In the repo, copy revision R of the trunk to a new branch called "AB" (Do not switch your working folder to AB yet)
Merge your working folder with A.
Switch your working folder to AB.
Commit your working folder (to AB) and update (from AB).
Switch your working folder to the trunk.
Merge your working folder with B.
Switch your working folder to AB.
Commit your working folder to AB.
Test, and commit any fixes to AB.
When it's working and you're ready to merge everything to the trunk, do a final commit (to AB), then update your working folder (from AB).
Switch your working folder to the trunk.
Merge your working folder with AB
Test and fix
When it's working, commit working folder to the trunk.
Go out for beers
We had a similar workflow at one point. The solution I finally landed on was to keep multiple local copies, basically one per branch. Got a bit dicey at times with shared databases but overall it was very successful.
you can checkout another copy of the branch you want to merge into at a different place on your local drive, merge into it and then commit it. Then delete the whole 2nd working copy and return to your current task.
But it does seem that you are trying to subvert your own working practices - unless you want to just merge 2 branches together to commit all the work simultaneously and delete the 2 old branches... but then, what's stopping you from committing to them and merging normally in such a case?
Every merge operation is done in your local sandbox. You do not have to be worried until you commit some junky code.
I don't know the whole deploy process you do but what you can do is:
switch to branch A
merge branch A with branch B
build the app, deploy and test it
If all works fine you can commit all changes (you are on branch A). Then you can switch to trunk and merge with branch A. After all conflicts are solved you can commit on trunk and that is all.
Eric, " I may want to only deploy one change at a time..." and "merge two branches to one working copy without committing" are incompatible requirements: or you'll test branch after branch or mix two branches in one big mix.
Version A Anyway - you can merge any node with any node inside repo-tree, not only somebranch with trunk. I.e., in common, #JoelFan workflow is good, but - require less actions
copy HEAD of trunk to AB
Merge AB with A
Commit mergeset, test etc...
Merge AB with B
Test merged results
Merge to trunk and delete temporary AB-branch
Version B is 2-URL merge. svn help merge, "2-URL Merge Example" part as start. You can merge 2 independent branches into third in one command merge BRANCHA[#N] BRANCHB[#M] [TRUNK_WCPATH]