2009/2/13 Owen Taylor <[email protected]>: > On Fri, 2009-02-13 at 18:28 +0100, Santi Béjar wrote: >> Hi, >> >> As the pusher, committer and the author can be different I think the >> pusher should be listed somewhere, maybe: >> >> Subject: [gnome-shell] Bug 570579: Redo the layout of overlay components >> >> Pushed by <userid>: >> <output of git show -p --stat> > > The "pusher" is the From: of the email. > (From: Owen Taylor <[email protected]). Do you think that is > sufficient?
I thought the From: was the author, but if it is the pusher fine. > >> Also, and maybe it is too long, but what about putting the "git >> describe" output or something similar in the subject? >> >> Subject: [pango PANGO_1_23_0-1-g44c9dd3] Bug 570579: Redo the layout >> of overlay components > > The git contrib post-receive-email has the git-describe in the subject > but it seemed more like scary git goo to me than anything useful. If you > want the name of the commit it's right at the top of the body. It was to mimic the svn commit messages that have the r<n> in the subject. > > (PANGO_1_23_0-1-g44c9dd3 never seemed any more descriptive to me > than g44c9dd3 really...) At least it says that the commit is after the PANGO_1_23_0 tag, with a distance of 1 commit since the tag. > > Hmm, a cgit link to the the commit might be a nice addition. Sure. >> > Annotated tag updated >> > Annotated tag deleted >> >> I think tag update and deletion should also be forbidden. > > Branch deletion worries me more than tag deletion (since it can be used > to get around the no-non-fast-forwards restriction.) It should be > possible to recover pretty well from accidentally deleting a tag (the > tag object isn't deleted after all, jut the ref.) What do you see > as the harm/danger? [also for Sandy's comments] Git downloads all the history, in particular the tags. So even if you remove or changed one tag there will be repositories with the old version. Also Git only downloads only automatically new tags (if they tag a commit in the history), but if you update a tag it will not be automatically downloaded, to prevent overwriting an existing tag. If you try the following commands you will see that the tag 'one' is not downloaded: mkdir 1 cd 1/ git init echo a > a git add . git commit -m "a" git tag -a -m 'first' one echo c > a git commit -a -m "b" cd .. git clone 1 2 cd 1 git tag -a -m 'second' second echo b > a git commit -a -m b git tag -f -a -m 'first_b' one cd ../2 git fetch # and the output of the last fetch would be something like: >From /home/santi/kk/1 66df373..e87015a master -> origin/master * [new tag] second -> second you need to do a: git fetch --tags If somebody make a wrong tag and pushes it to the Gnome Git repositories s/he can always make another tag, metacity tags with numbers in a special series, s/he could tag with an extra suffix. It should be the exception not the rule. >> I also think that only annotated tags make sense in the Gnome Git >> repositories, lightweight tag should be forbidden also. > > If we want to allow importing existing repositories into an empty > git.gnome.org repository with 'git push --all --tags' then forbidding > lightweight tags might be a problem. They can make annotated tags as they are done with the current svn -> git conversion. Santi _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
