* git-pull and tag objects @ 2007-02-08 11:16 Alex Bennee 2007-02-09 9:33 ` Alex Riesen 0 siblings, 1 reply; 26+ messages in thread From: Alex Bennee @ 2007-02-08 11:16 UTC (permalink / raw) To: git Hi, I have a master repositary which I keep in sync with a CVS server. Each time it imports a new baseline it tags it with the baseline tag we use. This allows for easy branching of "baseline" levels. I have slave repositaries which are cloned of the baseline which I do my development in. However when I bring the master branch of these work repositaries upto date (via git-pull ../baseline master) I find the tag objects are lost. Should they not be part of the tree? After all when I sync to Linus's kernel repo I get all his version tags as part of that. -- Alex, homepage: http://www.bennee.com/~alex/ "Spare no expense to save money on this one." -- Samuel Goldwyn ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-08 11:16 git-pull and tag objects Alex Bennee @ 2007-02-09 9:33 ` Alex Riesen 2007-02-09 23:19 ` Junio C Hamano 0 siblings, 1 reply; 26+ messages in thread From: Alex Riesen @ 2007-02-09 9:33 UTC (permalink / raw) To: Alex Bennee; +Cc: git On 2/8/07, Alex Bennee <kernel-hacker@bennee.com> wrote: > I have slave repositaries which are cloned of the baseline which I do my > development in. However when I bring the master branch of these work > repositaries upto date (via git-pull ../baseline master) I find the tag > objects are lost. Should they not be part of the tree? After all when I > sync to Linus's kernel repo I get all his version tags as part of that. You have to use "git pull ../baseline master:somewhere". This "master:somewhere" expression makes git fetch and stores the tags along with the branch' commits. Better yet, create an entry in remotes: .git/remotes or .git/config, depending on the version of git you have. The current master on kernel.org has the support for latter (branches in .git/config), which will also be in the upcoming release 1.5. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-09 9:33 ` Alex Riesen @ 2007-02-09 23:19 ` Junio C Hamano 2007-02-10 0:14 ` [PATCH] git-fetch: document automatic tag following Junio C Hamano 2007-02-10 14:23 ` git-pull and tag objects Theodore Tso 0 siblings, 2 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-09 23:19 UTC (permalink / raw) To: Alex Riesen; +Cc: Alex Bennee, git "Alex Riesen" <raa.lkml@gmail.com> writes: > You have to use "git pull ../baseline master:somewhere". > This "master:somewhere" expression makes git fetch and stores > the tags along with the branch' commits. Better yet, create an > entry in remotes: .git/remotes or .git/config, depending on the version > of git you have. The current master on kernel.org has the support > for latter (branches in .git/config), which will also be in the upcoming > release 1.5. While this is technically correct, the automatic tag following performed by git-fetch (git-pull invokes git-fetch internally and it is done as the side effect) probably needs a bit more detailed explanation. Automatic tag following is done by first fetching from the remote using the given <refspec>s, and if the repository has objects that are pointed by remote tags that it does not yet have, then fetch those missing tags. If the other end has tags that point at branches you are not interested in, you will not get them. There are currently two ways for you to get tags and one and half ways to decline. * "git fetch --tags URL <refspec>..." will download all tags. This has nothing to do with the automatic following. * "git fetch URL <refspec>..." (including the case where <refspec>s are taken from the configuration files) will trigger automatic tag following only when <refspec>s store the fetch result in tracking branches (this is what raa pointed out) * "git fetch --no-tags URL <refspec>..." forbids automatic tag following, even when <refspec>s are the tracking kind. The other half way to decline that is implicit in the above is to use <refspec>s that do not store the result in tracking branches. Now, the --no-tags option means "Do not automatically follow tags". But the --tags option does not mean the opposite. It means "Do fetch _all_ tags". We do not have an explicit option that says "Do follow tags". It is implicitly decided based on the kind of <refspec>. This is not a problem in practice and is a good heuristics that does the right thing for both people near the toplevel and people who only follow others trees. If you are following somebody else's tree, you are most likely using tracking branches (refs/heads/origin in traditional layout, or refs/remotes/origin/master in the separate-remote layout). You usually want the tags from the other end. On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there. This happens more often for people near the toplevel but not limited to them. Mere mortals when pulling from each other do not necessarily want to automatically get private 'anchor point' tags from the other person. You would notice "please pull" messages on the mailing list says repo URL and branch name alone. This is designed to be easily cut&pasted to "git fetch" command line: Linus, please pull from git://git..../proj.git master to get the following updates... becomes: $ git pull git://git..../proj.git master In such a case, you do not want to automatically follow other's tags. One important aspect of git is it is distributed, and being distributed largely means there is no inherent "upstream" or "downstream" in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned by upper echelon of people and tags only flow downwards, but that is not the case. It only shows that the usage pattern determines who are interested in whose tags. A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. "people who are primarily interested in networking part of the kernel") who may have their own set of tags (e.g. "this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release") to another circle of people (e.g. "people who integrate various subsystem improvements"). The latter are usually not interested in the detailed tags used internally in the former group (that is what "internal" means). That is why it is desirable not to follow tags automatically in this case. It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking with each other's progress by having tracking branches. Again, the existing heuristic would automatically follow such tags and that is a good thing. Although I do not think it is necessary for the above reasons, if somebody wanted to do it, it is easy and straightforward to make the automated tag following more orthogonal by letting you pass --do-follow-tags to "git fetch" to explicitly tell it to follow tags even when you are not tracking the other side. -- diff --git a/git-fetch.sh b/git-fetch.sh index 357cac2..aef2159 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -17,6 +17,7 @@ IFS="$LF" no_tags= tags= +follow_tags= append= force= verbose= @@ -46,6 +47,9 @@ do -t|--t|--ta|--tag|--tags) tags=t ;; + --fol|--foll|--follo|--follow) + follow_tags=t + ;; -n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags) no_tags=t ;; @@ -454,12 +458,11 @@ fetch_main () { fetch_main "$reflist" || exit # automated tag following -case "$no_tags$tags" in -'') - case "$reflist" in - *:refs/*) - # effective only when we are following remote branch - # using local tracking branch. +if test -z "$no_tags$tags" && { + test -n "$follow_tags" || + case "$reflist" in *:refs/*) :;; *) false ;; esac + } +then taglist=$(IFS=' ' && echo "$ls_remote_result" | git-show-ref --exclude-existing=refs/tags/ | @@ -469,7 +472,6 @@ case "$no_tags$tags" in echo >&2 "Auto-following $name" echo ".${name}:${name}" done) - esac case "$taglist" in '') ;; ?*) @@ -477,7 +479,7 @@ case "$no_tags$tags" in shallow_depth= fetch_main "$taglist" || exit ;; esac -esac +fi # If the original head was empty (i.e. no "master" yet), or # if we were told not to worry, we do not have to check. ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH] git-fetch: document automatic tag following. 2007-02-09 23:19 ` Junio C Hamano @ 2007-02-10 0:14 ` Junio C Hamano 2007-02-10 14:23 ` git-pull and tag objects Theodore Tso 1 sibling, 0 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-10 0:14 UTC (permalink / raw) To: Alex Riesen; +Cc: Alex Bennee, git I've added this to the documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Documentation/git-fetch.txt | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index 7ecf240..5fbeab7 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -20,6 +20,14 @@ The ref names and their object names of fetched refs are stored in `.git/FETCH_HEAD`. This information is left for a later merge operation done by "git merge". +When <refspec> stores the fetched result in tracking branches, +the tags that point at these branches are automatically +followed. This is done by first fetching from the remote using +the given <refspec>s, and if the repository has objects that are +pointed by remote tags that it does not yet have, then fetch +those missing tags. If the other end has tags that point at +branches you are not interested in, you will not get them. + OPTIONS ------- -- 1.5.0.rc4.16.g9e258 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-09 23:19 ` Junio C Hamano 2007-02-10 0:14 ` [PATCH] git-fetch: document automatic tag following Junio C Hamano @ 2007-02-10 14:23 ` Theodore Tso 2007-02-10 17:56 ` Linus Torvalds 1 sibling, 1 reply; 26+ messages in thread From: Theodore Tso @ 2007-02-10 14:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Alex Riesen, Alex Bennee, git Thanks for this great explanation of how tags work. Hopefully some or all of this can get incorporated into the git's user's manual. Adding the paragraph to the git-tag as you did in your patch is a good start, but having the entire explanation of how things work in the user's manual would be a really good thing, IMHO. This brings up another question which I've been looking for, but for which I haven't found a good answer in the git documentation. A google search shows a suggestion by hpa (and a brief discussion from sct) about how to handle conflicting tags back in 2005, but as far as I can tell it didn't go anywhere. Anyway, the questions that don't appear to be addressed in the git documentations are: 1) Suppose I do a "git tag" of a release, and then realize that I messed up, and I need to do some additional release work (i.e., editing a debian changelog file, etc.) before really doing another release, what do I do to tag a later revision as the "real" version v1.2? 2) Suppose I have v2.6.20 pointing to a particular revision, which was obtained from pulling from Linus's tree, and I pull from some other tree, say the wireless tree, and the maintainer there either accidentally or maliciously has the tag v2.6.20 pointing to some other revision. What happens in that case? Does the answer change if the tag is a signed vs. unsigned tag? 3) The git-tag man page talks about GPG signing tags, but it doesn't talk about how a GPG-signed tag is validated. Does this happen manually or automatically? If it happens manually, how should a tag be verified? If the answer is using git-verify-tag, then there should probably be better references in the documentation to git-verify-tag. It might also be a very good idea to have a config option which automatically verifies signed tags. 4) Is there a good/easy way to show whether a tag is a signed vs. unsigned tag? Short of using "git cat-file -t <tag>", there doesn't seem to be, and being forced to use a low-level git command to get that kind of information seems.... unsatisfactory. Thanks, - Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 14:23 ` git-pull and tag objects Theodore Tso @ 2007-02-10 17:56 ` Linus Torvalds 2007-02-10 21:32 ` Jakub Narebski ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Linus Torvalds @ 2007-02-10 17:56 UTC (permalink / raw) To: Theodore Tso; +Cc: Junio C Hamano, Alex Riesen, Alex Bennee, git On Sat, 10 Feb 2007, Theodore Tso wrote: > > This brings up another question which I've been looking for, but for > which I haven't found a good answer in the git documentation. A > google search shows a suggestion by hpa (and a brief discussion from > sct) about how to handle conflicting tags back in 2005, but as far as > I can tell it didn't go anywhere. I don't think we've ever had a conflicting tag. > 1) Suppose I do a "git tag" of a release, and then realize that I > messed up, and I need to do some additional release work (i.e., > editing a debian changelog file, etc.) before really doing another > release, what do I do to tag a later revision as the "real" version > v1.2? Well, if you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done. But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things: - The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have _different_ "X"'s. So just call it "X.1" and be done with it. - The insane thing. You really want to call the new version "X" too, _even_though_ others have already seen the old one. So just use "git tag -f" again, as if you hadn't already published the old one. HOWEVER! Git does *not* (and in my very very strong opinion, MUST NOT!) change tags behind users back. So if somebody already got the old tag, doing a "git pull" on your tree shouldn't just make them overwrite the old one. And I really think that git does the right thing. If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. I think this is a BIG security issue, in that people MUST be able to trust their tag-names. If I got a particular tag, NO WAY IN HELL must git just replace it for me because you happened to have a newer one! So if you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying "Ok, I messed up, and I pushed out an earlier version tagged as X. I then fixed somethign, and retagged the *fixed* tree as X again. If you got the wrong tag, and want the new one, you'll have to delete the old one and fetch the new one: git tag -d X git fetch origin X to get my updated tag. You can test which tag you have by doing git rev-parse X which should return 0123456789abcdef.. if you have the new version". Does this seem a bit complicated? HELL YES. But it *should* be. There is no way in hell that it would be correct to just "fix" it behind peoples backs. People need to know that their tags might have been changed. > 3) The git-tag man page talks about GPG signing tags, but it doesn't > talk about how a GPG-signed tag is validated. Does this happen > manually or automatically? Use "git verify-tag X" to see something like this: [torvalds@woody linux]$ git-verify-tag v2.6.17 gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>" but you obviously need to have the public key in question available to you. We could verify tags automatically, of course, but the question is, what would the policy be? (Side note: the 'monotone' people do the trust thing very deep in monotone, AND IT IS A COMPLETE DISASTER! I'm surprised they are not only continuing with it, they are adding more and more infrastructure exactly because once you do it automatically, you need to be able to handle any possible policy. It's insane. It's also really sad, because monotone gets so many things right. Their security model is just *totally* broken, and makes the whole thing be just a steaming pile of shit. Sad. Not that the whole C++/boost/STL crap exactly "helps" either, but the security thing is probably the more fundamental problem.) Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 17:56 ` Linus Torvalds @ 2007-02-10 21:32 ` Jakub Narebski 2007-02-10 21:58 ` Linus Torvalds 2007-02-11 0:25 ` Theodore Tso 2007-02-11 5:52 ` Junio C Hamano 2 siblings, 1 reply; 26+ messages in thread From: Jakub Narebski @ 2007-02-10 21:32 UTC (permalink / raw) To: git Linus Torvalds wrote: > On Sat, 10 Feb 2007, Theodore Tso wrote: >> 3) The git-tag man page talks about GPG signing tags, but it doesn't >> talk about how a GPG-signed tag is validated. Does this happen >> manually or automatically? > > Use "git verify-tag X" to see something like this: > > [torvalds@woody linux]$ git-verify-tag v2.6.17 > gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB > gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>" > > but you obviously need to have the public key in question available to > you. One of the solutions, used in git.git repository, is to put public key as a out-of-tree blob using git-hash-object, then tag it using singed tag with instruction about how to extract key in the tag message (tag comment). $ git cat-file -p junio-gpg-pub object 0246401b5d117e01717149c413aa2f8702a83d4f type blob tag junio-gpg-pub tagger Junio C Hamano <junkio@cox.net> Tue Dec 13 16:33:29 2005 -0800 GPG key to sign git.git archive. This blob object contains the GPG public key I use to sign git.git archive. To use it to verify tags I signed, do: $ git-cat-file blob junio-gpg-pub | gpg --import to import it into your keyring, and then $ git-verify-tag $tag_to_be_verified -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 21:32 ` Jakub Narebski @ 2007-02-10 21:58 ` Linus Torvalds 2007-02-11 21:55 ` Junio C Hamano 0 siblings, 1 reply; 26+ messages in thread From: Linus Torvalds @ 2007-02-10 21:58 UTC (permalink / raw) To: Jakub Narebski; +Cc: git On Sat, 10 Feb 2007, Jakub Narebski wrote: > > One of the solutions, used in git.git repository, is to put public key > as a out-of-tree blob using git-hash-object, then tag it using singed tag > with instruction about how to extract key in the tag message (tag comment). No. That's horrible. Yes, it's what Junio did, but if you don't trust the archive, the _last_ thing you should do is to depend on a blob in the archive itself to contain the thing to make you trust it more. So you want to get the gpg public key from somewhere else to be able to _independently_ verify that it's ok. Otherwise, somebody could just totally replace the object with one of their own, and then _claim_ that the public key they made is "junio-gpg-pub", and fool people into thinkign it's signed by Junio. So to get a valid chain of trust, you really have to have some sideband channel to get you started. There's a lot of infrastructure for that elsewhere (ie the whole "sign other peoples keys" thing that is so central to pgp), but even if you don't have a key to start with, you're actually better off getting a key (even with no other validation) from an independent source than have it be in the repository itself. Because at least then any attacker has to fake _two_ things, rather than just a single repo. Of course, in *practice* this is not a problem. And, in fact, thanks to git's SHA1 setup, you obviously don't have to really verify the key itself in git, you really only want to verify that yes, the object name is correct (ie if you get some sideband information from Junio that the "object 0246401b5d117e01717149c413aa2f8702a83d4f" really is Junio's key, that's sufficient in itself). (The "sideband channel" can be something as simple as google. For example, if you just google for the SHA1 of the tag itself, you'll actually get a lot of hits for it - a0e7d36193b96f552073558acf5fcc1f10528917 (which is not the key itself, but it is the tag that points to it, which in turn is signed with the key) shows up in manyplaces, and that very fact in itself is "interesting" as a sideband information. It's not "proof", but it's certainly one piece of information that may make you more comfortable with that tag not being something recent and fake - it's been around and been quoted by me in email archives, so if it's faked, it's fooled a number of people). Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 21:58 ` Linus Torvalds @ 2007-02-11 21:55 ` Junio C Hamano 2007-02-12 0:40 ` Jakub Narebski 0 siblings, 1 reply; 26+ messages in thread From: Junio C Hamano @ 2007-02-11 21:55 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jakub Narebski, git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Sat, 10 Feb 2007, Jakub Narebski wrote: >> >> One of the solutions, used in git.git repository, is to put public key >> as a out-of-tree blob using git-hash-object, then tag it using singed tag >> with instruction about how to extract key in the tag message (tag comment). > > No. That's horrible. Yes, it's what Junio did, but if you don't trust the > archive, the _last_ thing you should do is to depend on a blob in the > archive itself to contain the thing to make you trust it more. True. I should have made it clear it was purely a convenient way for people to get the public key and verifying that key needs to be done on a separate channel. Otherwise it would have confused people (exactly like Jakub was confused). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 21:55 ` Junio C Hamano @ 2007-02-12 0:40 ` Jakub Narebski 0 siblings, 0 replies; 26+ messages in thread From: Jakub Narebski @ 2007-02-12 0:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: Linus Torvalds, git Junio C Hamano wrote: > Linus Torvalds <torvalds@linux-foundation.org> writes: >> On Sat, 10 Feb 2007, Jakub Narebski wrote: >>> >>> One of the solutions, used in git.git repository, is to put public key >>> as a out-of-tree blob using git-hash-object, then tag it using singed tag >>> with instruction about how to extract key in the tag message (tag comment). >> >> No. That's horrible. Yes, it's what Junio did, but if you don't trust the >> archive, the _last_ thing you should do is to depend on a blob in the >> archive itself to contain the thing to make you trust it more. > > True. I should have made it clear it was purely a convenient > way for people to get the public key and verifying that key > needs to be done on a separate channel. Otherwise it would have > confused people (exactly like Jakub was confused). Gaah, perhaps I wasn't clear: I mentioned this as a method to _transfer_ the actual data for public key (I thought the question was about that). Not that one should place any trust because tags are signed by in-repo key... -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 17:56 ` Linus Torvalds 2007-02-10 21:32 ` Jakub Narebski @ 2007-02-11 0:25 ` Theodore Tso 2007-02-11 3:21 ` Linus Torvalds 2007-02-11 5:52 ` Junio C Hamano 2 siblings, 1 reply; 26+ messages in thread From: Theodore Tso @ 2007-02-11 0:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Junio C Hamano, Alex Riesen, Alex Bennee, git On Sat, Feb 10, 2007 at 09:56:25AM -0800, Linus Torvalds wrote: > We could verify tags automatically, of course, but the question is, what > would the policy be? What I would propose (post-1.5.0!) is that the policy file be local to the repository, and consist of an ordered list of regular expressions and and lists of PGP keys associated with each regexp. So for example, I might have in my repository a config file which states that any tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be signed by PGP key 0x76E21CBB (Linus's key). What I would very much like is for the tags to be automatically verified whenever I do a git-fetch operation, and for me to get a big, fat, warning if some tag isn't signed by an authoried key. So this would help make sure that when I'm pulling from kernel.org, I'm getting something that originally came from Linus, and someone hasn't managed to insert trojan into the git tree, but it doesn't help in between releases. In order to solve that problem we would have to have some kind of scheme where branch heads could be optionally signed, and then transfered over to the public repository. Then, in the git config file, we could list an expected set of keys that should sign any branch head for a particular tracking branch. Since all of this is local policy, someone who wanted to have a different set of trusted peers, they could do so. And, of course, someone who wanted to run completely open with no gpg signature checking at all could do so. (aka "rms/rms mode" :-) Does this make sense? - Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 0:25 ` Theodore Tso @ 2007-02-11 3:21 ` Linus Torvalds 0 siblings, 0 replies; 26+ messages in thread From: Linus Torvalds @ 2007-02-11 3:21 UTC (permalink / raw) To: Theodore Tso; +Cc: Junio C Hamano, Alex Riesen, Alex Bennee, git On Sat, 10 Feb 2007, Theodore Tso wrote: > > What I would propose (post-1.5.0!) is that the policy file be local to > the repository, and consist of an ordered list of regular expressions > and and lists of PGP keys associated with each regexp. So for > example, I might have in my repository a config file which states that > any tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be > signed by PGP key 0x76E21CBB (Linus's key). Actually, I think you can do it already. I think the "update" hook runs whenever we're pulling a ref, once for each ref. It might happen just for pushing to a remote, though. Anyway, with a hook, it's easy enough to just add exactly the kind of thing you are outlining, and yes, it would be repository-local. Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-10 17:56 ` Linus Torvalds 2007-02-10 21:32 ` Jakub Narebski 2007-02-11 0:25 ` Theodore Tso @ 2007-02-11 5:52 ` Junio C Hamano 2007-02-11 17:49 ` Linus Torvalds 2007-02-12 16:27 ` Theodore Tso 2 siblings, 2 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-11 5:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git Linus Torvalds <torvalds@linux-foundation.org> writes: > But if you have pushed things out (or others could just read your > repository directly), then others will have already seen the old tag. In > that case you can do one of two things: > ... > - The insane thing. > > You really want to call the new version "X" too, _even_though_ others > have already seen the old one. So just use "git tag -f" again, as if > you hadn't already published the old one. > > HOWEVER! > > Git does *not* (and in my very very strong opinion, MUST NOT!) change > tags behind users back. So if somebody already got the old tag, doing a > "git pull" on your tree shouldn't just make them overwrite the old one. > > And I really think that git does the right thing. If somebody got a > release tag from you, you cannot just change the tag for them by updating > your own one. I think this is a BIG security issue, in that people MUST be > able to trust their tag-names. If I got a particular tag, NO WAY IN HELL > must git just replace it for me because you happened to have a newer one! > > So if you really want to do the insane thing, you need to just fess up to > it, and tell people that you messed up. Confession time. Although it is correct that the people who already saw the original tag would not lose the tag object from their repository when you publish a replacement tag, we have _always_ overwritten the refs/tags/$tag to point at the new one, effectively losing the original. * 0a623e7c (Jul 5, 2005) In this version "git fetch $repo tag v2.6.13" would have done just echo "$head" >"$GIT_DIR/$destination" without checking if it already existed. * ae2da406 (Aug 22, 2005) We started checking if the fetched/followed tag already existed with this version. However, the result of the check was only used to say "$tagname: updating with $new_sha1 from $old_sha1" in the status message. And after numerous code reorganizations of git-fetch throughout its life, this logic has never been touched. This comment around ll. 170 we currently have: case "$1" in refs/tags/*) # Tags need not be pointing at commits so there # is no way to guarantee "fast-forward" anyway. was introduced with 853a3697 (Aug 20, 2005) and stayed there ever since. I think it is worth fixing this by tightening the rule as you described, even with this late in the game for 1.5.0. The user either needs to force it, or remove it beforehand. diff --git a/git-fetch.sh b/git-fetch.sh index 357cac2..1078016 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -169,14 +169,18 @@ update_local_ref () { case "$1" in refs/tags/*) - # Tags need not be pointing at commits so there - # is no way to guarantee "fast-forward" anyway. + # Tags should never be blindly overwritten without user's + # consent. if test -n "$oldshort_" then if now_=$(git show-ref --hash "$1") && test "$now_" = "$2" then [ "$verbose" ] && echo >&2 "* $1: same as $3" [ "$verbose" ] && echo >&2 " $label_: $newshort_" ||: + elif test -z "$force$single_force" + then + echo >&2 "* $1: refusing to update with $3" + false else echo >&2 "* $1: updating with $3" echo >&2 " $label_: $newshort_" ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 5:52 ` Junio C Hamano @ 2007-02-11 17:49 ` Linus Torvalds 2007-02-11 19:17 ` Junio C Hamano 2007-02-12 16:27 ` Theodore Tso 1 sibling, 1 reply; 26+ messages in thread From: Linus Torvalds @ 2007-02-11 17:49 UTC (permalink / raw) To: Junio C Hamano; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git On Sat, 10 Feb 2007, Junio C Hamano wrote: > > Although it is correct that the people who already saw the > original tag would not lose the tag object from their repository > when you publish a replacement tag, we have _always_ overwritten > the refs/tags/$tag to point at the new one, effectively losing > the original. > > * 0a623e7c (Jul 5, 2005) > In this version "git fetch $repo tag v2.6.13" would have done just > > echo "$head" >"$GIT_DIR/$destination" > > without checking if it already existed. Yes, but only if you actually explicitly asked for it, methinks. If you just do a "git pull", it won't do it. So I think it's ok. Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 17:49 ` Linus Torvalds @ 2007-02-11 19:17 ` Junio C Hamano 2007-02-11 19:21 ` Junio C Hamano 2007-02-11 19:25 ` Linus Torvalds 0 siblings, 2 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-11 19:17 UTC (permalink / raw) To: Linus Torvalds; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Sat, 10 Feb 2007, Junio C Hamano wrote: >> >> Although it is correct that the people who already saw the >> original tag would not lose the tag object from their repository >> when you publish a replacement tag, we have _always_ overwritten >> the refs/tags/$tag to point at the new one, effectively losing >> the original. >> >> * 0a623e7c (Jul 5, 2005) >> In this version "git fetch $repo tag v2.6.13" would have done just >> >> echo "$head" >"$GIT_DIR/$destination" >> >> without checking if it already existed. > > Yes, but only if you actually explicitly asked for it, methinks. > > If you just do a "git pull", it won't do it. > > So I think it's ok. Well, what you are saying is that it used to be Ok in Jul 5 2005 version but with tag following it is not Ok anymore, isn't it? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 19:17 ` Junio C Hamano @ 2007-02-11 19:21 ` Junio C Hamano 2007-02-11 19:25 ` Linus Torvalds 1 sibling, 0 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-11 19:21 UTC (permalink / raw) To: Linus Torvalds; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git Junio C Hamano <junkio@cox.net> writes: > Linus Torvalds <torvalds@linux-foundation.org> writes: > >> So I think it's ok. > > Well, what you are saying is that it used to be Ok in Jul 5 2005 > version but with tag following it is not Ok anymore, isn't it? Oops. I misread my own code. You are right. We filter and refetch only the ones we do not have, so we are Ok. Sorry for the noise. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 19:17 ` Junio C Hamano 2007-02-11 19:21 ` Junio C Hamano @ 2007-02-11 19:25 ` Linus Torvalds 2007-02-11 21:41 ` Junio C Hamano 1 sibling, 1 reply; 26+ messages in thread From: Linus Torvalds @ 2007-02-11 19:25 UTC (permalink / raw) To: Junio C Hamano; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git On Sun, 11 Feb 2007, Junio C Hamano wrote: > > Well, what you are saying is that it used to be Ok in Jul 5 2005 > version but with tag following it is not Ok anymore, isn't it? Do we actually do it with automatic tag following? I tested, and it didn't do anything bad for me. Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 19:25 ` Linus Torvalds @ 2007-02-11 21:41 ` Junio C Hamano 0 siblings, 0 replies; 26+ messages in thread From: Junio C Hamano @ 2007-02-11 21:41 UTC (permalink / raw) To: Linus Torvalds; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Sun, 11 Feb 2007, Junio C Hamano wrote: >> >> Well, what you are saying is that it used to be Ok in Jul 5 2005 >> version but with tag following it is not Ok anymore, isn't it? > > Do we actually do it with automatic tag following? I tested, and it didn't > do anything bad for me. You are right. The only iffy case that is remaining is "git fetch --tags $URL". The user is explicitly saying "I want all tags from there", but the user may not be expecting tags that are already present in the local repository to be overwritten. The filtering on the auto-follow codepath Johannes added with "git-show-ref --exclude-existing" would fix this case as well. -- >8 -- [PATCH] "git-fetch --tags $URL" should not overwrite existing tags Use the same --exclude-existing filter as we use for automatic tag following to avoid overwriting existing tags with replacement ones the other side created. Signed-off-by: Junio C Hamano <junkio@cox.net> --- diff --git a/git-fetch.sh b/git-fetch.sh index 357cac2..ca984e7 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -253,23 +253,10 @@ if test "$tags" then taglist=`IFS=' ' && echo "$ls_remote_result" | + git-show-ref --exclude-existing=refs/tags/ | while read sha1 name do - case "$sha1" in - fail) - exit 1 - esac - case "$name" in - *^*) continue ;; - refs/tags/*) ;; - *) continue ;; - esac - if git-check-ref-format "$name" - then - echo ".${name}:${name}" - else - echo >&2 "warning: tag ${name} ignored" - fi + echo ".${name}:${name}" done` || exit if test "$#" -gt 1 then ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-11 5:52 ` Junio C Hamano 2007-02-11 17:49 ` Linus Torvalds @ 2007-02-12 16:27 ` Theodore Tso 2007-02-13 6:17 ` Junio C Hamano 1 sibling, 1 reply; 26+ messages in thread From: Theodore Tso @ 2007-02-12 16:27 UTC (permalink / raw) To: Junio C Hamano; +Cc: Linus Torvalds, Alex Riesen, Alex Bennee, git On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote: > Although it is correct that the people who already saw the > original tag would not lose the tag object from their repository > when you publish a replacement tag, we have _always_ overwritten > the refs/tags/$tag to point at the new one, effectively losing > the original. So I have a suspicion that I have multiple tag objects with the same tag name (E2FSPROGS-1_26), from doing an hg conversion. Is there an easy way to search all of the tag objects in my git repository to see if this is the case, so I can delete them lest they cause any confusion/problems? - Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-12 16:27 ` Theodore Tso @ 2007-02-13 6:17 ` Junio C Hamano 2007-02-14 6:38 ` Linus Torvalds 0 siblings, 1 reply; 26+ messages in thread From: Junio C Hamano @ 2007-02-13 6:17 UTC (permalink / raw) To: Theodore Tso; +Cc: Linus Torvalds, Alex Riesen, Alex Bennee, git Theodore Tso <tytso@mit.edu> writes: > On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote: >> Although it is correct that the people who already saw the >> original tag would not lose the tag object from their repository >> when you publish a replacement tag, we have _always_ overwritten >> the refs/tags/$tag to point at the new one, effectively losing >> the original. > > So I have a suspicion that I have multiple tag objects with the same > tag name (E2FSPROGS-1_26), from doing an hg conversion. Is there an > easy way to search all of the tag objects in my git repository to see > if this is the case, so I can delete them lest they cause any > confusion/problems? "fsck --full" should report "dangling tag". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-13 6:17 ` Junio C Hamano @ 2007-02-14 6:38 ` Linus Torvalds 2007-02-14 7:22 ` Junio C Hamano 2007-02-15 1:21 ` Jakub Narebski 0 siblings, 2 replies; 26+ messages in thread From: Linus Torvalds @ 2007-02-14 6:38 UTC (permalink / raw) To: Junio C Hamano; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git On Mon, 12 Feb 2007, Junio C Hamano wrote: > > "fsck --full" should report "dangling tag". Well, except if - you've pruned - the importer never imported anything but the most recent one. One thing that _might_ be a good idea for tags (if people _really_ want to actually update tags under the same name) is to have a "parent" pointer for tag objects, the same way we have for commits. That way you could - if you really wanted to - create a chain of tags, and show the history of them. Now, I personally think you'd be better off just having separate names, but for something like a "passed testing" tag, it might be valid to (a) have the last one and (b) have a history chain. And it's not like it would be technically "hard" to do. I dunno. Personally I'd rather try to just tell people to not re-use tag-names, because it kind of destroys the whole point of a tag ("I checked out tag X!" just leadsto "_Which_ X?"). And you could certainly do the "passed testing" thing with commits in a separate branch instead: you'd create the "testing" branch, which is always a set of commits that have as their primary parent the commit that got tested, and as the second parent the previous commit in the "testing" series). So _generally_ I think we're better off keeping things the way they are, but on the other hand, if only to work well with idiotic systems that mis-use tags in ways that tags shouldn't be used, we *could* just extend on what tyou can do with a git tag too.. Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-14 6:38 ` Linus Torvalds @ 2007-02-14 7:22 ` Junio C Hamano 2007-02-14 11:18 ` Johannes Schindelin 2007-02-15 1:21 ` Jakub Narebski 1 sibling, 1 reply; 26+ messages in thread From: Junio C Hamano @ 2007-02-14 7:22 UTC (permalink / raw) To: Linus Torvalds; +Cc: Theodore Tso, Alex Riesen, Alex Bennee, git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Mon, 12 Feb 2007, Junio C Hamano wrote: >> >> "fsck --full" should report "dangling tag". > > Well, except if > - you've pruned > - the importer never imported anything but the most recent one. True -- but Ted was talking about look for them in order to eradicate them, so if you've pruned or never had one, you are Ok. > One thing that _might_ be a good idea for tags (if people _really_ want to > actually update tags under the same name) is to have a "parent" pointer > for tag objects, the same way we have for commits. That way you could - if > you really wanted to - create a chain of tags, and show the history of > them. > ... > I dunno. Personally I'd rather try to just tell people to not re-use > tag-names, because it kind of destroys the whole point of a tag ("I > checked out tag X!" just leadsto "_Which_ X?"). I agree. > And you could certainly do the "passed testing" thing with commits in a > separate branch instead: you'd create the "testing" branch, which is > always a set of commits that have as their primary parent the commit that > got tested, and as the second parent the previous commit in the "testing" > series). I personally feel that that kind of commit is misusing the parent field (for one thing, it would not play well with merges at all, although people who abuse commits to record non-ancestry structure may not even be interested in merging such things so it may not be a problem in practice). If people want to express relationship between commits (and other objects in general) other than ancestry, I think it would be cleaner to allow a tag to have more than one pointers to other objects. I know you are against arbitrary pointers inside objects that does not have semantic meaning, and I agree. Probably your "previous version of this tag was that one" is better than "more than one arbitrary pointers" in that sense. But I do not know how useful a linear history of tags are; it is semantically the same as v1.5.0, v1.5.0.1, v1.5.0.2, ... sequence. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-14 7:22 ` Junio C Hamano @ 2007-02-14 11:18 ` Johannes Schindelin 2007-02-14 16:35 ` Linus Torvalds 0 siblings, 1 reply; 26+ messages in thread From: Johannes Schindelin @ 2007-02-14 11:18 UTC (permalink / raw) To: Junio C Hamano Cc: Linus Torvalds, Theodore Tso, Alex Riesen, Alex Bennee, git Hi, On Tue, 13 Feb 2007, Junio C Hamano wrote: > Linus Torvalds <torvalds@linux-foundation.org> writes: > > > And you could certainly do the "passed testing" thing with commits in > > a separate branch instead: you'd create the "testing" branch, which is > > always a set of commits that have as their primary parent the commit > > that got tested, and as the second parent the previous commit in the > > "testing" series). > > I personally feel that that kind of commit is misusing the parent field > (for one thing, it would not play well with merges at all, although > people who abuse commits to record non-ancestry structure may not even > be interested in merging such things so it may not be a problem in > practice). I don't think it is misusing the parent field, but I would make the primary parent the ancestor in terms of testing. In a very real sense, this maps the history -- not of development, but of testing. It also makes sense to bisect on this line of history. The chance of a mismerge is somewhat real, though. At first I thought that you'd need a special script anyway, until I realized that it's just a matter of "git merge -s theirs <from-devel>". Ciao, Dscho ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-14 11:18 ` Johannes Schindelin @ 2007-02-14 16:35 ` Linus Torvalds 0 siblings, 0 replies; 26+ messages in thread From: Linus Torvalds @ 2007-02-14 16:35 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Theodore Tso, Alex Riesen, Alex Bennee, git On Wed, 14 Feb 2007, Johannes Schindelin wrote: > > The chance of a mismerge is somewhat real, though. At first I thought that > you'd need a special script anyway, until I realized that it's just a > matter of "git merge -s theirs <from-devel>". In fact, it's even quite doable as git commit-tree theirs^{tree} -p HEAD -p theirs < changelog (choose your parent order at will) so it's not as if it's much of a "script". It's a core command to do something like this. Using "git commit -s theirs" might not work (shouldn't, but I didn't test) for the first entry, so you probably *do* want to script this regardless. But git makes it really really easy. Linus ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-14 6:38 ` Linus Torvalds 2007-02-14 7:22 ` Junio C Hamano @ 2007-02-15 1:21 ` Jakub Narebski 2007-02-15 1:34 ` Johannes Schindelin 1 sibling, 1 reply; 26+ messages in thread From: Jakub Narebski @ 2007-02-15 1:21 UTC (permalink / raw) To: git Linus Torvalds wrote: > One thing that _might_ be a good idea for tags (if people _really_ want to > actually update tags under the same name) is to have a "parent" pointer > for tag objects, the same way we have for commits. That way you could - if > you really wanted to - create a chain of tags, and show the history of > them. Wouldn't it be better to just use reflog for given tag? That assuming of course that we could protect tag reflog from pruning... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-pull and tag objects 2007-02-15 1:21 ` Jakub Narebski @ 2007-02-15 1:34 ` Johannes Schindelin 0 siblings, 0 replies; 26+ messages in thread From: Johannes Schindelin @ 2007-02-15 1:34 UTC (permalink / raw) To: Jakub Narebski; +Cc: git, Linus Torvalds Hi, [*SIGH* I am Cc'ing Linus, since you -- again -- forgot that] On Thu, 15 Feb 2007, Jakub Narebski wrote: > Linus Torvalds wrote: > > > One thing that _might_ be a good idea for tags (if people _really_ > > want to actually update tags under the same name) is to have a > > "parent" pointer for tag objects, the same way we have for commits. > > That way you could - if you really wanted to - create a chain of tags, > > and show the history of them. > > Wouldn't it be better to just use reflog for given tag? That assuming of > course that we could protect tag reflog from pruning... No. Reflogs are a local thing, tags not necessarily. And much fun "pushing" a reflog to another repo. Ciao, Dscho ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2007-02-15 1:34 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-08 11:16 git-pull and tag objects Alex Bennee 2007-02-09 9:33 ` Alex Riesen 2007-02-09 23:19 ` Junio C Hamano 2007-02-10 0:14 ` [PATCH] git-fetch: document automatic tag following Junio C Hamano 2007-02-10 14:23 ` git-pull and tag objects Theodore Tso 2007-02-10 17:56 ` Linus Torvalds 2007-02-10 21:32 ` Jakub Narebski 2007-02-10 21:58 ` Linus Torvalds 2007-02-11 21:55 ` Junio C Hamano 2007-02-12 0:40 ` Jakub Narebski 2007-02-11 0:25 ` Theodore Tso 2007-02-11 3:21 ` Linus Torvalds 2007-02-11 5:52 ` Junio C Hamano 2007-02-11 17:49 ` Linus Torvalds 2007-02-11 19:17 ` Junio C Hamano 2007-02-11 19:21 ` Junio C Hamano 2007-02-11 19:25 ` Linus Torvalds 2007-02-11 21:41 ` Junio C Hamano 2007-02-12 16:27 ` Theodore Tso 2007-02-13 6:17 ` Junio C Hamano 2007-02-14 6:38 ` Linus Torvalds 2007-02-14 7:22 ` Junio C Hamano 2007-02-14 11:18 ` Johannes Schindelin 2007-02-14 16:35 ` Linus Torvalds 2007-02-15 1:21 ` Jakub Narebski 2007-02-15 1:34 ` Johannes Schindelin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.