help for the re-merge case when overwriting tags is the default

Bug #1648391 reported by Christian Ehrhardt  on 2016-12-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
usd-importer
Medium
Unassigned

Bug Description

Hi,
as discussed to log the idea of our talk.
When you have a re-merge tags like new/debian will change - please consider detecting the case and make it work for the most common case.

Nish Aravamudan (nacc) on 2016-12-19
Changed in usd-importer:
importance: Undecided → Medium
Nish Aravamudan (nacc) wrote :

Can you give some notion of the algorithm you are thinking of here?

Nish Aravamudan (nacc) on 2017-04-11
Changed in usd-importer:
status: New → Incomplete

I hope I remember the right case here, I think this was about not needing --force for the common cases.
One of these common cases is
1. doing a merge creating new/debian (and others)
2. a cycle later you'd do "git fetch --all"
3. run "usd merge" to set the tags to the right spot
   This needs --force today, but will become a common case.

In some sens we don't want users to use --force by default.

I haven't tried for a long time, it might even work today?

Pseudo Code:
1. if creating the three tags of "usd merge" check if they are already around
2. if so you know that those will collide
3. prompt to the user of what you found and provide a "<bla>, do you want to set force Y/N"?

If your --force today forces more than those three you might want a softer --force-tags and set that on behalf of step #3 being answered with yes. Also users enabling --force-tags by default is only half as bad as doing so with a more far reaching --force.

Nish Aravamudan (nacc) on 2017-08-02
Changed in usd-importer:
status: Incomplete → New
tags: added: workflow
Changed in usd-importer:
status: New → Triaged
milestone: none → 1.0
Robie Basak (racb) on 2017-11-28
tags: added: merge
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers