Opened 2 months ago

Last modified 2 months ago

#29905 new defect

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

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: devops git-maintance-scripts easy
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'd like the merge-forward script (see #29391) 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 :)

Child Tickets

TicketStatusOwnerSummaryComponent
#29692newAdd a git-reset-all script to tor's git scriptsCore Tor/Tor

Change History (3)

comment:1 Changed 2 months ago by asn

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.

comment:2 Changed 2 months ago by asn

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

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?

comment:3 in reply to:  2 Changed 2 months ago by teor

Replying to asn:

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

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

Note: See TracTickets for help on using tickets.