What bzr version did I branch from? - bazaar

I did a "bzr branch" from my team's bazaar repository and then committed some changes to my local branch. How can I determine what revision number I initially branched from?

Run bzr missing URL/to/team/branch and see what's the lowest number of your and theirs revisions (in the case branches have diverged). Previous number is the point where from you branched.

Look at bzr log the revision after your commits is the one you branched from. The branch point is not stored by Bazaar as far as I know.

If your team's branch is named differently to your local branch, you can run bzr log and look at the branch nick: field. The first revision with your team's branch name is the base revision.
Alternatively, you could look at the creation date of your branch folder. Check that against the timestamps in the commit log.

Related

Git. How to update feature branch withour merging unneccessary commits?

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.

How to rebase branch in IBM Clear Case

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.

Need to find commits on a specific branch

Can someone please share a code snippet that shows how I can pick out commits on only ONE branch using the JGit API.
If I use RevWalk, I get the entire tree, including sub-branches that have been merged into the specified branch.
How can I get JUST the commits on the specified branch without picking up parent commits of branches that may have been merged into the specified branch?
What may also help is to find out what branch a certain commit is sitting on.
Adding some more info:
How can I get all commits along the develop branch?
So based on the image above, I need SHAs:
2a34
b468
785c
but NOT:
731a
cbdb
Thanks!
In order to traverse the history of a Git repository, starting at a certain branch, you can use the LogCommand as described here: JGit: How to get all commits of a branch? (Without changes to the working directory ...)
The command's addFilter() method can be used to install a RevFilter to exclude certain commits.

Bazaar -- remove ALL local changes

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.

Create a bzr branch that selectively omits some commits from parent branch

Is it possible to create a branch of a bzr repository that selects omits certain changes? For example, let's say my repository is at revision 354, and I want to branch it, but I don't want to include the changes that were done in revision 247.
Note that I plan to merge in the changes from revision 247 at some point in the future. So I don't want to just make changes to the code that undo what revision 247 did, otherwise there will be a conflict later when I try to do the merge.
Is this type of selective branching possible with bzr?
I think you're looking to Reverse Cherrypick. This will let you remove a single revision from a branch.
no.
A revision always guarantees all of it's parent revisions.
I don't think you will have too many conflicts if you first undo and commit that revision and then later re-apply it.
If you are unsure branch into a temp directory and try it out.