9

The question is: how do I achieve the correct version (shown with git describe) on develop after I merged it into master and tagged master?

I use common git branching - master for production. Let's say git describe shows 1.5 on master, and, after merging with develop, master shows 1.5-234-g1e894af.
So I create a new annotated tag with git tag -a 1.6 and thus git describe master now shows 1.6.

BUT: git describe develop still shows 1.5-something, which is strange as for me - it has same commits as in master - why Git thinks it still belongs to 1.5 version?

Nothing better comes into my brain, so I just merge master into develop, and after that develop shows version 1.6-2-... which is acceptable but produces 1 more useless merge commit, and warns me about "merge made by recursive" which I also think makes no sense to do, but how to achieve correct version then?

aynber
  • 22,380
  • 8
  • 50
  • 63
Denis Chmel
  • 780
  • 6
  • 11

2 Answers2

3

It sounds like something is wrong with your use of git. If you are merging develop to master, but never master to develop, then master is free to diverge — any changes on master will never get into the develop branch. Therefore your statement that they have the same commits is false. Using VonC's diagram,

m(1.5)--m1--m2--m(1.6, master)
 \              / 
  d-------d----d (develop)

The commits I've labeled "m1" and "m2" will never get onto "develop". If there are no such commits — you do no work on master — then when you do a merge of develop into master it should be a fast-forward merge; they would have the same commits then, and everything would work as you have described.

The solution depends on the workflow you're trying to achieve, of course.

  • Personally, I would at this point either delete and recreate the develop branch starting from master, or fast-forward it to 1.6, so that when you continue working on develop you have this structure:

    m(1.5)--m1--m2---m(1.6, master)
 \              / \ 
  d-------d----d   d--d (develop)

    Then git describe will consider it to be based on 1.6 as it actually is.

  • If your intent is that develop is a continuous development branch, and master is the occasional "release" branch, then you should avoid creating any commits like m1 and m2; insofar as you do, git describe is accurately telling you that something is different.

I'm not an expert on using git in teams, so take all of this with a grain of salt.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108
  • Oh, thanks. At least I've understood what VonC meant :) Of course if develop doesn't have all master commits it may not be the same version. But in my case I always merge into develop after commiting anything in master. I just thought in this particular case it is strange to merge to and from master, to get two merge commits (not one) just to make git think they are now same branches, so same versions. – Denis Chmel Feb 05 '12 at 21:35
  • If you recreate the branch, or fast-forward-merge master to develop, then there will be only one merge commit. – Kevin Reid Feb 05 '12 at 22:16
2

Considering git describe is about "finding the most recent tag that is reachable from a commit", it seems ok that a git describe on develop get back to master at a commit where your new 1.6 tag wasn't yet set.

m(1.5)--m--m--m(1.6, master)
 \            / 
  d-------d--d (develop)          => git describe develop will return 1.5-xxx

After merging master to develop

m(1.5)--m--m--m(1.6, master)
 \            / \
  d-------d--d---d (develop)      => git describe develop will return 1.6-xxx

If other contributors aren't working on develop, you could consider rebasing develop branch on top of master, in order to get back your expected tag. (git rebase)

m(1.5)--m--m--m(1.6, master)
               \            
                d--d--d (develop) => git describe develop will return 1.6-xxx
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yes, the same picture I imagined as well. Rebase is team-unfriendly of course, plus changes commit IDs (we refer to them in bugtracker). Still I think there should be a way to back-merge just a tag. It must be a common problem, and I doubt everyone is rebasing or back-merging :( – Denis Chmel Feb 05 '12 at 19:59
  • Shouldn't the merge "master to develop" (diagram 2) be a fast-forward (with 'develop' at the 'master' commit)? – ysdx Feb 05 '12 at 20:10
  • @ysdx: I had your "generating a useless commit" in mind when drawing the diagram. The idea remains that `git describe` will return 1.6 only after merging back `master` to `develop`. – VonC Feb 05 '12 at 20:55