git-maintainance-scripts: merge-forward should provide indications of merges actually occuring

I'd like the merge-forward script (see #29391 (moved)) to highlight me the merge-forwards that actually merged something, contrary to the ones that were NOPs.

My fear is that I will have left some garbage in my worktrees and a merge-forward will merge forward something that I have not anticipated (e.g. from 035 to 040, when I just wanted to merge-fwd from 040 to master).

This has not yet happened, but I'd like as much protection as possible when using these automatic tools :)

changed milestone to %Tor: unspecified

Trac:
Child Ticket(s): #29692 (moved)

added component::core tor/tor devops easy git-maintance-scripts milestone::Tor: unspecified priority::medium severity::normal status::new type::defect labels

In particular here is how a merge-forward looks like, for a merge-fwd only between maint040->release040->master:

$ ./git-merge-forward.sh 
  [+] Fetching origin...success
[+] Handling branch 
release-0.2.9 Handling branch 
  [+] Switching branch to release-0.2.9...success
  [+] Merging branch origin/release-0.2.9...success
  [+] Merging branch maint-0.2.9 into release-0.2.9...success
[+] Handling branch 
maint-0.3.4 Handling branch 
  [+] Switching branch to maint-0.3.4...success
  [+] Merging branch origin/maint-0.3.4...success
  [+] Merging branch maint-0.2.9 into maint-0.3.4...success
[+] Handling branch 
release-0.3.4 Handling branch 
  [+] Switching branch to release-0.3.4...success
  [+] Merging branch origin/release-0.3.4...success
  [+] Merging branch maint-0.3.4 into release-0.3.4...success
[+] Handling branch 
maint-0.3.5 Handling branch 
  [+] Switching branch to maint-0.3.5...success
  [+] Merging branch origin/maint-0.3.5...success
  [+] Merging branch maint-0.3.4 into maint-0.3.5...success
[+] Handling branch 
release-0.3.5 Handling branch 
  [+] Switching branch to release-0.3.5...success
  [+] Merging branch origin/release-0.3.5...success
  [+] Merging branch maint-0.3.5 into release-0.3.5...success
[+] Handling branch 
maint-0.4.0 Handling branch 
  [+] Switching branch to maint-0.4.0...success
  [+] Merging branch origin/maint-0.4.0...success
  [+] Merging branch maint-0.3.5 into maint-0.4.0...success
[+] Handling branch 
release-0.4.0 Handling branch 
  [+] Switching branch to release-0.4.0...success
  [+] Merging branch origin/release-0.4.0...success
  [+] Merging branch maint-0.4.0 into release-0.4.0...success
[+] Handling branch 
master Handling branch 
  [+] Switching branch to master...success
  [+] Merging branch origin/master...success
  [+] Merging branch maint-0.4.0 into master...success

It shows no indication that the merging happened only between these tree worktrees.

Yikes, I spoke too soon I think I just did this exact mistake in #29806 (moved).

Apparently I was experimenting with a merge-forward that was not working and left garbage into my release-0.3.4 worktree (which I should not have messed up with in the first place). Then I git-pull-all.sh which did not complain that release-0.3.4 is not identical to origin/release-0.3.4.

So another useful thing would be to establish the assumption that after git-pull-all all the worktrees are completely synched with upstream? Does this work for everyone?

Replying to asn:

Yikes, I spoke too soon I think I just did this exact mistake in #29806 (moved).

Apparently I was experimenting with a merge-forward that was not working and left garbage into my release-0.3.4 worktree (which I should not have messed up with in the first place). Then I git-pull-all.sh which did not complain that release-0.3.4 is not identical to origin/release-0.3.4.

So another useful thing would be to establish the assumption that after git-pull-all all the worktrees are completely synched with upstream? Does this work for everyone?

If there are different PRs for different maint branches, we need to be able to merge to multiple maint branches, then merge forward.

Here's what that session might look like: (Using #29806 (moved) as an example.)

1. Reset all trees to origin
2. Merge PR for maint-0.3.4 into that branch
3. Merge PR for maint-0.3.5 into that branch
4. Merge PR for maint-0.4.0 into that branch
5. Merge forward

• merge forward does an implicit pull-all, but it must not do a reset

6. Push all

• should push-all do an implicit pull-all, to check for conflicts?

I would also like the reset-all, pull-all, and merge-forward scripts to list the branches that were changed, at the end of their output. (push-all already lists the pushed branches, using git.)

mentioned in issue #29692 (moved)

moved to tpo/core/tor#29905 (closed)