On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano <gits...@pobox.com> wrote:

>> Which raises another question on my side: Isn't it tedious for you to
>> both update DEF_VER *and* tag a version? Wouldn't it probably be less
>> error prove (in the sense of keeping DEF_VER and tagged version in
>> sync) to remove DEF_VER completely and just die if all ways to derive
>> a Git version fail?
> I do not see how it will fly well.  Some people want to build out of
> tarballs without having any "describe", and DEF_VER and version were
> added for that specific purpose.

Right, but do we really need DEF_VER *and* version? Couldn't we just
package official source tarballs in a way that they already contain an
auto-generated version file?

>>> a case where you have your own tag that points at the exact version
>>> as I tagged?  In such a case, do you have a preference on which tag
>> No. I always carry patches on top.
> That answer sidesteps the real issue; which one would you prefer if
> there are two or more tags?  "describe" updated with your patch
> would consider both and I think it favours the annotated one over
> lightweight.  If it matches the preferred order then G-V-N with you
> patch would help your workflow; otherwise you would still need a
> different way, e.g. making sure what you want it to use is always
> used by doing the ">version" thing.

My answer sidesteps the issue because you were explicitly offering the
sidestep in you original question ;-) Anyway, in such a scenario I
would probably prefer my own tag instead of upstream's tag, to be
honest. So you're right that in this case my patch won't help. But
like I said, the case is not valid for me as I will always carry
patches on top, and other people might feel differently about which
tag (annotated vs. lightweight) they prefer if both point to the same

Sebastian Schuberth
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to