On Wed, Nov 2, 2011 at 18:45, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Nov 2, 2011 at 6:19 PM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> I'm not saying that you shouldn't use them - go ahead and use the >> feature if you like it. But please spare me your excuses for stupid >> workarounds that come from the fact that they aren't a good match for >> sane workflows. We often disagree. :-) > Btw, having now done odd things with signed tags (because we've used > them as a side-band verification mechanism), I can certainly also say > that the signed tags have their set of problems too. ... > But practically, all of these issues should be pretty easily solvable. > So it should be quite easy to make > > git pull <repo> <tag-name> > > just do the right thing - including verifying the tag, and adding the > information in the tag into the merge commit message. Uhm, sure. Quoting you 2 days ago: On Mon, Oct 31, 2011 at 15:52, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> So nobody is worried about this (quoting from my earlier message)? > > No, because you haven't been reading what we write. > > The tag is useless. > > The information *in* the tag is not. But it shouldn't be saved in the > tag (or note, or whatever). Because that's just an annoying place for > it to be, with no upside. > > Save it in the commit we generate. BAM! Useful, readable, permanent, > and independently verifiable. So you propose we put the tag contents into the merge commit message so it can be verified after the fact? So merges are now going to be something much more horrific to read, because it will end with Git object tag cruft, the tag message, and the PGP signature spew that no human can decode in the head? Oh, right, tags are almost good enough. Elsewhere in this thread you also stated we have to redo the way tags are signed so that the tag message body itself is not part of the signature, allowing you to fix spelin errors so you are not stuck with them in your commit history. But I assume we will have to keep the more typical headers of object / type / tag / tagger fields, as that is the key information the signature needs to be over to be of any value. So now there will be two different ways in which a Git annotated tag object will have its signature created, as certainly you don't mean to remove the tag message body from the PGP signature content for release tags. I fail to see how shoving Git object data fields and a complete PGP signature block into a merge commit message body, which will show by default in all git log type tools, and exist in cherry-picks or rebases that might make that data less valuable, is somehow better than the gpgsig header that neatly tucks it away until requested. I also fail to see how scraping the message body for the proper fields in order to implement automated verification of the signature (because no human can do it themselves and copy-paste sucks) is a good idea. Everywhere else in Git that we have machine readable formats its very well structured so that no guessing is required. > So signed tags are not mis-designed from a conceptual standpoint - > they just work really really awkwardly right now for what the kernel > would like to do with them. > > With a few UI fixes, I think the signed tag thing would "just work". Well, UI fixes, protocol changes, improvements to manage a large reference space which we have previously said is an insane and stupid workflow, etc. One reason you picked up all of those extra tags was the include-tag capability kicking on and picking up older tag history. We now have to disable it in certain cases. Its not just a few UI fixes. And there is a lot more work to write a verify for the tag contents+signature that appears in the body of a merge commit message. Not to mention we now have to do that verify logic twice, once in the signed pull request tag like but not quite a tag but uses a tag thing you are advocating, and again for the merge commit message body that contains the tag object data that we don't normally show to an end user, but will now be in every merge commit you make. Go ahead and call me stupid, but this already is a bigger amount of surgery to the git-core code, not to mention worse user experience for the average `git log` reading human, than having a hidden by default gpgsig header that might ask a contributor to take 2 extra seconds before making a commit to consider the useful lifespan of that commit. Or $DEITY forbid, write a new empty commit to record the equivalent of their Signed-off-by. Oh, and while I am on that subject... <rant> I have never grasped why sometimes a Signed-off-by is added to a patch, and why sometimes its not. It seems to be this weird function of "If the commit SHA-1 is already stable DON'T FUCKING TOUCH IT BY ADDING SIGNED-OFF-BY IT RUINS THE HISTORY", but if you are too far down the food chain to be fortunate enough for your commit SHA-1 to remain frozen, the Signed-off-by has to be added to assert that the code can be contributed. It sounds like the workflow developed around where it wasn't acceptable to force history rewriting, you suffer by not having the SOB, but whenever possible you force a history rewrite on the contributor just so you can add a SOB and feel good about the fact that the SOB is added to the commit message. Get over it. Add the fucking empty commit to show the flow of a change. Stop forcing every fucking contributor to rebase/rewrite his commits just so someone higher up in the food chain can wank with their SOB line. Everyone I talk to that contributes code to the kernel who isn't Linus or Ted Tso complains about this, and then asks me to fucking fix it. They want stable SHA-1s so they know their change arrived into Linus' tree unmolested. Unfortunately, despite their volume of changes, they aren't high enough in the food chain to be this lucky. Nope, someone has to wank their SOB in first. And maybe fix a spelin error. </rant> -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
