Cannot import when there is multiple tags on same commits

Bug #1625878 reported by Mathieu Gagné
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
git-upstream
Status tracked in Trunk
0.12
Fix Released
Undecided
Unassigned
Trunk
Fix Released
Medium
Darragh Bailey

Bug Description

I'm trying to import 2015.1.4 tag from Nova project.
This tag also matches an existing tag: kilo-eol.

To import a specific tag, I created a temporary branch:

  git branch temp-import/2015.1.4 2015.1.4

I can import (without merge) just fine:

  git-upstream import --no-merge temp-import/2015.1.4

However git-upstream is using the tag kilo-eol to construct the import branch resulting in using import/kilo-eol instead of the expected import/2015.1.4.

Thus when finalizing the import:

  git-upstream import --finish --into local/kilo --import-branch import/2015.1.4 temp-import/2015.1.4

I get this error:

  Searching for previous import
  Merging import to requested branch 'local/kilo'
  ERROR : Failed to finish import by merging branch:
      'import/2015.1.4'
  into and replacing the contents of:
      'local/kilo'

  ERROR : 'git merge --no-commit -s ours import/2015.1.4' returned with exit code 128
  stderr: 'fatal: import/2015.1.4 - not something we can merge'

I end up with those branches being created:

  import/kilo-eol
  import/kilo-eol-base

Instead of the "expected" branches with import/2015.1.4 prefix.

Revision history for this message
Darragh Bailey (dbailey-k) wrote :

I've been able to reproduce this, but only if I skip one of the steps mentioned above.

To set up a test repo I've doing the following in the base of git-upstream:

 # reset to commit at HEAD of master at the time
 git checkout b7dc443ea0b0fef7d618d68b3fd57c60e701ff8a
 tox -e py27
 tox -e build-tree -- git_upstream/tests/commands/import/interactive_scenarios/basic.yaml
 source .tox/py27/bin/activate
 cd .git-test-trees/basic
 git tag 2015.1.4 upstream/master

Then I've followed your steps (with the only different is that I'm using master as target):

 git branch temp-import/2015.1.4 2015.1.4
 git-upstream import --no-merge temp-import/2015.1.4

Which returned the following output:

 Searching for previous import
 Starting import of upstream
 Successfully created import branch
 Attempting to linearise previous changes
 Successfully applied all locally carried changes
 Import complete, not merging to target branch 'HEAD' as
 requested.

And then running:

 git-upstream import --finish --into master --import-branch import/2015.1.4 temp-import/2015.1.4

Returned:

 Searching for previous import
 Merging import to requested branch 'master'
 Successfully finished import:
     target branch: 'master'
     upstream branch: 'temp-import/2015.1.4'
     import branch: 'import/2015.1.4'

However when I run the following steps instead:

 git branch temp-import/2015.1.4 2015.1.4
 # note no import with --no-merge
 git-upstream import --finish --into master --import-branch import/2015.1.4 temp-import/2015.1.4

I see the response of:

 Searching for previous import
 Merging import to requested branch 'master'
 ERROR : Failed to finish import by merging branch: 'import/2015.1.4'
 With commit: 'import/2015.1.4'
 into and replacing the contents of: 'master'

 ERROR : 'git merge --no-commit -s ours import/2015.1.4' returned with exit code 1
 stderr: 'merge: import/2015.1.4 - not something we can merge'

So I'm wondering if perhaps this was just accidental missing a step? As the Nova project is more complex it may not be obvious when running 'git log --decorate --graph --all --oneline' as to what exactly is happening that a step was missed, and also I believe there were other bugs causing some problems.

Any chance you could retest the steps you used with both the commit from git-upstream at the time, and if it does reproduce could you attach a log file (using 'git upstream --log-level debug --log-file myimport.log ...' for both commands will work just fine) from that run and then confirm whether it still occurs with the latest HEAD as well.

Changed in git-upstream:
assignee: nobody → Darragh Bailey (dbailey-k)
assignee: Darragh Bailey (dbailey-k) → nobody
assignee: nobody → Darragh Bailey (dbailey-k)
status: New → Incomplete
Revision history for this message
Darragh Bailey (dbailey-k) wrote :

