{"thread":{"id":"1196","subject":"Trial git RPM's..","startedAt":"2005-07-11T01:18:25Z","lastAt":"2005-07-15T00:46:16Z","messageCount":25,"participants":["Linus Torvalds","Eric W. Biederman","Chris Wright","Junio C Hamano","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5924","messageId":"Pine.LNX.4.58.0507101814210.17536@g5.osdl.org","threadId":"1196","inReplyTo":null,"subject":"Trial git RPM's..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-11T01:18:25Z","receivedAt":"2005-07-11T01:18:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, I tagged a \"v0.99\" thing, and pushed it out. I've also made trial \nRPM's of it: src, ppc64 and x86. They're build on whatever random machines \nI had, and on the ppc64 I chose to do it on my FC4 machine that has newer \nlibraries than my YDL one. The x86 thing is FC3, I do believe.\n\nI haven't really verified the RPM's in any other way than a trial \ninstallation on one machine, and \"gitk\" seemed to work. Whoop. The idea \nbeing that this is a good way to check whether the rpm target works, _and_ \ncogito can have something to build against.\n\nThey rpm's are at\n\n\thttp://www.kernel.org/pub/software/scm/git/\n\nor will be once mirrored.\n\n\t\tLinus\n"},{"id":"5947","messageId":"m1eka574c8.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507101814210.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-11T15:24:55Z","receivedAt":"2005-07-11T15:24:55Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> Ok, I tagged a \"v0.99\" thing, and pushed it out. I've also made trial \n> RPM's of it: src, ppc64 and x86. They're build on whatever random machines \n> I had, and on the ppc64 I chose to do it on my FC4 machine that has newer \n> libraries than my YDL one. The x86 thing is FC3, I do believe.\n>\n> I haven't really verified the RPM's in any other way than a trial \n> installation on one machine, and \"gitk\" seemed to work. Whoop. The idea \n> being that this is a good way to check whether the rpm target works, _and_ \n> cogito can have something to build against.\n\nA couple of pieces. The dist target has assumes git-tar-tree is in the\npath. Making it so you have to have git installed to build the rpm.\n\nThe man pages are not built. The build dependencies do not call out\nthe tools necessary to build the man pages.\n\nAnd it does not pass my torture test of building rpm's on debian,\nbut that is not a huge problem.\n\nAre you still up for a patch that records who and when made a tag?\nI sent one but it seems to have been lost.\n\nEric\n"},{"id":"5952","messageId":"Pine.LNX.4.58.0507110958400.17536@g5.osdl.org","threadId":"1196","inReplyTo":"m1eka574c8.fsf@ebiederm.dsl.xmission.com","subject":"Re: Trial git RPM's..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-11T17:06:06Z","receivedAt":"2005-07-11T17:06:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> A couple of pieces. The dist target has assumes git-tar-tree is in the\n> path. Making it so you have to have git installed to build the rpm.\n\nYes. Maybe we could relax that requirement by using \"./git-tar-tree\" or \nsomething? That still requires that you have _built_ git to do the rpm, \nbut at least you won't have had to install it.\n\nDoes that fit the rpm build process? Or does an rpm build make something \nlike that really inconvenient? I don't know, patches welcome.\n\n> The man pages are not built. The build dependencies do not call out\n> the tools necessary to build the man pages.\n\nMost people don't have asciidoc, and I'm not sure we want to require it. \nMaybe we could have a separate \"make man-rpm\" target for that?\n\n> And it does not pass my torture test of building rpm's on debian,\n> but that is not a huge problem.\n\nOk, why is debian problematic? Is there some missing dependency or \nsomething? I really haven't ever done an rpm, and the git rpm target was \nall done by Chris Wright, so I don't have any clue at all. Again, patches \nwelcome.\n\n> Are you still up for a patch that records who and when made a tag?\n> I sent one but it seems to have been lost.\n\nI'd really actually prefer for the code to be shared with the commit code, \nso that the user info (name, email, date) would not just be exactly the \nsame, but would share the same code so that we don't end up having them \never get out of sync. \n\nThat would imply moving parts of \"git-tag-script\" into mktag.c.\n\n\t\tLinus\n"},{"id":"5963","messageId":"20050711203406.GS5324@shell0.pdx.osdl.net","threadId":"1196","inReplyTo":"m1eka574c8.fsf@ebiederm.dsl.xmission.com","subject":"Re: Trial git RPM's..","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-07-11T20:34:06Z","receivedAt":"2005-07-11T20:34:06Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Eric W. Biederman (ebiederm@xmission.com) wrote:\n> Linus Torvalds writes:\n> \n> > Ok, I tagged a \"v0.99\" thing, and pushed it out. I've also made trial \n> > RPM's of it: src, ppc64 and x86. They're build on whatever random machines \n> > I had, and on the ppc64 I chose to do it on my FC4 machine that has newer \n> > libraries than my YDL one. The x86 thing is FC3, I do believe.\n> >\n> > I haven't really verified the RPM's in any other way than a trial \n> > installation on one machine, and \"gitk\" seemed to work. Whoop. The idea \n> > being that this is a good way to check whether the rpm target works, _and_ \n> > cogito can have something to build against.\n> \n> A couple of pieces. The dist target has assumes git-tar-tree is in the\n> path. Making it so you have to have git installed to build the rpm.\n\nKnown, and was a reasonable assumption in my environment. It's simple\nbootstrapping issue.\n\n> The man pages are not built. The build dependencies do not call out\n> the tools necessary to build the man pages.\n\nThat was rather intentional, because the asciidoc package is not common.\n\nthanks,\n-chris\n"},{"id":"5969","messageId":"20050711210309.GT5324@shell0.pdx.osdl.net","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507110958400.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-07-11T21:03:09Z","receivedAt":"2005-07-11T21:03:09Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Linus Torvalds (torvalds@osdl.org) wrote:\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> > \n> > A couple of pieces. The dist target has assumes git-tar-tree is in the\n> > path. Making it so you have to have git installed to build the rpm.\n> \n> Yes. Maybe we could relax that requirement by using \"./git-tar-tree\" or \n> something? That still requires that you have _built_ git to do the rpm, \n> but at least you won't have had to install it.\n> \n> Does that fit the rpm build process? Or does an rpm build make something \n> like that really inconvenient? I don't know, patches welcome.\n\nNo, that could be done. It's not the rpmbuild at that point, it's just\nprepping to do the rpmbuild. It's only an issue for those that are trying\nto build an rpm directly from the git source and who've never installed\ngit before. Doesn't seem necessary to me, I'm not that fond of it (will\neven slightly slow down make dist process if it's done from a clean,\ni.e. make clean, dir), but hey...the trivial patch below does this.\n\n> > And it does not pass my torture test of building rpm's on debian,\n> > but that is not a huge problem.\n> \n> Ok, why is debian problematic? Is there some missing dependency or \n> something? I really haven't ever done an rpm, and the git rpm target was \n> all done by Chris Wright, so I don't have any clue at all. Again, patches \n> welcome.\n\nHeh debian rpm build...I missed that bit in Eric's message. Eric, care\nto give details?\n\nthanks,\n-chris\n--\n\n\n\nUse git-tar-tree directly from git source during make dist. This\nhandles bootstrap issue with git not being installed.\n\nSigned-off-by: Chris Wright \n---\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -175,8 +175,8 @@ git.spec: git.spec.in\n \tsed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@\n \n GIT_TARNAME=git-$(GIT_VERSION)\n-dist: git.spec\n-\tgit-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar\n+dist: git.spec git-tar-tree\n+\t./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar\n \t@mkdir -p $(GIT_TARNAME)\n \t@cp git.spec $(GIT_TARNAME)\n \ttar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git.spec\n"},{"id":"5992","messageId":"m1vf3gzvvd.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507110958400.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T00:55:02Z","receivedAt":"2005-07-12T00:55:02Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>\n>> Are you still up for a patch that records who and when made a tag?\n>> I sent one but it seems to have been lost.\n>\n> I'd really actually prefer for the code to be shared with the commit code, \n> so that the user info (name, email, date) would not just be exactly the \n> same, but would share the same code so that we don't end up having them \n> ever get out of sync. \n\nSounds fair.\n\n> That would imply moving parts of \"git-tag-script\" into mktag.c.\n\nActually I was looking at doing a git-ident thing that will\njust compute who git thinks you are. And then git-commit-tree can\njust popen it to share code. That looks like how the logic has\nbeen accomplished in other places.\n\nMoving parts of git-tag-script into mktag is hard because you\nhave to generate a flat file to pass to gpg. And I don't think\nI am ready to hard code the call to gpg into mktag, as some other\nsigning method may come along. Although that may be the saner\nchoice.\n\nAnyway the git-ident thing is easy and informative for debugging\nso I will finish coding that up as soon as I get home.\n\nEric\n"},{"id":"5994","messageId":"m1u0j0zvpz.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507110958400.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T00:58:16Z","receivedAt":"2005-07-12T00:58:16Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>> \n>> A couple of pieces. The dist target has assumes git-tar-tree is in the\n>> path. Making it so you have to have git installed to build the rpm.\n>\n> Yes. Maybe we could relax that requirement by using \"./git-tar-tree\" or \n> something? That still requires that you have _built_ git to do the rpm, \n> but at least you won't have had to install it.\n>\n> Does that fit the rpm build process? Or does an rpm build make something \n> like that really inconvenient? I don't know, patches welcome.\n\nThat would be sane. The reason I worry about having it installed is\nthat if git-tar-tree changes without building first you will run\nthe old version instead of the new one.\n\n>> The man pages are not built. The build dependencies do not call out\n>> the tools necessary to build the man pages.\n>\n> Most people don't have asciidoc, and I'm not sure we want to require it. \n> Maybe we could have a separate \"make man-rpm\" target for that?\n\nOr just have a make man target and only require the rpm to use it.\nYou certainly want to require making the man pages when building\nthe rpm. Which means only those people who build rpms or build\nman pages need asciidoc. \n\n>> And it does not pass my torture test of building rpm's on debian,\n>> but that is not a huge problem.\n>\n> Ok, why is debian problematic? \n\nMostly because debian is not rpm based. If you are real careful\nyou can build rpm's on debian. It is almost as bad as complaining\nthat git does not build on windows with Microsoft's compiler. I was\ngetting a really generic error. I need to look into it deeper to see\nif is something that is avoidable.\n\n> Is there some missing dependency or \n> something? I really haven't ever done an rpm, and the git rpm target was \n> all done by Chris Wright, so I don't have any clue at all. Again, patches \n> welcome.\n\nWill do.\n\nEric\n"},{"id":"5997","messageId":"Pine.LNX.4.58.0507111815180.17536@g5.osdl.org","threadId":"1196","inReplyTo":"m1vf3gzvvd.fsf@ebiederm.dsl.xmission.com","subject":"Re: Trial git RPM's..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T01:15:52Z","receivedAt":"2005-07-12T01:15:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> Actually I was looking at doing a git-ident thing that will\n> just compute who git thinks you are. And then git-commit-tree can\n> just popen it to share code. That looks like how the logic has\n> been accomplished in other places.\n\nI hate popen() if there's a reasonable functional interface in a library.\n\npopen() is damn inefficient for doing something like this that is all C \nanyway.\n\n\t\tLinus\n"},{"id":"6002","messageId":"m11x647nnw.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507111815180.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T02:39:47Z","receivedAt":"2005-07-12T02:39:47Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>> \n>> Actually I was looking at doing a git-ident thing that will\n>> just compute who git thinks you are. And then git-commit-tree can\n>> just popen it to share code. That looks like how the logic has\n>> been accomplished in other places.\n>\n> I hate popen() if there's a reasonable functional interface in a library.\n> popen() is damn inefficient for doing something like this that is all C \n> anyway.\n\nOk two new files then. The new library function, and then\nthe utility that calls it.\n\nEric\n"},{"id":"6012","messageId":"m1slyk63k2.fsf_-_@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507111815180.17536@g5.osdl.org","subject":"[PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T04:39:25Z","receivedAt":"2005-07-12T04:39:25Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nThis patch adds a command git-id for use on\nthe command line to see what git will set your id too,\nand for use in scripts (git-tag-script) so they can get your git id.\n\nThe common code for computing the git-id is moved to ident.c\n\nFix parse_date to not mind being passed a constant date\nto parse.\n\nThe code to compute the identifier has been restructured\nto at least make a reasonable stab at error handling. The\noriginal version had so many unchecked return values it was\njust scary to think about.\n\nEric\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -47,7 +47,7 @@ PROG= git-update-cache git-diff-files \n \tgit-diff-stages git-rev-parse git-patch-id git-pack-objects \\\n \tgit-unpack-objects git-verify-pack git-receive-pack git-send-pack \\\n \tgit-prune-packed git-fetch-pack git-upload-pack git-clone-pack \\\n-\tgit-show-index\n+\tgit-show-index git-id\n \n all: $(PROG)\n \n@@ -57,7 +57,7 @@ install: $(PROG) $(SCRIPTS)\n \n LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \\\n \t tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \\\n-\t epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o\n+\t epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o\n LIB_FILE=libgit.a\n LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h csum-file.h \\\n \tpack.h pkt-line.h refs.h\ndiff --git a/cache.h b/cache.h\n--- a/cache.h\n+++ b/cache.h\n@@ -208,9 +208,14 @@ extern void *read_object_with_reference(\n \t\t\t\t\tunsigned char *sha1_ret);\n \n const char *show_date(unsigned long time, int timezone);\n-void parse_date(char *date, char *buf, int bufsize);\n+void parse_date(const char *date, char *buf, int bufsize);\n void datestamp(char *buf, int bufsize);\n \n+int git_ident(char *buf, size_t bufsize,\n+\tconst char *env_name, const char *env_email, const char *env_date);\n+int git_committer_ident(char *buf, size_t bufsize);\n+int git_author_ident(char *buf, size_t bufsize);\n+\n static inline void *xmalloc(size_t size)\n {\n \tvoid *ret = malloc(size);\ndiff --git a/commit-tree.c b/commit-tree.c\n--- a/commit-tree.c\n+++ b/commit-tree.c\n@@ -5,9 +5,10 @@\n */\n #include \"cache.h\"\n \n-#include \n #include \n #include \n+#include \n+#include \n \n #define BLOCKING (1ul << 14)\n \n@@ -45,39 +46,6 @@ static void add_buffer(char **bufp, unsi\n \tmemcpy(buf + size, one_line, len);\n }\n \n-static void remove_special(char *p)\n-{\n-\tchar c;\n-\tchar *dst = p, *src = p;\n-\n-\tfor (;;) {\n-\t\tc = *src;\n-\t\tsrc++;\n-\t\tswitch(c) {\n-\t\tcase '\\n': case '<': case '>':\n-\t\t\tcontinue;\n-\t\t}\n-\t\t*dst++ = c;\n-\t\tif (!c)\n-\t\t\tbreak;\n-\t}\n-\n-\t/*\n-\t * Go back, and remove crud from the end: some people\n-\t * have commas etc in their gecos field\n-\t */\n-\tdst--;\n-\twhile (--dst >= p) {\n-\t\tunsigned char c = *dst;\n-\t\tswitch (c) {\n-\t\tcase ',': case ';': case '.':\n-\t\t\t*dst = 0;\n-\t\t\tcontinue;\n-\t\t}\n-\t\tbreak;\n-\t}\n-}\n-\n static void check_valid(unsigned char *sha1, const char *expect)\n {\n \tvoid *buf;\n@@ -114,16 +82,13 @@ static int new_parent(int idx)\n \n int main(int argc, char **argv)\n {\n-\tint i, len;\n+\tint i;\n \tint parents = 0;\n \tunsigned char tree_sha1[20];\n \tunsigned char commit_sha1[20];\n-\tchar *gecos, *realgecos, *commitgecos;\n-\tchar *email, *commitemail, realemail[1000];\n-\tchar date[50], realdate[50];\n-\tchar *audate, *cmdate;\n+\tchar committer[1000];\n+\tchar author[1000];\n \tchar comment[1000];\n-\tstruct passwd *pw;\n \tchar *buffer;\n \tunsigned int size;\n \n@@ -142,35 +107,12 @@ int main(int argc, char **argv)\n \t}\n \tif (!parents)\n \t\tfprintf(stderr, \"Committing initial tree %s\\n\", argv[1]);\n-\tpw = getpwuid(getuid());\n-\tif (!pw)\n-\t\tdie(\"You don't exist. Go away!\");\n-\trealgecos = pw->pw_gecos;\n-\tlen = strlen(pw->pw_name);\n-\tmemcpy(realemail, pw->pw_name, len);\n-\trealemail[len] = '@';\n-\tgethostname(realemail+len+1, sizeof(realemail)-len-1);\n-\tif (!strchr(realemail+len+1, '.')) {\n-\t\tstrcat(realemail, \".\");\n-\t\tgetdomainname(realemail+strlen(realemail), sizeof(realemail)-strlen(realemail)-1);\n+\tif (git_author_ident(author, sizeof(author)) < 0) {\n+\t\tdie(\"Bad author! %s\", strerror(errno));\n+\t}\n+\tif (git_committer_ident(committer, sizeof(committer)) < 0) {\n+\t\tdie(\"Bad Committer! %s\", strerror(errno));\n \t}\n-\n-\tdatestamp(realdate, sizeof(realdate));\n-\tstrcpy(date, realdate);\n-\n-\tcommitgecos = gitenv(\"GIT_COMMITTER_NAME\") ? : realgecos;\n-\tcommitemail = gitenv(\"GIT_COMMITTER_EMAIL\") ? : realemail;\n-\tgecos = gitenv(\"GIT_AUTHOR_NAME\") ? : realgecos;\n-\temail = gitenv(\"GIT_AUTHOR_EMAIL\") ? : realemail;\n-\taudate = gitenv(\"GIT_AUTHOR_DATE\");\n-\tif (audate)\n-\t\tparse_date(audate, date, sizeof(date));\n-\tcmdate = gitenv(\"GIT_COMMITTER_DATE\");\n-\tif (cmdate)\n-\t\tparse_date(cmdate, realdate, sizeof(realdate));\n-\n-\tremove_special(gecos); remove_special(realgecos); remove_special(commitgecos);\n-\tremove_special(email); remove_special(realemail); remove_special(commitemail);\n \n \tinit_buffer(&buffer, &size);\n \tadd_buffer(&buffer, &size, \"tree %s\\n\", sha1_to_hex(tree_sha1));\n@@ -184,8 +126,8 @@ int main(int argc, char **argv)\n \t\tadd_buffer(&buffer, &size, \"parent %s\\n\", sha1_to_hex(parent_sha1[i]));\n \n \t/* Person/date information */\n-\tadd_buffer(&buffer, &size, \"author %s <%s> %s\\n\", gecos, email, date);\n-\tadd_buffer(&buffer, &size, \"committer %s <%s> %s\\n\\n\", commitgecos, commitemail, realdate);\n+\tadd_buffer(&buffer, &size, \"author %s <%s> %s\\n\", author);\n+\tadd_buffer(&buffer, &size, \"committer %s <%s> %s\\n\\n\", committer);\n \n \t/* And add the comment */\n \twhile (fgets(comment, sizeof(comment), stdin) != NULL)\ndiff --git a/date.c b/date.c\n--- a/date.c\n+++ b/date.c\n@@ -224,7 +224,7 @@ static int is_date(int year, int month, \n \treturn 0;\n }\n \n-static int match_multi_number(unsigned long num, char c, char *date, char *end, struct tm *tm)\n+static int match_multi_number(unsigned long num, char c, const char *date, char *end, struct tm *tm)\n {\n \tlong num2, num3;\n \n@@ -270,7 +270,7 @@ static int match_multi_number(unsigned l\n /*\n * We've seen a digit. Time? Year? Date? \n */\n-static int match_digit(char *date, struct tm *tm, int *offset, int *tm_gmt)\n+static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt)\n {\n \tint n;\n \tchar *end;\n@@ -361,7 +361,7 @@ static int match_digit(char *date, struc\n \treturn n;\n }\n \n-static int match_tz(char *date, int *offp)\n+static int match_tz(const char *date, int *offp)\n {\n \tchar *end;\n \tint offset = strtoul(date+1, &end, 10);\n@@ -388,7 +388,7 @@ static int match_tz(char *date, int *off\n \n /* Gr. strptime is crap for this; it doesn't have a way to require RFC2822\n (i.e. English) day/month names, and it doesn't work correctly with %z. */\n-void parse_date(char *date, char *result, int maxlen)\n+void parse_date(const char *date, char *result, int maxlen)\n {\n \tstruct tm tm;\n \tint offset, sign, tm_gmt;\ndiff --git a/git-tag-script b/git-tag-script\n--- a/git-tag-script\n+++ b/git-tag-script\n@@ -7,6 +7,7 @@ name=\"$1\"\n \n object=${2:-$(cat \"$GIT_DIR\"/HEAD)}\n type=$(git-cat-file -t $object) || exit 1\n+tagger=$(git-id) || exit 1\n \n ( echo \"#\"\n echo \"# Write a tag message\"\n@@ -17,8 +18,9 @@ grep -v '^#' < .editmsg | git-stripspace\n \n [ -s .tagmsg ] || exit\n \n-( echo -e \"object $object\\ntype $type\\ntag $name\\n\"; cat .tagmsg ) > .tmp-tag\n+( echo -e \"object $object\\ntype $type\\ntag $name\\ntagger $tagger\\n\"; cat .tagmsg ) > .tmp-tag\n rm -f .tmp-tag.asc .tagmsg\n gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag\n+mkdir -p \"$GIT_DIR/refs/tags\"\n git-mktag < .tmp-tag > \"$GIT_DIR/refs/tags/$name\"\n #rm .tmp-tag .tmp-tag.sig\ndiff --git a/id.c b/id.c\nnew file mode 100644\n--- /dev/null\n+++ b/id.c\n@@ -0,0 +1,36 @@\n+#include \"cache.h\"\n+#include \n+#include \n+#include \n+\n+static char *id_usage = \"git-id [--author | --committer]\";\n+\n+int main(int argc, char **argv)\n+{\n+\tchar buf[1000];\n+\tint (*ident)(char *buf, size_t bufsize);\n+\tint i;\n+\n+\tident = git_committer_ident;\n+\tfor(i = 1; i < argc; i++) {\n+\t\tchar *arg = argv[i];\n+\t\tif (strcmp(arg, \"--author\") == 0) {\n+\t\t\tident = git_author_ident;\n+\t\t}\n+\t\telse if (strcmp(arg, \"--committer\") == 0) {\n+\t\t\tident = git_committer_ident;\n+\t\t}\n+\t\telse {\n+\t\t\tusage(id_usage);\n+\t\t}\n+\t}\n+\n+\n+\tif (ident(buf, sizeof(buf)) < 0) {\n+\t\tdie(\"Cannot resolve ident: %s\\n\", strerror(errno));\n+\t}\n+\n+\tprintf(\"%s\\n\", buf);\n+\n+\treturn 0;\n+}\ndiff --git a/ident.c b/ident.c\nnew file mode 100644\n--- /dev/null\n+++ b/ident.c\n@@ -0,0 +1,144 @@\n+/*\n+ * GIT - The information manager from hell\n+ *\n+ * Copyright (C) Eric Biederman, 2005\n+ */\n+#include \"cache.h\"\n+\n+#include \n+#include \n+#include \n+#include \n+#include \n+#include \n+\n+#define MAX_NAME 1000\n+#define MAX_EMAIL 1000\n+#define MAX_DATE 50\n+static void remove_special(char *p)\n+{\n+\tchar c;\n+\tchar *dst = p, *src = p;\n+\n+\tfor (;;) {\n+\t\tc = *src;\n+\t\tsrc++;\n+\t\tswitch(c) {\n+\t\tcase '\\n': case '<': case '>':\n+\t\t\tcontinue;\n+\t\t}\n+\t\t*dst++ = c;\n+\t\tif (!c)\n+\t\t\tbreak;\n+\t}\n+\n+\t/*\n+\t * Go back, and remove crud from the end: some people\n+\t * have commas etc in their gecos field\n+\t */\n+\tdst--;\n+\twhile (--dst >= p) {\n+\t\tunsigned char c = *dst;\n+\t\tswitch (c) {\n+\t\tcase ',': case ';': case '.':\n+\t\t\t*dst = 0;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tbreak;\n+\t}\n+}\n+\n+int git_ident(char *buf, size_t bufsize,\n+\tconst char *env_name, const char *env_email, const char *env_date)\n+{\n+\tint len;\n+\tchar name[MAX_NAME];\n+\tchar email[MAX_EMAIL];\n+\tchar date[MAX_DATE];\n+\tstruct passwd *pw;\n+\tint count;\n+\t\n+\t/* Lookup the user in the password file */\n+\tpw = getpwuid(getuid());\n+\tif (!pw)\n+\t\treturn -1;\n+\n+\t/* Get the users full name */\n+\tstrncpy(name, pw->pw_gecos, sizeof(name));\n+\tname[sizeof(name) - 1] = '\\0';\n+\n+\t/* Get the email address with error handling */\n+\tlen = strlen(pw->pw_name);\n+\tif (len >= (sizeof(email) - 2)) {\n+\t\t/* Bad user name length */\n+\t\terrno = ENOMEM;\n+\t\treturn -1;\n+\t}\n+\tmemcpy(email, pw->pw_name, len);\n+\temail[len] = '@';\n+\temail[len + 1] = '\\0';\n+\n+\tif (gethostname(email+len+1, sizeof(email)-len-1) < 0) {\n+\t\treturn -1;\n+\t}\n+\temail[sizeof(email) - 1] = '\\0';\n+\tlen = strlen(email);\n+\tif (!strchr(email+len+1, '.')) {\n+\t\tif (len >= (sizeof(email) - 1)) {\n+\t\t\terrno = ENOMEM;\n+\t\t\treturn -1;\n+\t\t}\n+\t\temail[len] = '.';\n+\t\tif (getdomainname(email+len+1, sizeof(email) - len - 1) < 0) {\n+\t\t\treturn -1;\n+\t\t}\n+\t}\n+\t/* Get the date */\n+\tdatestamp(date, sizeof(date));\n+\n+\tif (env_name) {\n+\t\tstrncpy(name, env_name, sizeof(name));\n+\t\tname[sizeof(name) - 1] = '\\0';\n+\t}\n+\tif (env_email) {\n+\t\tstrncpy(email, env_email, sizeof(email));\n+\t\temail[sizeof(email) - 1] = '\\0';\n+\t}\n+\tif (env_date) {\n+\t\tparse_date(env_date, date, sizeof(date));\n+\t}\n+\tremove_special(name);\n+\tremove_special(email);\n+\tcount = snprintf(buf, bufsize, \"%s <%s> %s\", name, email, date);\n+\tif (count > bufsize) {\n+\t\terrno = ENOMEM;\n+\t\treturn -1;\n+\t}\n+\tif (count < 0) {\n+\t\treturn -1;\n+\t}\n+\treturn 0;\n+}\n+\n+int git_committer_ident(char *buf, size_t bufsize)\n+{\n+\tconst char *name;\n+\tconst char *email;\n+\tconst char *date;\n+\tname = gitenv(\"GIT_COMMITTER_NAME\");\n+\temail = gitenv(\"GIT_COMMITTER_EMAIL\");\n+\tdate = gitenv(\"GIT_COMMITTER_DATE\");\n+\treturn git_ident(buf, bufsize, name, email, date);\n+}\n+\n+int git_author_ident(char *buf, size_t bufsize)\n+{\n+\tconst char *name;\n+\tconst char *email;\n+\tconst char *date;\n+\tname = gitenv(\"GIT_AUTHOR_NAME\");\n+\temail = gitenv(\"GIT_AUTHOR_EMAIL\");\n+\tdate = gitenv(\"GIT_AUTHOR_DATE\");\n+\treturn git_ident(buf, bufsize, name, email, date);\n+}\n+\ndiff --git a/mktag.c b/mktag.c\n--- a/mktag.c\n+++ b/mktag.c\n@@ -42,7 +42,7 @@ static int verify_tag(char *buffer, unsi\n \tint typelen;\n \tchar type[20];\n \tunsigned char sha1[20];\n-\tconst char *object, *type_line, *tag_line;\n+\tconst char *object, *type_line, *tag_line, *tagger_line;\n \n \tif (size < 64 || size > MAXSIZE-1)\n \t\treturn -1;\n@@ -92,6 +92,12 @@ static int verify_tag(char *buffer, unsi\n \t\treturn -1;\n \t}\n \n+\t/* Verify the tagger line */\n+\ttagger_line = tag_line;\n+\t\n+\tif (memcmp(tagger_line, \"tagger\", 6) || (tagger_line[6] == '\\n'))\n+\t\treturn -1;\n+\n \t/* The actual stuff afterwards we don't care about.. */\n \treturn 0;\n }\n@@ -119,7 +125,7 @@ int main(int argc, char **argv)\n \t\tsize += ret;\n \t}\n \n-\t// Verify it for some basic sanity: it needs to start with \"object \\ntype \"\n+\t// Verify it for some basic sanity: it needs to start with \"object \\ntype\\ntagger \"\n \tif (verify_tag(buffer, size) < 0)\n \t\tdie(\"invalid tag signature file\");\n \n"},{"id":"6021","messageId":"m18y0c1prv.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"m1slyk63k2.fsf_-_@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T06:50:44Z","receivedAt":"2005-07-12T06:50:44Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> This patch adds a command git-id for use on\n> the command line to see what git will set your id too,\n> and for use in scripts (git-tag-script) so they can get your git id.\n>\n> The common code for computing the git-id is moved to ident.c\n>\n> Fix parse_date to not mind being passed a constant date\n> to parse.\n>\n> The code to compute the identifier has been restructured\n> to at least make a reasonable stab at error handling. The\n> original version had so many unchecked return values it was\n> just scary to think about.\n\nWell except for a small bug, but serious bug...\n\n> diff --git a/commit-tree.c b/commit-tree.c\n> --- a/commit-tree.c\n> +++ b/commit-tree.c\n> @@ -184,8 +126,8 @@ int main(int argc, char **argv)\n> \t\tadd_buffer(&buffer, &size, \"parent %s\\n\",\n> sha1_to_hex(parent_sha1[i]));\n> \n> \t/* Person/date information */\n> -\tadd_buffer(&buffer, &size, \"author %s <%s> %s\\n\", gecos, email, date);\n> - add_buffer(&buffer, &size, \"committer %s <%s> %s\\n\\n\", commitgecos,\n> commitemail, realdate);\n> +\tadd_buffer(&buffer, &size, \"author %s <%s> %s\\n\", author);\n> +\tadd_buffer(&buffer, &size, \"committer %s <%s> %s\\n\\n\", committer);\n\nThis should be:\n> +\tadd_buffer(&buffer, &size, \"author %s\\n\", author);\n> +\tadd_buffer(&buffer, &size, \"committer %s\\n\\n\", committer);\n\n> \n> \t/* And add the comment */\n> \twhile (fgets(comment, sizeof(comment), stdin) != NULL)\n> diff --git a/id.c b/id.c\n> new file mode 100644\n> --- /dev/null\n> +++ b/id.c\n> @@ -0,0 +1,36 @@\n> +#include \"cache.h\"\n> +#include \n> +#include \n> +#include \n> +\n> +static char *id_usage = \"git-id [--author | --committer]\";\n> +\n> +int main(int argc, char **argv)\n> +{\n> +\tchar buf[1000];\n> +\tint (*ident)(char *buf, size_t bufsize);\n> +\tint i;\n> +\n> +\tident = git_committer_ident;\n\nShould this default to git_author_ident or git_committer_ident?\nI'm not really certain how we expect to use the different flavors.\n\nEric\n"},{"id":"6027","messageId":"7veka48lcw.fsf@assigned-by-dhcp.cox.net","threadId":"1196","inReplyTo":"m18y0c1prv.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-12T08:44:15Z","receivedAt":"2005-07-12T08:44:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> Should this default to git_author_ident or git_committer_ident?\n> I'm not really certain how we expect to use the different flavors.\n\nThe only in-tree user after your patch is applied is the tagger\nstuff, so in that sense committer_ident may make more sense.\nHaving said that, for something like this that would not be used\nconstantly and interatively by the users, my preference is not\nto have any default at all, and always require --author or\n--committer. You have to type a bit more when doing the script,\nbut that needs to be done only once. You will be sure which one\nyou are asking from the command two weeks after you wrote the\nscript so it is not a big loss.\n\nI am not seriously suggesting the below as an alternative, but\nhave you thought about doing an inverse function of your\ncomputation for the case when the user has all the environment\nvariables, and have script eval its output, like this [*1*]:\n\n $ git-id\n GIT_AUTHOR_NAME='Junio C Hamano'\n GIT_AUTHOR_EMAIL='junkio@cox.net'\n GIT_COMMITTER_NAME='Junio C Hamano'\n GIT_COMMITTER_EMAIL='junkio@cox.net'\n $ eval \"`git-id`\"\n $ tagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>\"\n\nHaving names and emails available separately may turn out to be\neasier to use in other situation. Just a thought.\n\nBy the way, I do not particularly like the name \"git-id\". There\ncould be IDs for different kinds (not just people) we would want\nlater (file IDs, for example). Naming what you are computing\n_the_ \"id\" feels a bit too generic. I do not have a better\nalternative to suggest, though.\n\n[Footnote]\n\n*1* This makes its output syntax a bit too specific to the shell\nand unfriendly to Porcelain written in other languages. The\nonly non-shell Porcelains I am aware of are done in Perl (I do\nnot remember hearing its name) and Python (StGIT), both of which\nhave reasonable regexp support to grok something like this, so\nit would not be a big issue.\n"},{"id":"6035","messageId":"m14qb012x4.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"7veka48lcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T15:04:23Z","receivedAt":"2005-07-12T15:04:23Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano writes:\n\n> ebiederm@xmission.com (Eric W. Biederman) writes:\n>\n>> Should this default to git_author_ident or git_committer_ident?\n>> I'm not really certain how we expect to use the different flavors.\n>\n> The only in-tree user after your patch is applied is the tagger\n> stuff, so in that sense committer_ident may make more sense.\n\nThere is also the commit path, and that comes from C. I'm not\nquite certain how we should be using the environmental variables.\n\n> Having said that, for something like this that would not be used\n> constantly and interatively by the users, my preference is not\n> to have any default at all, and always require --author or\n> --committer. You have to type a bit more when doing the script,\n> but that needs to be done only once. You will be sure which one\n> you are asking from the command two weeks after you wrote the\n> script so it is not a big loss.\n\nMake sense. Although I'm not quite certain we actually need the\ninformation twice. Possibly we just have GIT_AUTHOR_NAME and\nGIT_AUTHOR_EMAIL, and then have commit-write take a flag to\noverride the author bit. That would certainly make it less\nconfusing when setting up environmental variables for git.\nAnd that would also give us a better name.\n\n> I am not seriously suggesting the below as an alternative, but\n> have you thought about doing an inverse function of your\n> computation for the case when the user has all the environment\n> variables, and have script eval its output, like this [*1*]:\n>\n> $ git-id\n> GIT_AUTHOR_NAME='Junio C Hamano'\n> GIT_AUTHOR_EMAIL='junkio@cox.net'\n> GIT_COMMITTER_NAME='Junio C Hamano'\n> GIT_COMMITTER_EMAIL='junkio@cox.net'\n> $ eval \"`git-id`\"\n> $ tagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>\"\n>\n> Having names and emails available separately may turn out to be\n> easier to use in other situation. Just a thought.\n\nPart of the request was to put all of this information together\nin a common place. And note that it is actually:\ntagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE\"\nWhere the date is a human unreadable string of the number of seconds\nsince the epoch (aka 1 Jan 1970 UTC).\n\n> By the way, I do not particularly like the name \"git-id\". There\n> could be IDs for different kinds (not just people) we would want\n> later (file IDs, for example). Naming what you are computing\n> _the_ \"id\" feels a bit too generic. I do not have a better\n> alternative to suggest, though.\n\nAgreed. Something like git-author or git-author-stamp is probably\nbetter.\n\n> *1* This makes its output syntax a bit too specific to the shell\n> and unfriendly to Porcelain written in other languages. The\n> only non-shell Porcelains I am aware of are done in Perl (I do\n> not remember hearing its name) and Python (StGIT), both of which\n> have reasonable regexp support to grok something like this, so\n> it would not be a big issue.\n\nAnd in git-commit-script this is actually parsed by sed which makes\nit so the shell can parse the information as well so I think\nwe are fine in that sense.\n\nEric\n"},{"id":"6036","messageId":"20050712151420.GC15794@pasky.ji.cz","threadId":"1196","inReplyTo":"m14qb012x4.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-12T15:14:20Z","receivedAt":"2005-07-12T15:14:20Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jul 12, 2005 at 05:04:23PM CEST, I got a letter\nwhere \"Eric W. Biederman\" told me that...\n> > By the way, I do not particularly like the name \"git-id\". There\n> > could be IDs for different kinds (not just people) we would want\n> > later (file IDs, for example). Naming what you are computing\n> > _the_ \"id\" feels a bit too generic. I do not have a better\n> > alternative to suggest, though.\n> \n> Agreed. Something like git-author or git-author-stamp is probably\n> better.\n\nSince that \"infriges\" the author/committer distinction, I would prefer\ngit-person-id.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"6038","messageId":"m1zmssyq0r.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"20050711210309.GT5324@shell0.pdx.osdl.net","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T15:59:00Z","receivedAt":"2005-07-12T15:59:00Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Chris Wright writes:\n\n> * Linus Torvalds (torvalds@osdl.org) wrote:\n>> > And it does not pass my torture test of building rpm's on debian,\n>> > but that is not a huge problem.\n>> \n>> Ok, why is debian problematic? Is there some missing dependency or \n>> something? I really haven't ever done an rpm, and the git rpm target was \n>> all done by Chris Wright, so I don't have any clue at all. Again, patches \n>> welcome.\n>\n> Heh debian rpm build...I missed that bit in Eric's message. Eric, care\n> to give details?\n\nOk paged back in my state. The practical problem is that rpmbuild try\nto lookup the build dependencies which simply aren't present on debian.\nPatch will be along shortly once I get the glitches fixed.\n\nOne last issue with building packages. Some distros are still shipping\nGNU interactive tools so git as a package name for the rpm is problematic.\nAt the very least it is extremely confusing that git-0.99 is a more\nrecent package that git-4.3.20.\n\nEric\n"},{"id":"6043","messageId":"Pine.LNX.4.58.0507120959550.17536@g5.osdl.org","threadId":"1196","inReplyTo":"m1zmssyq0r.fsf@ebiederm.dsl.xmission.com","subject":"Re: Trial git RPM's..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T17:01:51Z","receivedAt":"2005-07-12T17:01:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jul 2005, Eric W. Biederman wrote:\n> \n> One last issue with building packages. Some distros are still shipping\n> GNU interactive tools so git as a package name for the rpm is problematic.\n> At the very least it is extremely confusing that git-0.99 is a more\n> recent package that git-4.3.20.\n\nAhh. Dang, I should have remembered this. We should call the rpm \n\"git-core-0.99\", not just \"git-0.99\".\n\nChris, I assume this is just changing the name in the spec-file from \"git\" \nto \"git-core\"?\n\n\t\tLinus\n"},{"id":"6044","messageId":"m1vf3gymi4.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507120959550.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T17:14:59Z","receivedAt":"2005-07-12T17:14:59Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> Ahh. Dang, I should have remembered this. We should call the rpm \n> \"git-core-0.99\", not just \"git-0.99\".\n>\n> Chris, I assume this is just changing the name in the spec-file from \"git\" \n> to \"git-core\"?\n\nThe name of the tarball needs to be updated as well.\n\nEric\n"},{"id":"6046","messageId":"Pine.LNX.4.58.0507121027120.17536@g5.osdl.org","threadId":"1196","inReplyTo":"m1vf3gymi4.fsf@ebiederm.dsl.xmission.com","subject":"Re: Trial git RPM's..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T17:27:33Z","receivedAt":"2005-07-12T17:27:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jul 2005, Eric W. Biederman wrote:\n> \n> The name of the tarball needs to be updated as well.\n\nYes, I noticed.\n\nI ended up renaming the spec-file too.\n\nPushed out,\n\n\t\tLinus\n"},{"id":"6047","messageId":"20050712174605.GV19052@shell0.pdx.osdl.net","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507121027120.17536@g5.osdl.org","subject":"Re: Trial git RPM's..","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-07-12T17:46:05Z","receivedAt":"2005-07-12T17:46:05Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Linus Torvalds (torvalds@osdl.org) wrote:\n> On Tue, 12 Jul 2005, Eric W. Biederman wrote:\n> > The name of the tarball needs to be updated as well.\n> \n> Yes, I noticed.\n> \n> I ended up renaming the spec-file too.\n> \n> Pushed out,\n\nYup, looks good.\n-chris\n"},{"id":"6051","messageId":"Pine.LNX.4.58.0507121152260.17536@g5.osdl.org","threadId":"1196","inReplyTo":"m18y0c1prv.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T18:54:05Z","receivedAt":"2005-07-12T18:54:05Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nEric,\n I ended up coding the ident stuff a bit differently, and I didn't do done\nthe tag/git-id part yet. Can you check out my latest commit (pushed out, \nbut it will probably take a few minutes to mirror out), and do the final \ntag stuff based on that? \n\n\t\tLinus\n"},{"id":"6057","messageId":"loom.20050712T230013-978@post.gmane.org","threadId":"1196","inReplyTo":"m14qb012x4.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Junio C Hamano","fromEmail":"junkio@twinsun.com","sentAt":"2005-07-12T21:16:52Z","receivedAt":"2005-07-12T21:16:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric W. Biederman xmission.com> writes:\n\n> \n> Junio C Hamano cox.net> writes:\n>\n> > The only in-tree user after your patch is applied is the tagger\n> > stuff, so in that sense committer_ident may make more sense.\n> \n> There is also the commit path, and that comes from C. I'm not\n> quite certain how we should be using the environmental variables.\n\nBut there you would not have \"default\" issue, would you?\n\n> Part of the request was to put all of this information together\n> in a common place. And note that it is actually:\n> tagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE\"\n> Where the date is a human unreadable string of the number of seconds\n> since the epoch (aka 1 Jan 1970 UTC).\n\nThis may sound whacy, but how about having git-env command that\n\n (1) parrots GIT_* environment variables if the user has one; or\n (2) shows the values of environment variables the user _could_ have had\n to cause the program to behave the same way, when it the user does\n not have them?\n\nSynopsis.\n\n $ git-env [--values-only] [...]\n\nExamples.\n\n $ git-env GIT_COMMITER_DATE GIT_AUTHOR_NAME\n GIT_COMMITTER_DATE='1121202267 -0700'\n GIT_AUTHOR_NAME='Junio C Hamano'\n $ unset GIT_OBJECT_DIRECTORY\n $ GIT_DIR=foo git-env --values-only GIT_OBJECT_DIRECTORY\n foo/objects\n $ git-env\n GIT_DIR=.git\n GIT_OBJECT_DIRECTORY=.git/objects\n ...\n $ eval \"`git-env GIT_COMMITTER_DATE GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE`\"\n $ tagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE\"\n\nWe could add a couple of \"variable name\"s that we do _not_ use\nfrom the environment as a shorthand as well while we are at it,\nso that you can say:\n\n $ git-env GIT_COMMITTER_ID\n GIT_COMMITTER_ID='Junio C Hamano 1121202267 -0700'\n\nOnce we go this route, it may even make sense to have that GIT_COMMITTER_ID\nenvironment variable as well. I don't know..\n"},{"id":"6062","messageId":"m1pstnzn5j.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"Pine.LNX.4.58.0507121152260.17536@g5.osdl.org","subject":"Re: [PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T22:15:36Z","receivedAt":"2005-07-12T22:15:36Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> Eric,\n> I ended up coding the ident stuff a bit differently, and I didn't do done\n> the tag/git-id part yet. Can you check out my latest commit (pushed out, \n> but it will probably take a few minutes to mirror out), and do the final \n> tag stuff based on that? \n\nFor the most part it looks sane. I'm not really thrilled that\nsetup_ident() calls die, and when complaining about the user\nname we should probably complain that their sysadmin hated\nthen if it is over a 1000 characters not their parents :)\n\nI'm also not at all thrilled with global variables. Globals aren't\nthe source of all evil but they have a lot better claim than goto.\nAt least real_email and friends are file local. If you like\nit and the code works git is you project and I won't complain again.\n\nSince we are still looking at this there is one change in the user\ninterface I would like to make to simplify things for the end user.\nThe only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script\nwhen we you are making a new commit based on an old commit. Can\nwe add a command line option to git-commit-write, --author\nthat will allow the author field to be overridden. Allowing us\nto get down to a single set of GIT variables for specifying who\nthe user is?\n\nThat also simplifies the tagging case and answers the question \nwhich environment variables tags should look at, to see who the\nuser is. \n\nEric\n"},{"id":"6063","messageId":"loom.20050713T011619-369@post.gmane.org","threadId":"1196","inReplyTo":"m1pstnzn5j.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] tagger id","fromName":"Junio C Hamano","fromEmail":"junkio@twinsun.com","sentAt":"2005-07-12T23:42:13Z","receivedAt":"2005-07-12T23:42:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric W. Biederman xmission.com> writes:\n\n> Since we are still looking at this there is one change in the user\n> interface I would like to make to simplify things for the end user.\n> The only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script\n> when we you are making a new commit based on an old commit...\n\nI am afraid I do not follow you. For a \"project lead\" person like Linus, who\ntakes an e-mail submission of patches, GIT_AUTHOR is almost always different\nfrom the committer, and typically set up by the program that reads the e-mail\nto snarf the From: and Date: lines via environment variables, when the incoming\npatches are being processed. He is saying \"I am the COMMITTER, and this commit\nI am making is written by this AUTHOR\".\n\nAUTHOR can be set to somebody other than yourself and that is a typical mode\nof operation for a \"project lead\" person.\n\nOn the other hand, we made COMMITTER overridable only because (1) the\ncomputed value from the system are often not quite right on many systems\nwith weird GECOS field or domain/e-mail setup, and (2) when converting from\na foreign SCM, we wanted to keep the committer information (and dates), if\navailable. Only in (2), which is quite a special case, COMMITTER names\nsomebody different from yourself.\n\nWhat this means is that if you are asking the question \"who the user is\",\nthe answer _should_ always come from COMMITTER. \n\n> That also simplifies the tagging case and answers the question \n> which environment variables tags should look at, to see who the\n> user is. \n\nThe intent of \"tags\" (especially the signed kind) is to express \"trust\":\n\"This commit is called v2.6.12 and *I* vouch for it.\"\n\nCOMMITTER is the only sensible thing to use there, because (as you said)\nwhat you care is \"who I am\", not \"for whom I am doing this\". \n"},{"id":"6153","messageId":"m14qawzyzy.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"loom.20050713T011619-369@post.gmane.org","subject":"Re: [PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-15T00:36:33Z","receivedAt":"2005-07-15T00:36:33Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano writes:\n\n> I am afraid I do not follow you. \n\nI was confused. My big problem was that we don't really have\nan in tree user, and there wasn't a good explanation anywhere. So it\nwas hard to track this down. \n\nI'm going to lobby for a script to import patches from email being\nin the git tree just so people can see how this is done, and probably\nbecause there are a lot of people who have been reinventing this\nscript :)\n\n> The intent of \"tags\" (especially the signed kind) is to express \"trust\":\n> \"This commit is called v2.6.12 and *I* vouch for it.\"\n>\n> COMMITTER is the only sensible thing to use there, because (as you said)\n> what you care is \"who I am\", not \"for whom I am doing this\"\n\nSounds good.\n\nEric\n"},{"id":"6154","messageId":"m1zmsoyjzb.fsf@ebiederm.dsl.xmission.com","threadId":"1196","inReplyTo":"loom.20050712T230013-978@post.gmane.org","subject":"Re: [PATCH] tagger id","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-15T00:46:16Z","receivedAt":"2005-07-15T00:46:16Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano writes:\n\n> Eric W. Biederman xmission.com> writes:\n>\n>\n>> Part of the request was to put all of this information together\n>> in a common place. And note that it is actually:\n>> tagger=\"$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE\"\n>> Where the date is a human unreadable string of the number of seconds\n>> since the epoch (aka 1 Jan 1970 UTC).\n>\n> This may sound whacy, but how about having git-env command that\n>\n> (1) parrots GIT_* environment variables if the user has one; or\n> (2) shows the values of environment variables the user _could_ have had\n> to cause the program to behave the same way, when it the user does\n> not have them?\n\nI like the general idea. But I hate the code implications for\nechoing environmental variables that git cares about. Especially\nsince we really don't care about the environmental variables. Instead\nwe are doing this because we are doing things that the are best\nnot done in shell.\n\nSo I have made the program git-var [ -l |