nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Handling locked branches

Scott Hung

I'm creating a workflow for locked, older branches whereby a select few developers must approve changes made by the team. I plan to limit branch permissions & merge via pull requests (e.g. developer copies the old branch to a new branch, commits on the new branch, issues a pull request to merge the new & old branches and deletes the new branch). My change showed up correctly, but so did a whole lot more:

After the pull request was merged, the commit tab showed many more commits than the one I did. They all look to be those that already existed on the old branch. 14 JIRA issues were also associated with the merge as their IDs were referenced in the old commits. What just happened?

Some investigation reveals:

The diff tab only shows the file I changed
The old branch has many JIRA issues on it, but the Overview tab only lists 14.
Fisheye shows the Merge pull request as having 15,179 commits - probably the number of commits on the original branch.
Fisheye's Commit Graph shows two parallel branches which merge at my pull request. Commit descriptions are also duplicated.

My conclusion is Stash treated this as two independent branches and completely merged them together. How should I structure this so it doesn't happen on production? I suspect it must have something to do with how I create the new branch...

Thanks for any help!

Scott

Accepted answers

cofarrell

Hi Scott,

This is how Git works. An ASCII graph that might help:

o----o----o----o A
      \---o----o B
           \---o C

So in this case what would you consider branch C? Obviously if you are merging to branch A then there are going to be two more commits after you merge. What happens if you then merge B? There will only be one new commit because the previous commit was part of the merge with C. If you look at branch B or C in Stash on the commit list we are going to show you every commit, going back in time, which will be 4 commits instead of 1 or 2. The important thing to realise is that Git doesn't label/associate branches with previous commits, it's just a pointer to the most recent commit. How many commits are on branch B or C is purely relative to where it is being merged, nothing more.

I hope that helps and that I've understood your problem correctly?

Charles

All comments

cofarrell

Hi Scott,

This is how Git works. An ASCII graph that might help:

o----o----o----o A
      \---o----o B
           \---o C

I hope that helps and that I've understood your problem correctly?

Charles

Scott Hung

Charles,

I'm impressed with your ASCII art abilities! Here's a screenshot from fisheye of the branch after the merge. I expected the commit history to be what's shown in purple and am trying to figure out how the stuff that's greyed out got there. They came in as part of the merge so perhaps I mis-created the branch originally? Any ideas appreciated.

Scott

cofarrell

Hi Scott,

Yeah something slightly odd has happened. Your first commt on the branch has two parents where the right-hand side shouldn't be there. Without having access to your repository I couldn't say for sure what or how that happened.

My suspicion is that someone merged master into the branch and then rebased after that. Git then 'recreated' the commits that has previously been merged from master. You can see if the author/message of those other commits are identical to commits on master, but have a different hash. If this is the case I would recommend that you warn your users about rebasing, and ideally disable force pushes on your repository in Stash. While rebasing is a great feature of Git, it requires that the user knows what they're doing and is quite easy to get into trouble. An ascii diagram to help.

After the merge

        A   B
o---o---o---o master
    |        \
     \--o-----o branch
         C     D

After the rebase

        A   B
o---o---o---o master
             \
              o----o----o---o branch
              A'   B'   C'  D'

In this case A' is the same patch/changes as A, but they are identified with a different unique hash.

This is only a guess, and I would need more information to say with any more certainty. Let me know if that doesn't make sense, of if you see something odd happening on your next merge. Stash certainly isn't doing anything apart from the merge.

Charles

cofarrell

Scott, and anyone else reading this. Apologies, I'm not sure what I was thinking when I posted my previous comment. Maybe I just wanted an excuse to write another ascii graph.

When someone created your branch it looks like they then merged with something, which was the right-hand side (grey) section of your screenshot. It's impossible to say why that happened without knowing what those commits are and/or asking someone how they created the branch. It might be that the original branch was created earlier and then when they pulled it merged with the latest from master, which would create something like what you see there. In which case those grey commits would be expected to be normal commits of your branch, broken up by a merge commit.

In any case let me know if it happens again and maybe we could take a closer look at your workflow.

Charles

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

git

branch

lock