Possible to submit a commit to already pushed branch.

[Andree Holz]

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?

[Andree Holz]

Hi,

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?

Andree

[cofarrell]

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?

Charles

[cofarrell]

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. :)

Cheers,

Charles