tpope / git-bump

Create Git release commits and tags with changelogs
MIT License
256 stars 6 forks source link

git bump next isn't correct tag #4

Closed adamyonk closed 10 years ago

adamyonk commented 10 years ago

I'm not sure exactly what the issue is here - git bump tries to set a tag that has already been set, git bump next shows the incorrect next tag.

 ➔ git tag | grep v83.
v830
v831
v832
v833
v834
v835
v836
v837
v838
v839
 ➔ git bump next
834

The latest tag is v839, but bump is wanting to set v834. Does this not work because it's just a vXXX instead of vX.X.X?

tpope commented 10 years ago

Single numbers should work. Is v839 a direct ancestor of your current commit?

adamyonk commented 10 years ago

Can I check that with branch --merged? If so,

➔ git branch --merged v839
  feature/alert_conditions_v2
tpope commented 10 years ago

Here's the logic git-bump uses: https://github.com/tpope/git-bump/blob/f726e49367fea031dad54dc16f64b5c38b533188/lib/git_bump.rb#L77

One other thing to check is the commit date, as that's how git-bump sorts.

adamyonk commented 10 years ago

That all seems to line up. Does it have something to do with the subjects being different?

➔ git for-each-ref "refs/tags/v[0-9]*" --sort="*committerdate" --format="%(refname:short) %(*objectname) %(subject)"
…
v824 bef38c6bbca943c1b662d3a5d49e7d7da257494e Version 824
v825 58a7b57765ff7478e704600342f11154a15d7545 Version 825
v826 de361b6b4ed02c1b9b9b8150e9643f8c3bd595e0 v826
v827 d2097272eee51f00b46da53957ad3d774f98b058 v827
v828 0bbae80e0f5d104863e714a4432060c75d861ba8 v828
v829 3812cfe71b04c424f4084446b946c487e3245564 v829
v830 b815cca15139f801c20a0252faa038759a3d67d3 v830
v831 225d1c08b0edef3deae54f4b65ef471ddb110bf9 v831
v832 bf1480d6a0f8c65b3c40ae3d0bcdf02ddb1093a4 v832
v833 c68c9ca19c1c9ea25cb4bbda60f2816888ec5445 Version 833
v834 cbd5b0abeefa235b4f581d635700145b4272c1a4 v834
v835 b6e11db926e077d0fcd1e17a416a6b03aec6fc1d v835
v836 493b9145f8eef660a256f433800fbb75903ba375 v836
v838 80ab1a27ed3a9a072f03a6187196c054ec562b37 v838
v839 f32bc2a4166b449a709cf9bb5c31c1a4f48c6d63 v839
v840 4e0d3a99d847ea26e4b897a2f1e12a1cd5b9f1ca v840
v841 dfeb5ccc6ca1eeca29e759103d02d1ea644fa33e v841
v842 9b15e019dde903ac210a31676cd65d50ada05a46 v842
v843 689dfe0394d4e5d673605ca1cc3ac700c18cab48 v843
v844 760e50c20068071396e05518361b0e14ae54456c v844
v846 666158ae1b6b8cc44657c7d8239c389be4f25291 v846
v845 666158ae1b6b8cc44657c7d8239c389be4f25291 v845
v847 63c424c7bdaf24f04d9bdda1f0825b43aeaf8c16 v847
 ➔ git merge-base 63c424c7bdaf24f04d9bdda1f0825b43aeaf8c16 HEAD
63c424c7bdaf24f04d9bdda1f0825b43aeaf8c16
tpope commented 10 years ago

Oh, that's it. It's currently adamant about <project> <version> commit messages, and Version <version> squeaks by. If you do one in the proper format, future invocations should work properly.

adamyonk commented 10 years ago

Aha! Thanks a lot for working through that with me.