Re: [PATCH 0/2] Feeding an annotated but unsigned tag to "git merge"
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Wed, Jun 06, 2012 at 09:37:52AM -0700, Junio C Hamano wrote: > > 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. > > It is in line with --ff-only special casing, though. Is it? My impression from reading b5c9f1c is that --ff-only trumps both annotated _and_ signed tags. Which makes sense to me. What I was objecting to is that "some tag objects are more equal than others". It's OK to treat unannotated tags differently from tag objects, but treating annotated but unsigned objects differently from signed objects seems unnecessary and complex. > This was triggered by > http://thread.gmane.org/gmane.comp.version-control.git/198828 The complaint in that thread mentions git's v18.104.22.168, which is signed, and therefore would not be impacted by change. But perhaps that was purely for illustrative purposes. -Peff -- 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
[Newbies FAQ] [Linux Kernel Development] [Free Online Dating] [Gcc Help] [IETF Annouce] [DCCP] [Netdev] [Networking] [Security] [V4L] [Bugtraq] [Free Online Dating] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Linux SCSI] [Fedora Users] [Linux Resources]