On Tue, Jun 05, 2012 at 12:58:30PM -0700, Junio C Hamano wrote:
> This two-patch series further loosens the definition by considering
> that an annotated but unsigned tag can be fast-forwarded as long as
> it points at a commit that can be fast-forwarded to. So
>
> $ git merge anno
> $ git merge --ff anno
>
> will now fast-forward (note that this will *not* happen for signed
> tags).
>
> I find this change somewhat iffy myself, as we are encouraging
> people to lose information (i.e. the contents of the annotated tag
> is no longer recorded in the history) and some may see it as a
> regression in the post 1.7.10 world because of that.
>
> But since I've written it already, I thought it might be worth
> showing it to the list for discussion, if only to publicly reject
> the idea ;-).
It has been nearly a day, and nobody has publicly rejected it. So I will
do so. :)
This just doesn't make sense to me. Why would we treat annotated but
unsigned tags differently from signed tags? In both cases, the new
behavior is keeping more information about what happened, which is
generally a good thing.
I haven't seen any good argument against creating these merges[1]. But
even if there was one, I don't think "signed versus unsigned" is
necessarily the right distinguishing feature. It is probably more about
per-project or per-user preferences (e.g., "my project does not want too
many merges, because it makes our history less pretty"). And in that
case, something like a config flag would be a better option (not that I
am not saying that such a flag is a good idea, only that it might be
less bad than this).
-Peff
[1] From the tone of your message, I think you are not the right person
to be arguing that side, anyway. It sounds as though you are not all
that invested in this series. :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html