At the very least this suggests that the '--finish' phase is not validating the import branch reference given is valid to ensure an intelligent error message that helps the user. But would be good to confirm that this is all that is missing.

description: updated
Revision history for this message
Darragh Bailey (dbailey-k) wrote :

Working through this with the bug author identified what is going on.

When importing using a name that is similar to a tag, the present of other tags may result in a non-deterministic result from 'git describe' picking the other tag to construct the import branch name from.

Since this name is not printed during the normal execution using --no-merge before attempting to rebase the import, any conflicts will result in no message being displayed indicating the name of the import branch to the user.

Thus the user may presume the wrong name and the subsequent finish command will be incorrect and fail with a non-obvious error.

The issues contained are git-upstream:

1. Should always use the original tag name in the import -> most likely resolved by supporting importing by tags see https://bugs.launchpad.net/git-upstream/+bug/1547180
2. Should always print to the console the import branch being used even with --no-merge is specified
3. Should provide a better error message should the user execute the --finish command with an invalid branch/reference specified to --import-branch.

Revision history for this message
Darragh Bailey (dbailey-k) wrote :

Confirmed that unfortunately 'git describe <tag>' can pick a different tag if multiple tags apply to the same commit, so necessary to establish if already given a tag and only otherwise attempting to describe it if not.

Changed in git-upstream:
status: Incomplete → Confirmed
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to git-upstream (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/381930

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Related fix proposed to branch: master
Review: https://review.openstack.org/381931

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to git-upstream (master)

Fix proposed to branch: master
Review: https://review.openstack.org/381963

Changed in git-upstream:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to git-upstream (master)

Reviewed: https://review.openstack.org/381930
Committed: https://git.openstack.org/cgit/openstack/git-upstream/commit/?id=f243bd6355754a0e4c77eb8a6a4abeb70d1a8b48
Submitter: Jenkins
Branch: master

commit f243bd6355754a0e4c77eb8a6a4abeb70d1a8b48
Author: Darragh Bailey <email address hidden>
Date: Tue Oct 4 14:43:29 2016 +0100

    Use tag for import branch naming when given

    When importing using a tag for the upstream point to use, use the given
    tag provided instead of running describe against it again as this might
    result in the wrong tag being returned.

    The documentation for git describe states that when provided a tag,
    `git describe <tag>` will simply return the given tag, however
    when it is not an annotated tag it is possible for there to be multiple
    tags on the same commit and `git describe` may return any of them
    instead of the originally given tag. Explicitly add a check to see if
    the commit(ish) reference to import from is a tag and skip calling `git
    describe` in such a case.

    Change-Id: I7c6c3c2eb138089ccbc13d773da3d8a4a8efe673
    Related-Bug: #1625878

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/381931
Committed: https://git.openstack.org/cgit/openstack/git-upstream/commit/?id=0e30d3898b6e1f0542aa252b54706a572f9e52d5
Submitter: Jenkins
Branch: master

commit 0e30d3898b6e1f0542aa252b54706a572f9e52d5
Author: Darragh Bailey <email address hidden>
Date: Tue Oct 4 15:46:50 2016 +0100

    Report import branch name used by default

    To avoid users needing to assume the name of the import branch created,
    ensure that by default the name is outputted as part of a message to
    the user.

    Change-Id: I3e633d1431d77f9c89e986755004a5904dbc0952
    Related-Bug: #1625878

Changed in git-upstream:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to git-upstream (master)

Reviewed: https://review.openstack.org/381963
Committed: https://git.openstack.org/cgit/openstack/git-upstream/commit/?id=691ae783e0174909bd4fe0bc86176869ef2103e1
Submitter: Jenkins
Branch: master

commit 691ae783e0174909bd4fe0bc86176869ef2103e1
Author: Darragh Bailey <email address hidden>
Date: Tue Oct 4 17:06:02 2016 +0100

    Check valid import branch argument value

    Report invalid import branch to user when combined with --finish option
    as the value provided to --import-branch must be a valid reference.

    Change-Id: Ibd9e52bd4e387e997cb845721e49a91520989298
    Closes-Bug: #1625878

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.