My colleague created a feature branch about a year ago and checked in some modification on it. Now I need to continue with it but During the time files was changed on the main branch too.
Now I need to rebase feature branch to main latest and merge changes from main to my feature branch.
How can I do that?
cleartool rebase is a term from UCM ClearCase, and applies to a baseline (a label on all elements of an UCM component -- or set of files).
If you are not using UCM, the equivalent would be to put a label on the LATEST of the elements in your branch.
In both cases (UCM or non-UCM), the end-result of that rebase would be to merge the main branch into the feature branch.
In non-UCM, this is a simple cleartool merge (you don't need the initial LABEL: it is just to memorize the state of the feature branch before the merge)
Warning: that "rebase" is not like a rebase in a distributed VCS like Git, where commits (versioned set of files) are replayed. Here, ClearCase is file-centric, which means it will only do merges.
Related
Im a bit confused about these scenarios:
I have a task.
I create feature branch, make work here.
And then I create Pull Request to release-test branch.
In order to avoid conflicts, first I have to update my feature branch. So I have to merge release-test into feature.
But in this case, in my Pull Request I will have a lot of merged commits which I don't want to have. I want only my feature branch commits in PR.
What should I do in this situation?
I pushed my feature branch and then conflict appears in PR. What are my next steps?
I tried to revert to the last commit, made compare with release-test branch, then force push. Is this a good practice?
P.S. I'm using Intellij Idea if this would help
In order to avoid conflicts, first I have to update my feature branch. So I have to merge release-test into feature.
Don't: you should always merge from specific to integration branches, not the reverse.
Your feature branch is a specific branch (specific for a given task you are isolating in its own branch)
release-test is an integration branch (where multiple branches come to be merged)
If you need to update your feature branch compared to release-test, rebase it:
cd /path/to/local/repo
git switch feature
git fetch
git rebase origin/release-test
# resolve potential conflict there
git push --force
That will guarantee there won't be any conflict in your PR (automatically updated after the push --force), since your feature branch will only add new commits on top of the most recent remote release-test branch.
I am working on a project, using Fossil for version controlling and organizing it. I have some branches other than my main trunk branch, and want to update (commit) only a single branch. Doing commit will push my changes on a branch to the main Files (i am hosting my project on Chiselapp)
. How is it possible to update or commit only a single branch without affecting the main files?
A commit only ever affects a single branch. Except perhaps after merging two branches, but I'm assuming you haven't been doing that.
The only thing I can think of is that the skin you're using has a "Files" menu item that links to dir?ci=tip. The tip is a special name for the most recent commit. Which means that, if you make a commit in a different branch than trunk, that "Files" menu item will now show you the files of that other branch.
The hackish temporary way to fix that is to make a commit in trunk afterwards, so that tip refers to trunk again. But that's not ideal.
The easiest way to permanently fix this, is by choosing a different skin which doesn't do that, or by editing your skin's header, and replacing the link to dir?ci=tip by another link, dir?ci=trunk for example. That way, that menu item will always show the files in the trunk branch.
Fossil unlike Git pushes/pulls all branches and tags at once*. The reason (apart from being by design) is that Fossil repository is a database, push/full synchronizes the database in the respective direction.
This means if you committed changes on several branches then all of them will be pushed to the remote.
*UNLESS, the changes are done on private branches (see fossil help for fossil commit --branch --private, fossil branch new --private).
Private commits/branches by default are excluded from push/pull. To also include these use --private option (see fossil help for fossil push --private).
Once the changes have been pushed, they are integrated in the remote repo and can be viewed in the remote repo's web-GUI as individual commits or via the branch to which they belong. The view includes the Files section that reflects the repo contents (snapshot) at the commit's version.
To answer your question: if you committed changes to existing trunk branch, they will be pushed to the remote trunk as well. If you don't want to make changes to the remote trunk, then make your changes in your new branch (to be pushed as a new branch) or in your private branch (will NOT be pushed by default).
I have a long standing patch branch and a develop branch. I want to cherry-pick specific changes from develop to the patch branch.
When I do, I get new commits with no link to the old commit.
Is there a way to cherry pick and maintain the parental link to the branch for that commit?
is adding "-x" the best I can do?
Thanks
Yes, -x is really the only way to reference the commit that you cherry-picked.
If you want to maintain the parent relationship of your commits, you would need to merge the branches. My guess would be that you would want to merge the patch branch with the develop branch so that you keep your work properly segregated.
Though based on the way you phrased the question, I think that you might have a misconception about commits. They don't have a "link" to a branch. Rather each commit has a single parent commit that they point to. Merge commits have multiple parents to show which commits they are merging together. A branch is really just a pointer to a commit. A commit can exist on multiple branches either because it was merged or you created a new branch based from it or a later commit.
What git cherry-pick does is make a copy of the changes that you made on one branch and apply them to a different location. You do this because you don't want the rest of the history coming along with this particular change. If you want to maintain a history, you would git merge or git rebase the changes from one branch to another.
The bzr documentation states http://doc.bazaar.canonical.com/bzr-0.10/bzr_man.htm
bzr update: ... If you want to discard your local changes, you can just do a
bzr revert instead of bzr commit after the update.
However this is not what I am getting. I have new files in my repo and all I want is to have the latest revision in my working directory and to have bzr status show anything as being changed.
Is this possible?
First of all, you're looking at an extremely old version of the doc.
As of version 2.6 (current stable),
the description of bzr update is longer, and very different:
Description:
This will perform a merge of the destination revision (the tip of the
branch, or the specified revision) into the working tree, and then make
that revision the basis revision for the working tree.
You can use this to visit an older revision, or to update a working tree
that is out of date from its branch.
If there are any uncommitted changes in the tree, they will be carried
across and remain as uncommitted changes after the update. To discard
these changes, use 'bzr revert'. The uncommitted changes may conflict
with the changes brought in by the change in basis revision.
If the tree's branch is bound to a master branch, bzr will also update
the branch from the master.
You cannot update just a single file or directory, because each Bazaar
working tree has just a single basis revision. If you want to restore a
file that has been removed locally, use 'bzr revert' instead of 'bzr
update'. If you want to restore a file to its state in a previous
revision, use 'bzr revert' with a '-r' option, or use 'bzr cat' to write
out the old content of that file to a new location.
The 'dir' argument, if given, must be the location of the root of a
working tree to update. By default, the working tree that contains the
current working directory is used.
Aliases: up
See also: pull, status-flags, working-trees
Your question is not very clear.
When you're working in centralized mode,
you have a working tree you created with bzr checkout,
the bzr update command will bring in the new revisions that were added in the central repository.
If your working tree was clean (bzr status showing no changes) before bzr update,
then your working tree will be updated to the latest version (as it is on the central server),
and your working tree will be still clean.
If your working tree wasn't clean before bzr update,
then Bazaar will try to merge the new revisions on the server into your working tree,
and conflicts may happen.
If the changes you had were exactly as what the new revisions changed,
then you will end up with a clean working tree, which is extremely rare.
Most commonly,
if your working tree had changes before bzr update,
it will most probably have changes after, and possibly conflicts too.
The bzr status will tell you what they are.
It's best to not have pending changes before running bzr update.
Is theere a way of finding out what changes a bzr update will do without actually doing it.
Specifially I would like to have a bit of warning if there is going to be a conflict.
Not directly that I'm aware of, that's what bzr revert is for. However, there is a common way to structure your local branches to help. I use one local branch that mirrors the central branch, then I branch off of that for my work. When I'm ready to "check in," I update my local mirror branch, which always succeeds without conflicts because I haven't changed my working copy of that branch. Then I merge my feature branch into my local mirror branch, then push my local mirror branch to the central repository.
The advantage of this setup in your case is you could use bzr merge --preview or bzr diff to see the changes if you don't want to actually try the merge. I personally prefer just to revert the merge until the conflicts are fixed either upstream or in my local feature branch.