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 commit. -- 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
