{"thread":{"id":"623","subject":"git-rev-list in local commit order","startedAt":"2005-05-14T21:44:06Z","lastAt":"2005-05-18T05:16:58Z","messageCount":17,"participants":["Sean","Thomas Gleixner","Linus Torvalds","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3334","messageId":"4127.10.10.10.24.1116107046.squirrel@linux1","threadId":"623","inReplyTo":null,"subject":"git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-14T21:44:06Z","receivedAt":"2005-05-14T21:44:06Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"Attached is a preliminary hackish patch to sort git-rev-list in local\ncommit order.   While I don't know how useful this really is, it's\npresented as an alternative to the repo-id proposal.  This will work even\nif the branch happens to be from a single repository, where repo-id will\nnot.  However, shared commit objects can cause problems so for best\nresults use private commit objects for each repository.\n\nFor purposes of testing, this patch changes the Cogito default of linking\nobjects to copying, for local repository pull operations.   This patch\nwill work with _existing_ repositories where local commit times have been\nmaintained.\n\nAlso attached, is a little test script that demonstrates the local commit\ntime order.  After running the test script, you can use the cg-log command\nin each of the M and R directories to see the difference even though the\ntwo repositories share a head commit.\n\nThis patch is not nearly ready for inclusion anywhere just meant for\ncomment.  It is based off Petr's cogito tree (commit\nfa6e9eb368e949e78c4e66217461cf624b52b0a2).\n\n cache.h     |    1\n cg-pull     |    4 -\n commit.c    |  121\n+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n commit.h    |    6 ++\n rev-list.c  |    2\n sha1_file.c |    8 +++\n 6 files changed, 137 insertions(+), 5 deletions(-)\n\nSean\n\n\n\nIndex: cache.h\n===================================================================\n--- a/cache.h  (mode:100644)\n+++ b/cache.h  (mode:100644)\n@@ -157,6 +157,7 @@\n extern int write_sha1_from_fd(const unsigned char *sha1, int fd);\n \n extern int has_sha1_file(const unsigned char *sha1);\n+extern unsigned long sha1_local_date(const unsigned char *sha1);\n \n /* Convert to/from hex/sha1 representation */\n extern int get_sha1(const char *str, unsigned char *sha1);\nIndex: cg-pull\n===================================================================\n--- a/cg-pull  (mode:100755)\n+++ b/cg-pull  (mode:100755)\n@@ -143,7 +143,7 @@\n \t[ \"$1\" = \"-i\" ] && shift\n \t[ \"$1\" = \"-s\" ] && shift\n \n-\tcp_flags_l=\"-va\"\n+\tcp_flags_l=\"-vdR\"\n \tif [ \"$1\" = \"-u\" ]; then\n \t\tcp_flags_l=\"$cp_flags_l -lu\"\n \t\tshift\n@@ -163,7 +163,7 @@\n }\n \n pull_local () {\n-\tgit-local-pull -a -l -v \"$(cat \"$_git/refs/heads/$1\")\" \"$2\"\n+\tgit-local-pull -a -v \"$(cat \"$_git/refs/heads/$1\")\" \"$2\"\n }\n \n if echo \"$uri\" | grep -q \"^http://\"; then\nIndex: commit.c\n===================================================================\n--- a/commit.c  (mode:100644)\n+++ b/commit.c  (mode:100644)\n@@ -2,6 +2,7 @@\n #include \"cache.h\"\n #include <string.h>\n #include <limits.h>\n+#include <stdlib.h>\n \n const char *commit_type = \"commit\";\n \n@@ -13,6 +14,7 @@\n \t\tmemset(ret, 0, sizeof(struct commit));\n \t\tcreated_object(sha1, &ret->object);\n \t\tret->object.type = commit_type;\n+\t\tret->local_date = sha1_local_date(sha1);\n \t\treturn ret;\n \t}\n \tif (obj->type != commit_type) {\n@@ -41,6 +43,18 @@\n \treturn date;\n }\n \n+static void insert_by_local_date(struct commit_list **list, struct commit *item)\n+{\n+\tstruct commit_list **pp = list;\n+\tstruct commit_list *p;\n+\twhile ((p = *pp) != NULL) {\n+\t\tif (p->item->local_date > item->local_date) \n+\t\t\tbreak;\n+\t\tpp = &p->next;\n+\t}\n+\tcommit_list_insert(item, pp);\n+}\n+\n int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)\n {\n \tvoid *bufptr = buffer;\n@@ -58,12 +72,13 @@\n \t       !get_sha1_hex(bufptr + 7, parent)) {\n \t\tstruct commit *new_parent = lookup_commit(parent);\n \t\tif (new_parent) {\n-\t\t\tcommit_list_insert(new_parent, &item->parents);\n+ \t\t\tinsert_by_local_date(&item->parents, new_parent);\n \t\t\tadd_ref(&item->object, &new_parent->object);\n \t\t}\n \t\tbufptr += 48;\n \t}\n \titem->date = parse_commit_date(bufptr);\n+\titem->merge_nodes = NULL;\n \treturn 0;\n }\n \n@@ -152,3 +167,107 @@\n \t}\n \treturn ret;\n }\n+\n+struct commit_list *copy_commit_list(struct commit_list *list)\n+{\n+\tstruct commit_list *copy = NULL;\n+\twhile (list) {\n+\t\tcommit_list_insert(list->item, &copy); \n+\t\tlist = list->next;\n+\t}\n+\treturn copy;\n+}\n+\n+int found_on_list(struct commit *item, struct commit_list *list)\n+{\n+\twhile (list) {\n+\t\tif (list->item == item)\n+\t\t\treturn 1;\n+\t\tlist = list->next;\n+\t}\n+\treturn 0;\n+}\n+\n+static struct commit *process_local_list(struct commit_list **list_p, \n+\t\t\t\t\tint this_mark, int other_mark)\n+{\n+\tstruct commit *item = (*list_p)->item;\n+\n+\tif (item->object.flags & other_mark) {\n+\t\treturn item;\n+\t} else {\n+\t\tpop_most_recent_commit(list_p, this_mark);\n+\t}\n+\treturn NULL;\n+}\n+\n+struct commit *common_local_ancestor(struct commit *rev1, struct commit *rev2)\n+{\n+\tstruct commit_list *rev1list = NULL;\n+\tstruct commit_list *rev2list = NULL;\n+\n+\tcommit_list_insert(rev1, &rev1list); rev1->object.flags |= 0x1;\n+\tcommit_list_insert(rev2, &rev2list); rev2->object.flags |= 0x2;\n+\tparse_commit(rev1); parse_commit(rev2);\n+\n+\twhile (rev1list || rev2list) {\n+\t\tstruct commit *ret;\n+\t\tif (!rev1list) {\n+\t\t\t// process 2\n+\t\t\tret = process_local_list(&rev2list, 0x2, 0x1);\n+\t\t} else if (!rev2list) {\n+\t\t\t// process 1\n+\t\t\tret = process_local_list(&rev1list, 0x1, 0x2);\n+\t\t} else if (rev1list->item->local_date \n+\t\t\t\t< rev2list->item->local_date) {\n+\t\t\t// process 2\n+\t\t\tret = process_local_list(&rev2list, 0x2, 0x1);\n+\t\t} else {\n+\t\t\t// process 1\n+\t\t\tret = process_local_list(&rev1list, 0x1, 0x2);\n+\t\t}\n+\t\tif (ret) {\n+\t\t\tfree_commit_list(rev1list);\n+\t\t\tfree_commit_list(rev2list);\n+\t\t\treturn ret;\n+\t\t}\n+\t}\n+\treturn NULL;\n+}\n+\n+void insert_merge_nodes(struct commit_list *plist,\n+\t\t\tstruct commit_list *stop,\n+\t\t\tstruct commit *node)\n+{\n+\tstruct commit_list *p;\n+\tfor (p=plist; p != stop; p=p->next)\n+\t\tcommit_list_insert(\tcommon_local_ancestor(node, p->item),\n+\t\t\t\t\t&node->merge_nodes);\n+}\n+\n+struct commit *pop_newest_local_commit(\tstruct commit_list **list,\n+\t\t\t\t\tunsigned int mark)\n+{\n+\tstruct commit *ret = (*list)->item;\n+\tstruct commit_list *parents = ret->parents;\n+\tstruct commit_list *old = *list;\n+\tstruct commit_list *prev = ret->merge_nodes;\n+\n+\t*list = (*list)->next;\n+\tfree(old);\n+\n+\t/* Loop expects parents to be ordered oldest to newest on local time */\n+\twhile (parents) {\n+\t\tstruct commit *commit = parents->item;\n+\t\tparse_commit(commit);\n+\t\tif (!((commit->object.flags & mark) | \n+                       found_on_list(commit, ret->merge_nodes))) {\n+\t\t\tcommit->object.flags |= mark;\n+\t\t\tprev = commit->merge_nodes = copy_commit_list(prev);\n+\t\t\tinsert_merge_nodes(ret->parents, parents, commit);\n+\t\t\tcommit_list_insert(commit, list);\n+\t\t}\n+\t\tparents = parents->next;\n+\t}\n+\treturn ret;\n+}\nIndex: commit.h\n===================================================================\n--- a/commit.h  (mode:100644)\n+++ b/commit.h  (mode:100644)\n@@ -11,8 +11,9 @@\n \n struct commit {\n \tstruct object object;\n-\tunsigned long date;\n+\tunsigned long date, local_date;\n \tstruct commit_list *parents;\n+\tstruct commit_list *merge_nodes;\n \tstruct tree *tree;\n };\n \n@@ -36,4 +37,7 @@\n struct commit *pop_most_recent_commit(struct commit_list **list, \n \t\t\t\t      unsigned int mark);\n \n+struct commit *pop_newest_local_commit(\tstruct commit_list **list,\n+\t\t\t\t\tunsigned int mark);\n+\n #endif /* COMMIT_H */\nIndex: rev-list.c\n===================================================================\n--- a/rev-list.c  (mode:100644)\n+++ b/rev-list.c  (mode:100644)\n@@ -38,7 +38,7 @@\n \n \tcommit_list_insert(commit, &list);\n \tdo {\n-\t\tstruct commit *commit = pop_most_recent_commit(&list, 0x1);\n+\t\tstruct commit *commit = pop_newest_local_commit(&list, 0x4);\n \n \t\tif (min_age != -1 && (commit->date > min_age))\n \t\t\tcontinue;\nIndex: sha1_file.c\n===================================================================\n--- a/sha1_file.c  (mode:100644)\n+++ b/sha1_file.c  (mode:100644)\n@@ -577,6 +577,14 @@\n \treturn !!find_sha1_file(sha1, &st);\n }\n \n+unsigned long sha1_local_date(const unsigned char *sha1)\n+{\n+\tstruct stat st;\n+\tif (find_sha1_file(sha1, &st))\n+\t\treturn st.st_mtime;\n+\treturn 0;\n+}\n+\n int index_fd(unsigned char *sha1, int fd, struct stat *st)\n {\n \tunsigned long size = st->st_size;\n"},{"id":"3378","messageId":"1116186533.11872.152.camel@tglx","threadId":"623","inReplyTo":"4127.10.10.10.24.1116107046.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-15T19:48:53Z","receivedAt":"2005-05-15T19:48:53Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:\n> Attached is a preliminary hackish patch to sort git-rev-list in local\n> commit order. \n\n+unsigned long sha1_local_date(const unsigned char *sha1)\n+{\n+       struct stat st;\n+       if (find_sha1_file(sha1, &st))\n+               return st.st_mtime;\n+       return 0;\n+}\n\nDo you really want to base workflow and history information on file\ntimes ?\n\n\nFile times are local and completely error prone in distributed\nenvironments. \n\n\ntglx\n\n\n"},{"id":"3380","messageId":"4971.10.10.10.24.1116187076.squirrel@linux1","threadId":"623","inReplyTo":"1116186533.11872.152.camel@tglx","subject":"Re: git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-15T19:57:56Z","receivedAt":"2005-05-15T19:57:56Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, May 15, 2005 3:48 pm, Thomas Gleixner said:\n> On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:\n>> Attached is a preliminary hackish patch to sort git-rev-list in local\n>> commit order.\n>\n> +unsigned long sha1_local_date(const unsigned char *sha1)\n> +{\n> +       struct stat st;\n> +       if (find_sha1_file(sha1, &st))\n> +               return st.st_mtime;\n> +       return 0;\n> +}\n>\n> Do you really want to base workflow and history information on file\n> times ?\n\nThe local commit order just isn't all that important in many situations. \nAnd for situations where it is important, this proposal seems completely\nadequate.   Mind you, the patch in question is complete crap.\n\n> File times are local and completely error prone in distributed\n> environments.\n\nI disagree that they're inherently error prone, steps can be taken to make\nthem as secure as you desire.  Also, many people just will not care about\nthis local-commit-time as they will simply be tracking a remote\nrepository.   For applications like David Woodhouse's need to present the\nnewest commits first on a web page, this is _completely_ adequate.   I've\nyet to see an intended use for this information that isn't completely\nhandled by this proposal.  Afterall, most people using git are getting by\njust fine without such a facility today.\n\nRegards,\nSean\n\n\n"},{"id":"3386","messageId":"1116189873.11872.171.camel@tglx","threadId":"623","inReplyTo":"4971.10.10.10.24.1116187076.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-15T20:44:33Z","receivedAt":"2005-05-15T20:44:33Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Sun, 2005-05-15 at 15:57 -0400, Sean wrote:\n> Afterall, most people using git are getting by\n> just fine without such a facility today.\n\n\nAxiom 1:\nSean knows exactly what people care about\n\nAxiom 2:\nTime is a reliable source of information.\n\nAxiom 3:\nAll information except X can be derived from time.\n\nAxiom 4:\nMost people dont care about X, therefor X is irrelevant.\n\nAxiom 5:\nIf doubts, see Axiom 1\n\ntglx\n\n\n"},{"id":"3387","messageId":"1102.10.10.10.24.1116189916.squirrel@linux1","threadId":"623","inReplyTo":"1116189873.11872.171.camel@tglx","subject":"Re: git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-15T20:45:16Z","receivedAt":"2005-05-15T20:45:16Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, May 15, 2005 4:44 pm, Thomas Gleixner said:\n> On Sun, 2005-05-15 at 15:57 -0400, Sean wrote:\n>> Afterall, most people using git are getting by\n>> just fine without such a facility today.\n>\n> Axiom 1:\n> Sean knows exactly what people care about\n>\n> Axiom 2:\n> Time is a reliable source of information.\n>\n> Axiom 3:\n> All information except X can be derived from time.\n>\n> Axiom 4:\n> Most people dont care about X, therefor X is irrelevant.\n>\n> Axiom 5:\n> If doubts, see Axiom 1\n>\n\nThomas,\n\nYou can continue the personal attacks or you can simply explain to the\nlist what you are trying to accomplish and why it is important and why any\nother proposal besides yours isn't worthy.\n\nSean\n\n\n\n"},{"id":"3388","messageId":"1116191636.11872.195.camel@tglx","threadId":"623","inReplyTo":"1102.10.10.10.24.1116189916.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-15T21:13:56Z","receivedAt":"2005-05-15T21:13:56Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Sun, 2005-05-15 at 16:45 -0400, Sean wrote:\n\n> You can continue the personal attacks or you can simply explain to the\n> list what you are trying to accomplish and why it is important and why any\n> other proposal besides yours isn't worthy.\n\nI did never say, that my proposal is the world formula, but I have more\nthan once explained, why time is the worst source of information.\n\nYou keep beating on time as a reliable source of information and tell me\nthat most people are completely happy with it. You must have access to a\nquite good opinion survey.\n\n\nTime of files or time in commit blobs is not a reliable information to\nkeep track of\n - workflows\n - history\nThats all I'm talking about and it is the concern of others too.\n\nIn \"git\" repositories the only reliable source of information is the\nparent child relationship. This information is only partially reliable\ndue to the head forward scenario. I think we agreed on this, right ?\nYou have no other reliable source of information due to the fact that\ncommitter names are not unique.\n\n> I disagree that they're inherently error prone, \n> steps can be taken to make them as secure as you desire.\n\nYou continue to propose stuff which is not viable. Can you enforce \n- NTP syncronisation\n- the correct usage of rsync options \n- timestamp aware backups \n\nNo, you can't.\n\nWhy did the mail people resort to \"In-Reply-To\", \"Message-ID\" and\n\"References\" ? Because time turned out to be an inreliable source of\ninformation. Please read the related discussions before you argue that\ntime based solutions are sufficient.\n\nTime is illusion. \n\n\ntglx\n\n\n\n"},{"id":"3391","messageId":"1273.10.10.10.24.1116192097.squirrel@linux1","threadId":"623","inReplyTo":"1116191636.11872.195.camel@tglx","subject":"Re: git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-15T21:21:37Z","receivedAt":"2005-05-15T21:21:37Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, May 15, 2005 5:13 pm, Thomas Gleixner said:\n> On Sun, 2005-05-15 at 16:45 -0400, Sean wrote:\n>\n>> You can continue the personal attacks or you can simply explain to the\n>> list what you are trying to accomplish and why it is important and why\n>> any\n>> other proposal besides yours isn't worthy.\n>\n> I did never say, that my proposal is the world formula, but I have more\n> than once explained, why time is the worst source of information.\n>\n> You keep beating on time as a reliable source of information and tell me\n> that most people are completely happy with it. You must have access to a\n> quite good opinion survey.\n>\n> Time of files or time in commit blobs is not a reliable information to\n> keep track of\n>  - workflows\n>  - history\n> Thats all I'm talking about and it is the concern of others too.\n>\n> In \"git\" repositories the only reliable source of information is the\n> parent child relationship. This information is only partially reliable\n> due to the head forward scenario. I think we agreed on this, right ?\n> You have no other reliable source of information due to the fact that\n> committer names are not unique.\n>\n>> I disagree that they're inherently error prone,\n>> steps can be taken to make them as secure as you desire.\n>\n> You continue to propose stuff which is not viable. Can you enforce\n> - NTP syncronisation\n> - the correct usage of rsync options\n> - timestamp aware backups\n>\n> No, you can't.\n>\n> Why did the mail people resort to \"In-Reply-To\", \"Message-ID\" and\n> \"References\" ? Because time turned out to be an inreliable source of\n> information. Please read the related discussions before you argue that\n> time based solutions are sufficient.\n>\n> Time is illusion.\n\nWhat you're missing is that time is only important in this case to deduce\nthe relative age of each commit LOCALLY.   The intention of this proposal\nis not to allow time comparison of commits between repositories.  In fact,\nyou'll see if you look closely, that you don't need to do that in order to\nsolve the stated problem of sorting the commits by the time they were\nmerged LOCALLY.\n\nCheers,\nSean\n\n\n"},{"id":"3396","messageId":"1116192629.11872.201.camel@tglx","threadId":"623","inReplyTo":"1273.10.10.10.24.1116192097.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-15T21:30:29Z","receivedAt":"2005-05-15T21:30:29Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Sun, 2005-05-15 at 17:21 -0400, Sean wrote:\n> > Time is illusion.\n> \n> What you're missing is that time is only important in this case to deduce\n> the relative age of each commit LOCALLY.   The intention of this proposal\n> is not to allow time comparison of commits between repositories. \n\n\nI do not want to compare times. I want to figure out workflows and\nhistories between different repositories.\n\n>  In fact,\n> you'll see if you look closely, that you don't need to do that in order to\n> solve the stated problem of sorting the commits by the time they were\n> merged LOCALLY.\n\nEven LOCALLY is no guarantee for correct timestamps.\n\n\ntglx\n\n\n"},{"id":"3398","messageId":"1392.10.10.10.24.1116193437.squirrel@linux1","threadId":"623","inReplyTo":"1116192629.11872.201.camel@tglx","subject":"Re: git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-15T21:43:57Z","receivedAt":"2005-05-15T21:43:57Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, May 15, 2005 5:30 pm, Thomas Gleixner said:\n> On Sun, 2005-05-15 at 17:21 -0400, Sean wrote:\n>> > Time is illusion.\n>>\n>> What you're missing is that time is only important in this case to\n>> deduce\n>> the relative age of each commit LOCALLY.   The intention of this\n>> proposal\n>> is not to allow time comparison of commits between repositories.\n>\n> I do not want to compare times. I want to figure out workflows and\n> histories between different repositories.\n\nWell I honestly don't know what you want.   If I wanted to include a\n\"fortune\" line in every commit and couldn't explain what value it\nprovided, i'd expect you or others to object.\n\nMy time based proposal solves the issue of :\n\nRn------\\\nRn-1    Mn\nRn-2    Mn-1\nRn-3 ---/\nInitial\n\nShowing up in two repositories sorted based on the order they were\ncommitted locally.  This was an issue that you stated you were trying to\nsolve.  The test case works just as advertised.  Remote times don't\nmatter, all that matters is the time you merge the objects locally.\n\n> Even LOCALLY is no guarantee for correct timestamps.\n\nSure, but then your repoid might have gone missing or be set incorrectly\ntoo.   One nice thing if your time is wrong, you can simply reset the\ntimestamp on the file.   If your repo-id is wrong, you have to recast the\ncommit object which will get a different SHA1 number and make things more\ndifficult.\n\nSean\n\n\n"},{"id":"3401","messageId":"1116195235.11872.213.camel@tglx","threadId":"623","inReplyTo":"1392.10.10.10.24.1116193437.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-15T22:13:55Z","receivedAt":"2005-05-15T22:13:55Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Sun, 2005-05-15 at 17:43 -0400, Sean wrote:\n\n> Well I honestly don't know what you want.   If I wanted to include a\n> \"fortune\" line in every commit and couldn't explain what value it\n> provided, i'd expect you or others to object.\n\nLast try.\n\nA repository Id makes it possible to identify workflows in and across\nrepositories. \n\nThis information is valuable for me and others due to already discussed\nreasons. \n\nI accept that is irrelevant for you.\n\ntglx\n\n\n"},{"id":"3417","messageId":"1629.10.10.10.24.1116278725.squirrel@linux1","threadId":"623","inReplyTo":"1116195235.11872.213.camel@tglx","subject":"Re: git-rev-list in local commit order","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-16T21:25:25Z","receivedAt":"2005-05-16T21:25:25Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, May 15, 2005 6:13 pm, Thomas Gleixner said:\n> Last try.\n>\n> A repository Id makes it possible to identify workflows in and across\n> repositories.\n\nSorry, your proposal falls short, accurate work flow would allow you to\nshow every repository a commit passed through on the way to its final\ndestination.  Your proposal does not allow that; as discussed.  Nor does\nit handle multiple projects or branches within a single repository.\n\nAs noted by others, using git often means the creation of temporary\nrepositories, hardly something that deserves an identifier.  Git, by\ndesign, doesn't give a hoot about individual repositories.\n\nAnd you also haven't addressed what to do when someone else uses say,\nLinus' repoid, as their own.  It seems like a risk to have the operation\nof each repository depend on a value anyone else can duplicate.  Linus\ncan't control what repoid everyone else uses, he can control the time on\nhis own machine.  Unique repoid's are an illusion.\n\n> This information is valuable for me and others due to already discussed\n> reasons.\n\nWhy should everyone else manage repoids in their own personal repository\nfor you; what value will _they_ get out of it?\n\n> I accept that is irrelevant for you.\n\nPersonally I don't really care either way.  But you haven't given one real\nexample where it is actually needed to do useful work.  Making pretty\ngraphs on a web page doesn't count if they're not useful to anyone.  You\nshouldn't force everyone else to manage repoid's unless there is some\nvalue for _them_.\n\nIf you're still going to pursue this, at least make sure repoid is not\nmandatory.  If a local repository identifier isn't defined, don't create a\nrepoid line in the commits.\n\nSean\n\n\n"},{"id":"3435","messageId":"Pine.LNX.4.58.0505161638090.18337@ppc970.osdl.org","threadId":"623","inReplyTo":"1629.10.10.10.24.1116278725.squirrel@linux1","subject":"Re: git-rev-list in local commit order","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-16T23:46:50Z","receivedAt":"2005-05-16T23:46:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 16 May 2005, Sean wrote:\n> \n> And you also haven't addressed what to do when someone else uses say,\n> Linus' repoid, as their own.  It seems like a risk to have the operation\n> of each repository depend on a value anyone else can duplicate.  Linus\n> can't control what repoid everyone else uses, he can control the time on\n> his own machine.  Unique repoid's are an illusion.\n\nYes. I'm not ahuge fan of the notion of \"repo ID's\". One reason is that I\nactually really really like the notion of anonymous repositories, so that\nwhen I do something stupid, and blow away one of my less successful\nrepositories and continue with another one, nobody ever sees it (and yes,\nthis happens - in my BK usage I occasionally cloned my repo for some\ntesting, and then ended up using the _cloned_ repo for the real work, and\ntotally blowing away ymy original one, and renamed my cloned one back to\nwhere my main one is).\n\nThat said, while I actually think that time/date matters, I don't think it \nshould matter a lot.\n\nI don't see why people don't just use the \"committer\" name for this.  \nThat's really what you want, and it ends up being a very good\napproximation of \"repository ID\" for a commit. Sure, people end up having\nmultiple reposiories, and thus you'll occasionally see merges that end up\nmerging two heads with the same \"repo ID\", but does anybody really care? I\ndoubt it.\n\nFor example, if you have a company Q&A policy that says that you want to \nkeep commits to different repos separate, just make sure that those repos \nare on different machines or are accessed with different users. Or write \nsome simple wrapper scripts that make sure to set GIT_COMMITTER_EMAIL to \nthe proper value (say, the wrapper could be as simple as\n\n\t#!/bin/sh\n\texport GIT_COMMITTER_EMAIL=$(cat .git/committer_email)\n\treal-git-commit \"$@\"\n\nand then you just create a \".git/committer_email\" file per repository that \ncontains the \"repo ID\" you want to fake.\n\n\t\tLinus\n"},{"id":"3443","messageId":"1116323520.17296.12.camel@tglx.tec.linutronix.de","threadId":"623","inReplyTo":"Pine.LNX.4.58.0505161638090.18337@ppc970.osdl.org","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-17T09:52:00Z","receivedAt":"2005-05-17T09:52:00Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Mon, 2005-05-16 at 16:46 -0700, Linus Torvalds wrote:\n> Yes. I'm not ahuge fan of the notion of \"repo ID's\". One reason is that I\n> actually really really like the notion of anonymous repositories, so that\n> when I do something stupid, and blow away one of my less successful\n> repositories and continue with another one, nobody ever sees it (and yes,\n> this happens - in my BK usage I occasionally cloned my repo for some\n> testing, and then ended up using the _cloned_ repo for the real work, and\n> totally blowing away ymy original one, and renamed my cloned one back to\n> where my main one is).\n\nWhat you blow away is a work space. But at the end you push the result\nof whatever work space you kept into a public available repository. Also\nBK stores a somewhat hidden repository (not workspace) id.\n\nMy idea of repository id was not the notion of workspace seperation. I\ndont care in which directory and on which machine you or who ever\ncommits a line of code. I care where the change appears in a public\nrepository, which is unique.\n\n> I don't see why people don't just use the \"committer\" name for this.  \n> That's really what you want, and it ends up being a very good\n> approximation of \"repository ID\" for a commit. Sure, people end up having\n> multiple reposiories, and thus you'll occasionally see merges that end up\n> merging two heads with the same \"repo ID\", but does anybody really care? I\n> doubt it.\n\nI came up with this after I started \"git tracker\" and David Woodhouse\nasked me to make it possible to look at the history of his repository\nfrom the repositiory POV rather than from the cloned global history of\ntorvalds/linux-2.6.git. \n\nSure I have retrieved the information from committer name and committer\nmail, but when I tried to do the same with Dave Millers and Gregs\nrepositories it turned out to be impossible as they use the same\nname/mail for each of their repositories.\n\n> For example, if you have a company Q&A policy that says that you want to \n> keep commits to different repos separate, just make sure that those repos \n> are on different machines or are accessed with different users. Or write \n> some simple wrapper scripts that make sure to set GIT_COMMITTER_EMAIL to \n> the proper value (say, the wrapper could be as simple as\n> \n> \t#!/bin/sh\n> \texport GIT_COMMITTER_EMAIL=$(cat .git/committer_email)\n> \treal-git-commit \"$@\"\n> \n> and then you just create a \".git/committer_email\" file per repository that \n> contains the \"repo ID\" you want to fake.\n\nMight be a workable solution. I would prefer if this would be a part of\nthe core plumbing.\nWould you accept a patch for commit-tree which tries to check this file\nfor existance and use the content in case its there?\n\ntglx\n\n\n"},{"id":"3448","messageId":"Pine.LNX.4.58.0505170833330.18337@ppc970.osdl.org","threadId":"623","inReplyTo":"1116323520.17296.12.camel@tglx.tec.linutronix.de","subject":"Re: git-rev-list in local commit order","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-17T15:43:12Z","receivedAt":"2005-05-17T15:43:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 May 2005, Thomas Gleixner wrote:\n> \n> What you blow away is a work space. But at the end you push the result\n> of whatever work space you kept into a public available repository. Also\n> BK stores a somewhat hidden repository (not workspace) id.\n\nNo.\n\nThe public repo is secondary. Really. It has no meaning. The only thing \nthat matters is what you call \"workspace\".\n\n> My idea of repository id was not the notion of workspace seperation. I\n> dont care in which directory and on which machine you or who ever\n> commits a line of code. I care where the change appears in a public\n> repository, which is unique.\n\nYou seem to think that the repository on master.kernel.org is more \nimportant than the one on my private machine, and you're _wrong_.\n\nIt's the _private_ repositories that are the important ones. The public \nones are a communication channel, nothing more. They have no importance on \ntheir own.\n\nI've blown the public one away several times. With BK, we've had disk\ncorruption on kernel.org, we've had break-ins on bkbits.net, and we've had\nrepository corruption due to people editing the SCCS files by hand. Any\nnumber of silly problems, in other words. The result? Blow the public tree\naway, restore it from one of the private ones from a machine that you\ntrust.\n\nI _never_ look at my public tree. I literally have a small script called \n\"push-all\" in my git repositories, and it does:\n\n\t#!/bin/sh\n\techo master.kernel.org:\n\trsync -av --delete --exclude-from=.exclude .git/ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\t...\n\nie it just pushes my stuff to a few other places.\n\nIn other words, the public stuff is the _slave_. It has no meaning. The \nonly important one is the one that the _developer_ works on.\n\nOf course, this is not to say that everybody needs to take my approach.\nThe nice thing about distributed systems is that a centralized system is\njust a trivial special case of them, so somebody else, who uses git as if\nit were CVS, could say \"repo xxxx at git-master:/pub/git-root/project is\nthe 'main' repository, and all the workspaces are just temporary\nworkspaces\".\n\nBut from a git _design_ point (and from a kernel usage point), the belief\nthat a \"workspace\" is somehow less important than a \"central repository\"\nis just very very very wrong. Each workspace is it's own repository, and \nit's the _local_ ones that matter, not some \"central repository\".\n\n\t\tLinus\n"},{"id":"3452","messageId":"1116349507.17296.31.camel@tglx.tec.linutronix.de","threadId":"623","inReplyTo":"Pine.LNX.4.58.0505170833330.18337@ppc970.osdl.org","subject":"Re: git-rev-list in local commit order","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2005-05-17T17:05:07Z","receivedAt":"2005-05-17T17:05:07Z","isPatch":false,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Tue, 2005-05-17 at 08:43 -0700, Linus Torvalds wrote:\n> > My idea of repository id was not the notion of workspace seperation. I\n> > dont care in which directory and on which machine you or who ever\n> > commits a line of code. I care where the change appears in a public\n> > repository, which is unique.\n> \n> You seem to think that the repository on master.kernel.org is more \n> important than the one on my private machine, and you're _wrong_.\n\nFor me yes, as I have no access to your private ones and I can only rely\non the integrity of the public accessible ones.\n\nFor the individual developer the private workspaces are surely more\nimportant. I never doubted that, but I do not care whether you use one\nor ten workspaces and which one of them you blow away or use for\nupdating of master.kernel.org. \n\ntglx\n\n\n"},{"id":"3453","messageId":"Pine.LNX.4.58.0505171035570.18337@ppc970.osdl.org","threadId":"623","inReplyTo":"1116349507.17296.31.camel@tglx.tec.linutronix.de","subject":"Re: git-rev-list in local commit order","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-17T17:44:12Z","receivedAt":"2005-05-17T17:44:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 May 2005, Thomas Gleixner wrote:\n>\n> On Tue, 2005-05-17 at 08:43 -0700, Linus Torvalds wrote:\n> > > My idea of repository id was not the notion of workspace seperation. I\n> > > dont care in which directory and on which machine you or who ever\n> > > commits a line of code. I care where the change appears in a public\n> > > repository, which is unique.\n> > \n> > You seem to think that the repository on master.kernel.org is more \n> > important than the one on my private machine, and you're _wrong_.\n> \n> For me yes, as I have no access to your private ones and I can only rely\n> on the integrity of the public accessible ones.\n> \n> For the individual developer the private workspaces are surely more\n> important. I never doubted that, but I do not care whether you use one\n> or ten workspaces and which one of them you blow away or use for\n> updating of master.kernel.org. \n\nBut how would you track \"repositoryness\", when the repository you care \nabout has absolutely nothing to do with the repositories that any of the \ndevelopers who created it in the first place care about?\n\nSee the problem? You can't. You seem to want to track information that\nsimply does not _exist_.\n\nPut another way: the repository ID of the eventual public \"target\"  \nrepository only becomes available once the information has been pushed\nthere, not before. So a \"commit\" cannot contain that information, because\nat commit time, you fundamentally cannot know what the eventual public\nrepository (if any) will be.\n\nSo the public repo really is nothing but a shadow of the real work, and \nthe only reliable ordering you can do will have to depend on local \ninformation (ie things like the committer \"email\" value).\n\nNow, what you _can_ do (and what the snapshot mechanism and the commit \nmailing list scripts do) is to create a \"publicly visible timeline\" thing, \nie you can at regular intervals generate a snapshot of \"what is the state \nof public repo X\" and you'll get a \"local commit ordering\" from that.\n\nBut that local commit ordering will fundamentally depend on exactly when\nand how often you do the snapshotting and when I (or somebody else)\nhappened to push to that public repo, so it will inevitably be something\nyou can never re-create later from just the final repository contents.  \nIOW, it's not something that \"git-rev-list\" can re-create - the only way\nto recreate it is literally to build up a separate list of \"what was the\nhead commit at time X\" outside of the repository.\n\n\t\tLinus\n"},{"id":"3488","messageId":"2cfc403205051722163296144@mail.gmail.com","threadId":"623","inReplyTo":"Pine.LNX.4.58.0505171035570.18337@ppc970.osdl.org","subject":"Re: git-rev-list in local commit order","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-18T05:16:58Z","receivedAt":"2005-05-18T05:16:58Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/18/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> \n> \n> On Tue, 17 May 2005, Thomas Gleixner wrote:\n> >\n> > On Tue, 2005-05-17 at 08:43 -0700, Linus Torvalds wrote:\n> > > > My idea of repository id was not the notion of workspace seperation. I\n> > > > dont care in which directory and on which machine you or who ever\n> > > > commits a line of code. I care where the change appears in a public\n> > > > repository, which is unique.\n> > >\n> > > You seem to think that the repository on master.kernel.org is more\n> > > important than the one on my private machine, and you're _wrong_.\n> >\n> > For me yes, as I have no access to your private ones and I can only rely\n> > on the integrity of the public accessible ones.\n> >\n> > For the individual developer the private workspaces are surely more\n> > important. I never doubted that, but I do not care whether you use one\n> > or ten workspaces and which one of them you blow away or use for\n> > updating of master.kernel.org.\n> \n> But how would you track \"repositoryness\", when the repository you care\n> about has absolutely nothing to do with the repositories that any of the\n> developers who created it in the first place care about?\n> \n> See the problem? You can't. You seem to want to track information that\n> simply does not _exist_.\n> \n> Put another way: the repository ID of the eventual public \"target\"\n> repository only becomes available once the information has been pushed\n> there, not before. So a \"commit\" cannot contain that information, because\n> at commit time, you fundamentally cannot know what the eventual public\n> repository (if any) will be.\n\nEarlier in a related thread, I argued that what everyone else has been\ncalling a repo-id is actually a workspace id. Your GIT_COMMITER_EMAIL\nidea would have the same practical effect as a separate workspace id,\nthough it does pollute the interpretation of the e-mail id's since\nthey are no longer pure e-mail id's...\n\nWould you be amenable to a patch that allowed tools to put attributes\nof the form:\n\n   x-\"some-attribute\" (' ' [^\\0]*)+ '\\0'\n\ninto a commit header?\n\nIf, over time, x-\"some-attribute\" became unversially accepted as\nuseful, a new release of git could bless it as official and the 'x-'\nprefix could be dropped.\n\nIn the meantime, tools could experiment with additional commit markers\nas they see fit without affecting the interoperability of other tools\nwhich use only the blessed markers.\n\nOf course, a constraint on the semantics of an x-* attribute would\nideally be that it's value must be fixed for all time once the commit\nhappens since there is no way to change it without creating a new\ncommit.\n\njon.\n"}]}