{"thread":{"id":"6738","subject":"git-pull and tag objects","startedAt":"2007-02-08T11:16:46Z","lastAt":"2007-02-15T01:34:08Z","messageCount":26,"participants":["Alex Bennee","Alex Riesen","Junio C Hamano","Theodore Tso","Linus Torvalds","Jakub Narebski","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33936","messageId":"1170933407.15431.38.camel@okra.transitives.com","threadId":"6738","inReplyTo":null,"subject":"git-pull and tag objects","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2007-02-08T11:16:46Z","receivedAt":"2007-02-08T11:16:46Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"Hi,\n\nI have a master repositary which I keep in sync with a CVS server. Each\ntime it imports a new baseline it tags it with the baseline tag we use.\nThis allows for easy branching of \"baseline\" levels.\n\nI have slave repositaries which are cloned of the baseline which I do my\ndevelopment in. However when I bring the master branch of these work\nrepositaries upto date (via git-pull ../baseline master) I find the tag\nobjects are lost. Should they not be part of the tree? After all when I\nsync to Linus's kernel repo I get all his version tags as part of that.\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n\"Spare no expense to save money on this one.\" -- Samuel Goldwyn\n"},{"id":"34050","messageId":"81b0412b0702090133qa4eb0c0v6a2d309fe9653a3f@mail.gmail.com","threadId":"6738","inReplyTo":"1170933407.15431.38.camel@okra.transitives.com","subject":"Re: git-pull and tag objects","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-09T09:33:46Z","receivedAt":"2007-02-09T09:33:46Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/8/07, Alex Bennee wrote:\n> I have slave repositaries which are cloned of the baseline which I do my\n> development in. However when I bring the master branch of these work\n> repositaries upto date (via git-pull ../baseline master) I find the tag\n> objects are lost. Should they not be part of the tree? After all when I\n> sync to Linus's kernel repo I get all his version tags as part of that.\n\nYou have to use \"git pull ../baseline master:somewhere\".\nThis \"master:somewhere\" expression makes git fetch and stores\nthe tags along with the branch' commits. Better yet, create an\nentry in remotes: .git/remotes or .git/config, depending on the version\nof git you have. The current master on kernel.org has the support\nfor latter (branches in .git/config), which will also be in the upcoming\nrelease 1.5.\n"},{"id":"34081","messageId":"7v4ppurka1.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"81b0412b0702090133qa4eb0c0v6a2d309fe9653a3f@mail.gmail.com","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-09T23:19:50Z","receivedAt":"2007-02-09T23:19:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> You have to use \"git pull ../baseline master:somewhere\".\n> This \"master:somewhere\" expression makes git fetch and stores\n> the tags along with the branch' commits. Better yet, create an\n> entry in remotes: .git/remotes or .git/config, depending on the version\n> of git you have. The current master on kernel.org has the support\n> for latter (branches in .git/config), which will also be in the upcoming\n> release 1.5.\n\nWhile this is technically correct, the automatic tag following\nperformed by git-fetch (git-pull invokes git-fetch internally\nand it is done as the side effect) probably needs a bit more\ndetailed explanation.\n\nAutomatic tag following is done by first fetching from the\nremote using the given s, and if the repository has\nobjects that are pointed by remote tags that it does not yet\nhave, then fetch those missing tags. If the other end has tags\nthat point at branches you are not interested in, you will not\nget them.\n\nThere are currently two ways for you to get tags and one and\nhalf ways to decline.\n\n * \"git fetch --tags URL ...\" will download all tags.\n This has nothing to do with the automatic following.\n\n * \"git fetch URL ...\" (including the case where\n s are taken from the configuration files) will\n trigger automatic tag following only when s store\n the fetch result in tracking branches (this is what raa\n pointed out)\n\n * \"git fetch --no-tags URL ...\" forbids automatic tag\n following, even when s are the tracking kind.\n\nThe other half way to decline that is implicit in the above is\nto use s that do not store the result in tracking\nbranches.\n\nNow, the --no-tags option means \"Do not automatically follow\ntags\". But the --tags option does not mean the opposite. It\nmeans \"Do fetch _all_ tags\". We do not have an explicit option\nthat says \"Do follow tags\". It is implicitly decided based on\nthe kind of .\n\nThis is not a problem in practice and is a good heuristics that\ndoes the right thing for both people near the toplevel and\npeople who only follow others trees.\n\nIf you are following somebody else's tree, you are most likely\nusing tracking branches (refs/heads/origin in traditional\nlayout, or refs/remotes/origin/master in the separate-remote\nlayout). You usually want the tags from the other end.\n\nOn the other hand, if you are fetching because you would want a\none-shot merge from somebody else, you typically do not want to\nget tags from there. This happens more often for people near\nthe toplevel but not limited to them. Mere mortals when pulling\nfrom each other do not necessarily want to automatically get\nprivate 'anchor point' tags from the other person.\n\nYou would notice \"please pull\" messages on the mailing list says\nrepo URL and branch name alone. This is designed to be easily\ncut&pasted to \"git fetch\" command line:\n\n\tLinus, please pull from\n\n \tgit://git..../proj.git master\n\n\tto get the following updates...\n\nbecomes:\n\n $ git pull git://git..../proj.git master\n\nIn such a case, you do not want to automatically follow other's\ntags.\n\nOne important aspect of git is it is distributed, and being\ndistributed largely means there is no inherent \"upstream\" or\n\"downstream\" in the system. On the face of it, the above\nexample might seem to indicate that the tag namespace is owned\nby upper echelon of people and tags only flow downwards, but\nthat is not the case. It only shows that the usage pattern\ndetermines who are interested in whose tags.\n\nA one-shot pull is a sign that a commit history is now crossing\nthe boundary between one circle of people (e.g. \"people who are\nprimarily interested in networking part of the kernel\") who may\nhave their own set of tags (e.g. \"this is the third release\ncandidate from the networking group to be proposed for general\nconsumption with 2.6.21 release\") to another circle of people\n(e.g. \"people who integrate various subsystem improvements\").\nThe latter are usually not interested in the detailed tags used\ninternally in the former group (that is what \"internal\" means).\nThat is why it is desirable not to follow tags automatically in\nthis case.\n\nIt may well be that among networking people, they may want to\nexchange the tags internal to their group, but in that workflow\nthey are most likely tracking with each other's progress by\nhaving tracking branches. Again, the existing heuristic would\nautomatically follow such tags and that is a good thing.\n\nAlthough I do not think it is necessary for the above reasons,\nif somebody wanted to do it, it is easy and straightforward to\nmake the automated tag following more orthogonal by letting you\npass --do-follow-tags to \"git fetch\" to explicitly tell it to\nfollow tags even when you are not tracking the other side.\n\n--\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 357cac2..aef2159 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -17,6 +17,7 @@ IFS=\"$LF\"\n \n no_tags=\n tags=\n+follow_tags=\n append=\n force=\n verbose=\n@@ -46,6 +47,9 @@ do\n \t-t|--t|--ta|--tag|--tags)\n \t\ttags=t\n \t\t;;\n+\t--fol|--foll|--follo|--follow)\n+\t\tfollow_tags=t\n+\t\t;;\n \t-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)\n \t\tno_tags=t\n \t\t;;\n@@ -454,12 +458,11 @@ fetch_main () {\n fetch_main \"$reflist\" || exit\n \n # automated tag following\n-case \"$no_tags$tags\" in\n-'')\n-\tcase \"$reflist\" in\n-\t*:refs/*)\n-\t\t# effective only when we are following remote branch\n-\t\t# using local tracking branch.\n+if test -z \"$no_tags$tags\" && {\n+\ttest -n \"$follow_tags\" ||\n+\tcase \"$reflist\" in *:refs/*) :;; *) false ;; esac\n+ }\n+then\n \t\ttaglist=$(IFS='\t' &&\n \t\techo \"$ls_remote_result\" |\n \t\tgit-show-ref --exclude-existing=refs/tags/ |\n@@ -469,7 +472,6 @@ case \"$no_tags$tags\" in\n \t\t\techo >&2 \"Auto-following $name\"\n \t\t\techo \".${name}:${name}\"\n \t\tdone)\n-\tesac\n \tcase \"$taglist\" in\n \t'') ;;\n \t?*)\n@@ -477,7 +479,7 @@ case \"$no_tags$tags\" in\n \t\tshallow_depth=\n \t\tfetch_main \"$taglist\" || exit ;;\n \tesac\n-esac\n+fi\n \n # If the original head was empty (i.e. no \"master\" yet), or\n # if we were told not to worry, we do not have to check.\n"},{"id":"34084","messageId":"7vireaq36z.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"7v4ppurka1.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-fetch: document automatic tag following.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T00:14:12Z","receivedAt":"2007-02-10T00:14:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've added this to the documentation.\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/git-fetch.txt | 8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 7ecf240..5fbeab7 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -20,6 +20,14 @@ The ref names and their object names of fetched refs are stored\n in `.git/FETCH_HEAD`. This information is left for a later merge\n operation done by \"git merge\".\n \n+When stores the fetched result in tracking branches,\n+the tags that point at these branches are automatically\n+followed. This is done by first fetching from the remote using\n+the given s, and if the repository has objects that are\n+pointed by remote tags that it does not yet have, then fetch\n+those missing tags. If the other end has tags that point at\n+branches you are not interested in, you will not get them.\n+\n \n OPTIONS\n -------\n-- \n1.5.0.rc4.16.g9e258\n"},{"id":"34099","messageId":"20070210142322.GB25607@thunk.org","threadId":"6738","inReplyTo":"7v4ppurka1.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-10T14:23:22Z","receivedAt":"2007-02-10T14:23:22Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"Thanks for this great explanation of how tags work. Hopefully some or\nall of this can get incorporated into the git's user's manual.\nAdding the paragraph to the git-tag as you did in your patch is a\ngood start, but having the entire explanation of how things work in\nthe user's manual would be a really good thing, IMHO.\n\nThis brings up another question which I've been looking for, but for\nwhich I haven't found a good answer in the git documentation. A\ngoogle search shows a suggestion by hpa (and a brief discussion from\nsct) about how to handle conflicting tags back in 2005, but as far as\nI can tell it didn't go anywhere.\n\nAnyway, the questions that don't appear to be addressed in the git\ndocumentations are:\n\n1) Suppose I do a \"git tag\" of a release, and then realize that I\nmessed up, and I need to do some additional release work (i.e.,\nediting a debian changelog file, etc.) before really doing another\nrelease, what do I do to tag a later revision as the \"real\" version\nv1.2?\n\n2) Suppose I have v2.6.20 pointing to a particular revision, which was\nobtained from pulling from Linus's tree, and I pull from some other\ntree, say the wireless tree, and the maintainer there either\naccidentally or maliciously has the tag v2.6.20 pointing to some other\nrevision. What happens in that case? Does the answer change if the\ntag is a signed vs. unsigned tag?\n\n3) The git-tag man page talks about GPG signing tags, but it doesn't\ntalk about how a GPG-signed tag is validated. Does this happen\nmanually or automatically? If it happens manually, how should a tag\nbe verified? If the answer is using git-verify-tag, then there should\nprobably be better references in the documentation to git-verify-tag.\nIt might also be a very good idea to have a config option which\nautomatically verifies signed tags.\n\n4) Is there a good/easy way to show whether a tag is a signed\nvs. unsigned tag? Short of using \"git cat-file -t \", there\ndoesn't seem to be, and being forced to use a low-level git command to\nget that kind of information seems.... unsatisfactory.\n\nThanks,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"34128","messageId":"Pine.LNX.4.64.0702100938540.8424@woody.linux-foundation.org","threadId":"6738","inReplyTo":"20070210142322.GB25607@thunk.org","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-10T17:56:25Z","receivedAt":"2007-02-10T17:56:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Feb 2007, Theodore Tso wrote:\n> \n> This brings up another question which I've been looking for, but for\n> which I haven't found a good answer in the git documentation. A\n> google search shows a suggestion by hpa (and a brief discussion from\n> sct) about how to handle conflicting tags back in 2005, but as far as\n> I can tell it didn't go anywhere.\n\nI don't think we've ever had a conflicting tag.\n\n> 1) Suppose I do a \"git tag\" of a release, and then realize that I\n> messed up, and I need to do some additional release work (i.e.,\n> editing a debian changelog file, etc.) before really doing another\n> release, what do I do to tag a later revision as the \"real\" version\n> v1.2?\n\nWell, if you never pushed anything out, just re-tag it. Use \"-f\" to \nreplace the old one. And you're done.\n\nBut if you have pushed things out (or others could just read your \nrepository directly), then others will have already seen the old tag. In \nthat case you can do one of two things:\n\n - The sane thing.\n\n Just admit you screwed up, and use a different name. Others have \n already seen one tag-name, and if you keep the same name, you may be in \n the situation that two people both have \"version X\", but they actually \n have _different_ \"X\"'s.\n\n So just call it \"X.1\" and be done with it. \n\n - The insane thing.\n\n You really want to call the new version \"X\" too, _even_though_ others \n have already seen the old one. So just use \"git tag -f\" again, as if \n you hadn't already published the old one.\n\n HOWEVER!\n\n Git does *not* (and in my very very strong opinion, MUST NOT!) change \n tags behind users back. So if somebody already got the old tag, doing a \n \"git pull\" on your tree shouldn't just make them overwrite the old one. \n\nAnd I really think that git does the right thing. If somebody got a \nrelease tag from you, you cannot just change the tag for them by updating \nyour own one. I think this is a BIG security issue, in that people MUST be \nable to trust their tag-names. If I got a particular tag, NO WAY IN HELL \nmust git just replace it for me because you happened to have a newer one!\n\nSo if you really want to do the insane thing, you need to just fess up to \nit, and tell people that you messed up. You can do that by making a very \npublic announcement saying\n\n \"Ok, I messed up, and I pushed out an earlier version tagged as X. I \n then fixed somethign, and retagged the *fixed* tree as X again.\n\n If you got the wrong tag, and want the new one, you'll have to delete \n the old one and fetch the new one:\n\n\tgit tag -d X\n\tgit fetch origin X\n\n to get my updated tag.\n\n You can test which tag you have by doing\n\n\tgit rev-parse X\n\n which should return 0123456789abcdef.. if you have the new version\".\n\nDoes this seem a bit complicated? HELL YES. But it *should* be. There is \nno way in hell that it would be correct to just \"fix\" it behind peoples \nbacks. People need to know that their tags might have been changed.\n\n> 3) The git-tag man page talks about GPG signing tags, but it doesn't\n> talk about how a GPG-signed tag is validated. Does this happen\n> manually or automatically?\n\nUse \"git verify-tag X\" to see something like this:\n\n\t[torvalds@woody linux]$ git-verify-tag v2.6.17\n\tgpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB\n\tgpg: Good signature from \"Linus Torvalds (tag signing key) \"\n\nbut you obviously need to have the public key in question available to \nyou.\n\nWe could verify tags automatically, of course, but the question is, what \nwould the policy be? \n\n(Side note: the 'monotone' people do the trust thing very deep in \nmonotone, AND IT IS A COMPLETE DISASTER! I'm surprised they are not only \ncontinuing with it, they are adding more and more infrastructure exactly \nbecause once you do it automatically, you need to be able to handle any \npossible policy. It's insane. It's also really sad, because monotone gets \nso many things right. Their security model is just *totally* broken, and \nmakes the whole thing be just a steaming pile of shit. Sad. Not that the \nwhole C++/boost/STL crap exactly \"helps\" either, but the security thing \nis probably the more fundamental problem.)\n\n\t\t\tLinus\n"},{"id":"34141","messageId":"eqldhe$h7i$1@sea.gmane.org","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702100938540.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-10T21:32:05Z","receivedAt":"2007-02-10T21:32:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n \n> On Sat, 10 Feb 2007, Theodore Tso wrote:\n\n>> 3) The git-tag man page talks about GPG signing tags, but it doesn't\n>> talk about how a GPG-signed tag is validated. Does this happen\n>> manually or automatically?\n> \n> Use \"git verify-tag X\" to see something like this:\n> \n> [torvalds@woody linux]$ git-verify-tag v2.6.17\n> gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB\n> gpg: Good signature from \"Linus Torvalds (tag signing key) \"\n> \n> but you obviously need to have the public key in question available to \n> you.\n\nOne of the solutions, used in git.git repository, is to put public key\nas a out-of-tree blob using git-hash-object, then tag it using singed tag\nwith instruction about how to extract key in the tag message (tag comment).\n\n $ git cat-file -p junio-gpg-pub\n object 0246401b5d117e01717149c413aa2f8702a83d4f\n type blob\n tag junio-gpg-pub\n tagger Junio C Hamano Tue Dec 13 16:33:29 2005 -0800\n\n GPG key to sign git.git archive.\n\n This blob object contains the GPG public key I use to sign git.git\n archive.\n\n To use it to verify tags I signed, do:\n\n $ git-cat-file blob junio-gpg-pub | gpg --import\n\n to import it into your keyring, and then\n\n $ git-verify-tag $tag_to_be_verified\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"34142","messageId":"Pine.LNX.4.64.0702101347350.8424@woody.linux-foundation.org","threadId":"6738","inReplyTo":"eqldhe$h7i$1@sea.gmane.org","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-10T21:58:59Z","receivedAt":"2007-02-10T21:58:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Feb 2007, Jakub Narebski wrote:\n> \n> One of the solutions, used in git.git repository, is to put public key\n> as a out-of-tree blob using git-hash-object, then tag it using singed tag\n> with instruction about how to extract key in the tag message (tag comment).\n\nNo. That's horrible. Yes, it's what Junio did, but if you don't trust the \narchive, the _last_ thing you should do is to depend on a blob in the \narchive itself to contain the thing to make you trust it more.\n\nSo you want to get the gpg public key from somewhere else to be able to \n_independently_ verify that it's ok.\n\nOtherwise, somebody could just totally replace the object with one of \ntheir own, and then _claim_ that the public key they made is \n\"junio-gpg-pub\", and fool people into thinkign it's signed by Junio.\n\nSo to get a valid chain of trust, you really have to have some sideband \nchannel to get you started. There's a lot of infrastructure for that \nelsewhere (ie the whole \"sign other peoples keys\" thing that is so central \nto pgp), but even if you don't have a key to start with, you're actually \nbetter off getting a key (even with no other validation) from an \nindependent source than have it be in the repository itself. Because at \nleast then any attacker has to fake _two_ things, rather than just a \nsingle repo.\n\nOf course, in *practice* this is not a problem. And, in fact, thanks to \ngit's SHA1 setup, you obviously don't have to really verify the key itself \nin git, you really only want to verify that yes, the object name is \ncorrect (ie if you get some sideband information from Junio that the \n\"object 0246401b5d117e01717149c413aa2f8702a83d4f\" really is Junio's key, \nthat's sufficient in itself).\n\n(The \"sideband channel\" can be something as simple as google. For example, \nif you just google for the SHA1 of the tag itself, you'll actually get a \nlot of hits for it - a0e7d36193b96f552073558acf5fcc1f10528917 (which is \nnot the key itself, but it is the tag that points to it, which in turn is \nsigned with the key) shows up in manyplaces, and that very fact in itself \nis \"interesting\" as a sideband information. It's not \"proof\", but it's \ncertainly one piece of information that may make you more comfortable with \nthat tag not being something recent and fake - it's been around and been \nquoted by me in email archives, so if it's faked, it's fooled a number of \npeople).\n\n\t\tLinus\n"},{"id":"34147","messageId":"20070211002501.GB19656@thunk.org","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702100938540.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-11T00:25:01Z","receivedAt":"2007-02-11T00:25:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Feb 10, 2007 at 09:56:25AM -0800, Linus Torvalds wrote:\n> We could verify tags automatically, of course, but the question is, what \n> would the policy be? \n\nWhat I would propose (post-1.5.0!) is that the policy file be local to\nthe repository, and consist of an ordered list of regular expressions\nand and lists of PGP keys associated with each regexp. So for\nexample, I might have in my repository a config file which states that\nany tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be\nsigned by PGP key 0x76E21CBB (Linus's key).\n\nWhat I would very much like is for the tags to be automatically\nverified whenever I do a git-fetch operation, and for me to get a big,\nfat, warning if some tag isn't signed by an authoried key.\n\nSo this would help make sure that when I'm pulling from kernel.org,\nI'm getting something that originally came from Linus, and someone\nhasn't managed to insert trojan into the git tree, but it doesn't help\nin between releases. In order to solve that problem we would have to\nhave some kind of scheme where branch heads could be optionally\nsigned, and then transfered over to the public repository. Then, in\nthe git config file, we could list an expected set of keys that should\nsign any branch head for a particular tracking branch. \n\nSince all of this is local policy, someone who wanted to have a\ndifferent set of trusted peers, they could do so. And, of course,\nsomeone who wanted to run completely open with no gpg signature\nchecking at all could do so. (aka \"rms/rms mode\" :-)\n\nDoes this make sense?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"34151","messageId":"Pine.LNX.4.64.0702101919520.8424@woody.linux-foundation.org","threadId":"6738","inReplyTo":"20070211002501.GB19656@thunk.org","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-11T03:21:31Z","receivedAt":"2007-02-11T03:21:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Feb 2007, Theodore Tso wrote:\n> \n> What I would propose (post-1.5.0!) is that the policy file be local to\n> the repository, and consist of an ordered list of regular expressions\n> and and lists of PGP keys associated with each regexp. So for\n> example, I might have in my repository a config file which states that\n> any tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be\n> signed by PGP key 0x76E21CBB (Linus's key).\n\nActually, I think you can do it already.\n\nI think the \"update\" hook runs whenever we're pulling a ref, once for each \nref. It might happen just for pushing to a remote, though.\n\nAnyway, with a hook, it's easy enough to just add exactly the kind of \nthing you are outlining, and yes, it would be repository-local.\n\n\t\tLinus\n"},{"id":"34154","messageId":"7vy7n5gs0y.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702100938540.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T05:52:29Z","receivedAt":"2007-02-11T05:52:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But if you have pushed things out (or others could just read your \n> repository directly), then others will have already seen the old tag. In \n> that case you can do one of two things:\n> ...\n> - The insane thing.\n>\n> You really want to call the new version \"X\" too, _even_though_ others \n> have already seen the old one. So just use \"git tag -f\" again, as if \n> you hadn't already published the old one.\n>\n> HOWEVER!\n>\n> Git does *not* (and in my very very strong opinion, MUST NOT!) change \n> tags behind users back. So if somebody already got the old tag, doing a \n> \"git pull\" on your tree shouldn't just make them overwrite the old one. \n>\n> And I really think that git does the right thing. If somebody got a \n> release tag from you, you cannot just change the tag for them by updating \n> your own one. I think this is a BIG security issue, in that people MUST be \n> able to trust their tag-names. If I got a particular tag, NO WAY IN HELL \n> must git just replace it for me because you happened to have a newer one!\n>\n> So if you really want to do the insane thing, you need to just fess up to \n> it, and tell people that you messed up.\n\nConfession time.\n\nAlthough it is correct that the people who already saw the\noriginal tag would not lose the tag object from their repository\nwhen you publish a replacement tag, we have _always_ overwritten\nthe refs/tags/$tag to point at the new one, effectively losing\nthe original.\n\n* 0a623e7c (Jul 5, 2005)\nIn this version \"git fetch $repo tag v2.6.13\" would have done just\n\n\techo \"$head\" >\"$GIT_DIR/$destination\"\n\nwithout checking if it already existed.\n\n* ae2da406 (Aug 22, 2005)\n\nWe started checking if the fetched/followed tag already existed\nwith this version. However, the result of the check was only\nused to say \"$tagname: updating with $new_sha1 from $old_sha1\"\nin the status message.\n\nAnd after numerous code reorganizations of git-fetch throughout\nits life, this logic has never been touched. This comment\naround ll. 170 we currently have:\n\n case \"$1\" in\n refs/tags/*)\n\t# Tags need not be pointing at commits so there\n\t# is no way to guarantee \"fast-forward\" anyway.\n\nwas introduced with 853a3697 (Aug 20, 2005) and stayed there\never since.\n\nI think it is worth fixing this by tightening the rule as you\ndescribed, even with this late in the game for 1.5.0. The user\neither needs to force it, or remove it beforehand.\n\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 357cac2..1078016 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -169,14 +169,18 @@ update_local_ref () {\n \n case \"$1\" in\n refs/tags/*)\n-\t# Tags need not be pointing at commits so there\n-\t# is no way to guarantee \"fast-forward\" anyway.\n+\t# Tags should never be blindly overwritten without user's\n+\t# consent.\n \tif test -n \"$oldshort_\"\n \tthen\n \t\tif now_=$(git show-ref --hash \"$1\") && test \"$now_\" = \"$2\"\n \t\tthen\n \t\t\t[ \"$verbose\" ] && echo >&2 \"* $1: same as $3\"\n \t\t\t[ \"$verbose\" ] && echo >&2 \" $label_: $newshort_\" ||:\n+\t\telif test -z \"$force$single_force\"\n+\t\tthen\n+\t\t\techo >&2 \"* $1: refusing to update with $3\"\n+\t\t\tfalse\n \t\telse\n \t\t\techo >&2 \"* $1: updating with $3\"\n \t\t\techo >&2 \" $label_: $newshort_\"\n"},{"id":"34182","messageId":"Pine.LNX.4.64.0702110948120.8424@woody.linux-foundation.org","threadId":"6738","inReplyTo":"7vy7n5gs0y.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-11T17:49:21Z","receivedAt":"2007-02-11T17:49:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Feb 2007, Junio C Hamano wrote:\n> \n> Although it is correct that the people who already saw the\n> original tag would not lose the tag object from their repository\n> when you publish a replacement tag, we have _always_ overwritten\n> the refs/tags/$tag to point at the new one, effectively losing\n> the original.\n> \n> * 0a623e7c (Jul 5, 2005)\n> In this version \"git fetch $repo tag v2.6.13\" would have done just\n> \n> \techo \"$head\" >\"$GIT_DIR/$destination\"\n> \n> without checking if it already existed.\n\nYes, but only if you actually explicitly asked for it, methinks.\n\nIf you just do a \"git pull\", it won't do it.\n\nSo I think it's ok. \n\n\t\tLinus\n"},{"id":"34183","messageId":"7vire8ec6w.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702110948120.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T19:17:27Z","receivedAt":"2007-02-11T19:17:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 10 Feb 2007, Junio C Hamano wrote:\n>> \n>> Although it is correct that the people who already saw the\n>> original tag would not lose the tag object from their repository\n>> when you publish a replacement tag, we have _always_ overwritten\n>> the refs/tags/$tag to point at the new one, effectively losing\n>> the original.\n>> \n>> * 0a623e7c (Jul 5, 2005)\n>> In this version \"git fetch $repo tag v2.6.13\" would have done just\n>> \n>> \techo \"$head\" >\"$GIT_DIR/$destination\"\n>> \n>> without checking if it already existed.\n>\n> Yes, but only if you actually explicitly asked for it, methinks.\n>\n> If you just do a \"git pull\", it won't do it.\n>\n> So I think it's ok. \n\nWell, what you are saying is that it used to be Ok in Jul 5 2005\nversion but with tag following it is not Ok anymore, isn't it?\n"},{"id":"34184","messageId":"7vejowec0a.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"7vire8ec6w.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T19:21:25Z","receivedAt":"2007-02-11T19:21:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> So I think it's ok. \n>\n> Well, what you are saying is that it used to be Ok in Jul 5 2005\n> version but with tag following it is not Ok anymore, isn't it?\n\nOops. I misread my own code.\n\nYou are right. We filter and refetch only the ones we do not\nhave, so we are Ok.\n\nSorry for the noise.\n"},{"id":"34185","messageId":"Pine.LNX.4.64.0702111124410.8424@woody.linux-foundation.org","threadId":"6738","inReplyTo":"7vire8ec6w.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-11T19:25:15Z","receivedAt":"2007-02-11T19:25:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Feb 2007, Junio C Hamano wrote:\n> \n> Well, what you are saying is that it used to be Ok in Jul 5 2005\n> version but with tag following it is not Ok anymore, isn't it?\n\nDo we actually do it with automatic tag following? I tested, and it didn't \ndo anything bad for me.\n\n\t\tLinus\n"},{"id":"34187","messageId":"7v3b5ce5j0.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702111124410.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T21:41:23Z","receivedAt":"2007-02-11T21:41:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 11 Feb 2007, Junio C Hamano wrote:\n>> \n>> Well, what you are saying is that it used to be Ok in Jul 5 2005\n>> version but with tag following it is not Ok anymore, isn't it?\n>\n> Do we actually do it with automatic tag following? I tested, and it didn't \n> do anything bad for me.\n\nYou are right.\n\nThe only iffy case that is remaining is \"git fetch --tags $URL\".\nThe user is explicitly saying \"I want all tags from there\", but\nthe user may not be expecting tags that are already present in\nthe local repository to be overwritten.\n\nThe filtering on the auto-follow codepath Johannes added with\n\"git-show-ref --exclude-existing\" would fix this case as well.\n\n-- >8 --\n[PATCH] \"git-fetch --tags $URL\" should not overwrite existing tags\n\nUse the same --exclude-existing filter as we use for automatic\ntag following to avoid overwriting existing tags with replacement\nones the other side created.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 357cac2..ca984e7 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -253,23 +253,10 @@ if test \"$tags\"\n then\n \ttaglist=`IFS='\t' &&\n \t\t echo \"$ls_remote_result\" |\n+\t\t git-show-ref --exclude-existing=refs/tags/ |\n \t while read sha1 name\n \t\t do\n-\t\t\tcase \"$sha1\" in\n-\t\t\tfail)\n-\t\t\t\texit 1\n-\t\t\tesac\n-\t\t\tcase \"$name\" in\n-\t\t\t*^*) continue ;;\n-\t\t\trefs/tags/*) ;;\n-\t\t\t*) continue ;;\n-\t\t\tesac\n-\t\t \tif git-check-ref-format \"$name\"\n-\t\t\tthen\n-\t\t\t echo \".${name}:${name}\"\n-\t\t\telse\n-\t\t\t echo >&2 \"warning: tag ${name} ignored\"\n-\t\t\tfi\n+\t\t\techo \".${name}:${name}\"\n \t\t done` || exit\n \tif test \"$#\" -gt 1\n \tthen\n"},{"id":"34192","messageId":"7vfy9ccqaa.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702101347350.8424@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T21:55:57Z","receivedAt":"2007-02-11T21:55:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 10 Feb 2007, Jakub Narebski wrote:\n>> \n>> One of the solutions, used in git.git repository, is to put public key\n>> as a out-of-tree blob using git-hash-object, then tag it using singed tag\n>> with instruction about how to extract key in the tag message (tag comment).\n>\n> No. That's horrible. Yes, it's what Junio did, but if you don't trust the \n> archive, the _last_ thing you should do is to depend on a blob in the \n> archive itself to contain the thing to make you trust it more.\n\nTrue. I should have made it clear it was purely a convenient\nway for people to get the public key and verifying that key\nneeds to be done on a separate channel. Otherwise it would have\nconfused people (exactly like Jakub was confused).\n"},{"id":"34226","messageId":"200702120140.28782.jnareb@gmail.com","threadId":"6738","inReplyTo":"7vfy9ccqaa.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-12T00:40:27Z","receivedAt":"2007-02-12T00:40:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n>> On Sat, 10 Feb 2007, Jakub Narebski wrote:\n>>> \n>>> One of the solutions, used in git.git repository, is to put public key\n>>> as a out-of-tree blob using git-hash-object, then tag it using singed tag\n>>> with instruction about how to extract key in the tag message (tag comment).\n>>\n>> No. That's horrible. Yes, it's what Junio did, but if you don't trust the \n>> archive, the _last_ thing you should do is to depend on a blob in the \n>> archive itself to contain the thing to make you trust it more.\n> \n> True. I should have made it clear it was purely a convenient\n> way for people to get the public key and verifying that key\n> needs to be done on a separate channel. Otherwise it would have\n> confused people (exactly like Jakub was confused).\n\nGaah, perhaps I wasn't clear: I mentioned this as a method to _transfer_\nthe actual data for public key (I thought the question was about that).\nNot that one should place any trust because tags are signed by in-repo\nkey...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"34291","messageId":"20070212162745.GB2741@thunk.org","threadId":"6738","inReplyTo":"7vy7n5gs0y.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-12T16:27:45Z","receivedAt":"2007-02-12T16:27:45Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:\n> Although it is correct that the people who already saw the\n> original tag would not lose the tag object from their repository\n> when you publish a replacement tag, we have _always_ overwritten\n> the refs/tags/$tag to point at the new one, effectively losing\n> the original.\n\nSo I have a suspicion that I have multiple tag objects with the same\ntag name (E2FSPROGS-1_26), from doing an hg conversion. Is there an\neasy way to search all of the tag objects in my git repository to see\nif this is the case, so I can delete them lest they cause any\nconfusion/problems?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"34380","messageId":"7vr6su1szp.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"20070212162745.GB2741@thunk.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-13T06:17:30Z","receivedAt":"2007-02-13T06:17:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:\n>> Although it is correct that the people who already saw the\n>> original tag would not lose the tag object from their repository\n>> when you publish a replacement tag, we have _always_ overwritten\n>> the refs/tags/$tag to point at the new one, effectively losing\n>> the original.\n>\n> So I have a suspicion that I have multiple tag objects with the same\n> tag name (E2FSPROGS-1_26), from doing an hg conversion. Is there an\n> easy way to search all of the tag objects in my git repository to see\n> if this is the case, so I can delete them lest they cause any\n> confusion/problems?\n\n\"fsck --full\" should report \"dangling tag\".\n"},{"id":"34502","messageId":"Pine.LNX.4.64.0702132230490.3604@woody.linux-foundation.org","threadId":"6738","inReplyTo":"7vr6su1szp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T06:38:37Z","receivedAt":"2007-02-14T06:38:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Feb 2007, Junio C Hamano wrote:\n> \n> \"fsck --full\" should report \"dangling tag\".\n\nWell, except if\n - you've pruned\n - the importer never imported anything but the most recent one.\n\nOne thing that _might_ be a good idea for tags (if people _really_ want to \nactually update tags under the same name) is to have a \"parent\" pointer \nfor tag objects, the same way we have for commits. That way you could - if \nyou really wanted to - create a chain of tags, and show the history of \nthem.\n\nNow, I personally think you'd be better off just having separate names, \nbut for something like a \"passed testing\" tag, it might be valid to (a) \nhave the last one and (b) have a history chain. And it's not like it would \nbe technically \"hard\" to do.\n\nI dunno. Personally I'd rather try to just tell people to not re-use \ntag-names, because it kind of destroys the whole point of a tag (\"I \nchecked out tag X!\" just leadsto \"_Which_ X?\").\n\nAnd you could certainly do the \"passed testing\" thing with commits in a \nseparate branch instead: you'd create the \"testing\" branch, which is \nalways a set of commits that have as their primary parent the commit that \ngot tested, and as the second parent the previous commit in the \"testing\" \nseries).\n\nSo _generally_ I think we're better off keeping things the way they are, \nbut on the other hand, if only to work well with idiotic systems that \nmis-use tags in ways that tags shouldn't be used, we *could* just extend \non what tyou can do with a git tag too..\n\n\t\tLinus\n"},{"id":"34503","messageId":"7vfy99td98.fsf@assigned-by-dhcp.cox.net","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702132230490.3604@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T07:22:11Z","receivedAt":"2007-02-14T07:22:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 12 Feb 2007, Junio C Hamano wrote:\n>> \n>> \"fsck --full\" should report \"dangling tag\".\n>\n> Well, except if\n> - you've pruned\n> - the importer never imported anything but the most recent one.\n\nTrue -- but Ted was talking about look for them in order to\neradicate them, so if you've pruned or never had one, you are\nOk.\n\n> One thing that _might_ be a good idea for tags (if people _really_ want to \n> actually update tags under the same name) is to have a \"parent\" pointer \n> for tag objects, the same way we have for commits. That way you could - if \n> you really wanted to - create a chain of tags, and show the history of \n> them.\n> ...\n> I dunno. Personally I'd rather try to just tell people to not re-use \n> tag-names, because it kind of destroys the whole point of a tag (\"I \n> checked out tag X!\" just leadsto \"_Which_ X?\").\n\nI agree.\n\n> And you could certainly do the \"passed testing\" thing with commits in a \n> separate branch instead: you'd create the \"testing\" branch, which is \n> always a set of commits that have as their primary parent the commit that \n> got tested, and as the second parent the previous commit in the \"testing\" \n> series).\n\nI personally feel that that kind of commit is misusing the\nparent field (for one thing, it would not play well with merges\nat all, although people who abuse commits to record non-ancestry\nstructure may not even be interested in merging such things so\nit may not be a problem in practice). If people want to express\nrelationship between commits (and other objects in general)\nother than ancestry, I think it would be cleaner to allow a tag\nto have more than one pointers to other objects.\n\nI know you are against arbitrary pointers inside objects that\ndoes not have semantic meaning, and I agree. Probably your\n\"previous version of this tag was that one\" is better than \"more\nthan one arbitrary pointers\" in that sense.\n\nBut I do not know how useful a linear history of tags are; it is\nsemantically the same as v1.5.0, v1.5.0.1, v1.5.0.2, ... sequence.\n"},{"id":"34515","messageId":"Pine.LNX.4.63.0702141213150.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6738","inReplyTo":"7vfy99td98.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-pull and tag objects","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-14T11:18:25Z","receivedAt":"2007-02-14T11:18:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Feb 2007, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > And you could certainly do the \"passed testing\" thing with commits in \n> > a separate branch instead: you'd create the \"testing\" branch, which is \n> > always a set of commits that have as their primary parent the commit \n> > that got tested, and as the second parent the previous commit in the \n> > \"testing\" series).\n> \n> I personally feel that that kind of commit is misusing the parent field \n> (for one thing, it would not play well with merges at all, although \n> people who abuse commits to record non-ancestry structure may not even \n> be interested in merging such things so it may not be a problem in \n> practice).\n\nI don't think it is misusing the parent field, but I would make the \nprimary parent the ancestor in terms of testing. In a very real sense, \nthis maps the history -- not of development, but of testing. It also makes \nsense to bisect on this line of history.\n\nThe chance of a mismerge is somewhat real, though. At first I thought that \nyou'd need a special script anyway, until I realized that it's just a \nmatter of \"git merge -s theirs \".\n\nCiao,\nDscho\n"},{"id":"34554","messageId":"Pine.LNX.4.64.0702140831160.3604@woody.linux-foundation.org","threadId":"6738","inReplyTo":"Pine.LNX.4.63.0702141213150.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-pull and tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T16:35:21Z","receivedAt":"2007-02-14T16:35:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Johannes Schindelin wrote:\n> \n> The chance of a mismerge is somewhat real, though. At first I thought that \n> you'd need a special script anyway, until I realized that it's just a \n> matter of \"git merge -s theirs \".\n\nIn fact, it's even quite doable as\n\n\tgit commit-tree theirs^{tree} -p HEAD -p theirs < changelog\n\n(choose your parent order at will) so it's not as if it's much of a \n\"script\". It's a core command to do something like this.\n\nUsing \"git commit -s theirs\" might not work (shouldn't, but I didn't test) \nfor the first entry, so you probably *do* want to script this regardless. \nBut git makes it really really easy.\n\n\t\tLinus\n"},{"id":"34663","messageId":"er0cfg$1m7$1@sea.gmane.org","threadId":"6738","inReplyTo":"Pine.LNX.4.64.0702132230490.3604@woody.linux-foundation.org","subject":"Re: git-pull and tag objects","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-15T01:21:36Z","receivedAt":"2007-02-15T01:21:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> One thing that _might_ be a good idea for tags (if people _really_ want to \n> actually update tags under the same name) is to have a \"parent\" pointer \n> for tag objects, the same way we have for commits. That way you could - if \n> you really wanted to - create a chain of tags, and show the history of \n> them.\n\nWouldn't it be better to just use reflog for given tag? That assuming of\ncourse that we could protect tag reflog from pruning...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"34665","messageId":"Pine.LNX.4.63.0702150232340.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6738","inReplyTo":"er0cfg$1m7$1@sea.gmane.org","subject":"Re: git-pull and tag objects","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T01:34:08Z","receivedAt":"2007-02-15T01:34:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[*SIGH* I am Cc'ing Linus, since you -- again -- forgot that]\n\nOn Thu, 15 Feb 2007, Jakub Narebski wrote:\n\n> Linus Torvalds wrote:\n> \n> > One thing that _might_ be a good idea for tags (if people _really_ \n> > want to actually update tags under the same name) is to have a \n> > \"parent\" pointer for tag objects, the same way we have for commits. \n> > That way you could - if you really wanted to - create a chain of tags, \n> > and show the history of them.\n> \n> Wouldn't it be better to just use reflog for given tag? That assuming of \n> course that we could protect tag reflog from pruning...\n\nNo. Reflogs are a local thing, tags not necessarily. And much fun \n\"pushing\" a reflog to another repo.\n\nCiao,\nDscho\n"}]}