Possible to submit a commit to already pushed branch.

In gerrit it's possible to re-push commits to already pushed branch.

To do this, you only need to add a change-id into the commit (also possible with a git hook script).

My Question now, is this also with stash possible?

2 answers

Hi Andree,

I hope I get this right, I'm not really a Gerrit expert. From what I understand that you use the change-id in Gerrit to re-associate commits on a single review when doing a rebase?

So in Stash we don't really have the same concept. You can quite happily rebase and force-push (assuming it isn't disabled) and Stash will happily update the pull request accordingly. Comments on the full PR diff should be migrated if possible, just like if you had pushed a new commit.

While I'm a big fan of rebasing, on the Stash team I've found it better _not_ to rebase during a pull request, or at least not when making alterations. If the changes are really part of a previous changeset, I normally push a new commit first, so that reviewers receive a notification with a direct link. After that, or perhaps at the end of the review, I might then do one final rebase. If you're not worried about reviewers being able to see those minor alterations then just ignore me. :)




yes you are right I use the change-id to re associate commits to already pushed commits at gerrit and gerrit is showing those commit's as a new version from the previously pushed commits.

So in stash I couldn't change as an example the first commit of already pushed branch. I need to write a new commit an push it to stash?


Hi Andree,

You have two choices:

1. Create a new commit with your changes and push. The branch will still include the original commits.

2. Rebase and amend the first commit (which will then require you to force push). I imagine this is roughly equivalent to using the change-id in Gerrit.

Both of these will work just as well with Stash. As mentioned, the only problem with rebasing is that reviewers can't see what actually changed, just that you removed all the old commits and added new ones. You may or may not like this.

I recommend maybe trying both and see which you prefer.

My own workflow is to push new commits first, so that reviewers can see what changes I've made, and then to rebase just before merging to cleanup history (but not to actually change anything).

Does that make sense?


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 06, 2018 in Bitbucket

Upgrade Best Practices

Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...

679 views 5 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you