{"thread":{"id":"3962","subject":"[PATCH 1/5] add 'prior' link in commit structure","startedAt":"2006-04-25T03:54:21Z","lastAt":"2006-04-29T14:59:12Z","messageCount":63,"participants":["Sam Vilain","Junio C Hamano","Jakub Narebski","sean","Linus Torvalds","Jason Riedy","Andreas Ericsson"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"19075","messageId":"20060425035421.18382.51677.stgit@localhost.localdomain","threadId":"3962","inReplyTo":null,"subject":"[RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T03:54:21Z","receivedAt":"2006-04-25T03:54:21Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"This patch series implements \"prior\" links in commit objects. A\n'prior' link on a commit represents its historical precedent, as\nopposed to the previous commit(s) that this commit builds upon.\n\nThis is a proof of concept only; there is an outstanding bug (I put\nthe prior header right after parent, when it should really go after\nauthor/committer), and room for improvement no doubt remain elsewhere.\nNot to mention my shocking C coding style ;)\n\nExamples of use cases this helps:\n\n 1. heads that represent topic branch merges\n\n This is the \"pu\" branch case, where the head is a merge of several\n topic branches that is continually moved forward.\n\n topic branches head\n ,___. ,___.\n | TA1 | | TB1 |\n `---' `---' ,__.\n ^\\_____^\\____| H1 |\n `--'\n\n + some topic branch changes and a republish:\n\n ,___. ,___.\n | TA1 | | TB1 |\n `---' `---'^ ,__.\n |^\\_____^\\____| H1 |\n | | `--'\n ,_|_. ,_|_. P\n | TA2 | | TB2 | |\n `---' `---'^ |\n ^ ^ |\n ,_|_. | |\n | TA3 | | |\n `---' | ,__.\n ^\\______\\____| H2 |\n `--'\n\n key: ^ = parent P = prior\n\n 2. revising published commits / re-basing\n\n This is what \"stg\" et al do. The tools allow you to commit,\n rewind, revise, recommit, fast forward, etc.\n\n In this case, the \"prior\" link would point to the last revision of\n a patch. Tools would probably\n\n 3. sub-projects\n\n In this case, the commit on the \"main\" commit line would have a\n \"prior\" link to the commit on the sub-project. The sub-project\n would effectively be its own head with copied commits objects on\n the main head.\n\n 4. tracking cherry picking\n\n In this case, the \"prior\" link just points to the commit that was\n cherry picked. This is perhaps a little different, but an idea\n that somebody else had for this feature.\n\nSam.\n"},{"id":"19070","messageId":"20060425043106.18382.24344.stgit@localhost.localdomain","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"[PATCH 1/5] add 'prior' link in commit structure","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T04:31:06Z","receivedAt":"2006-04-25T04:31:06Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nAdd a space in the commit for a prior commit that forms this commit's\nhistorical, not substantial, precedent.\n\nFor now this is just recorded as a char* pointer, as it is not an\nerror condition for the commit not to be present locally.\n---\n\n commit.h | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/commit.h b/commit.h\nindex de142af..b00a6b9 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -13,6 +13,7 @@ struct commit {\n \tstruct object object;\n \tunsigned long date;\n \tstruct commit_list *parents;\n+\tchar *prior;\n \tstruct tree *tree;\n \tchar *buffer;\n };\n"},{"id":"19073","messageId":"20060425043106.18382.48165.stgit@localhost.localdomain","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"[PATCH 2/5] git-merge-base: follow 'prior' links to find merge bases","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T04:31:06Z","receivedAt":"2006-04-25T04:31:06Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nIt is possible that a good merge base may be found looking via \"prior\"\nlinks as well. We follow them where possible.\n---\n\n merge-base.c | 12 ++++++++++++\n 1 files changed, 12 insertions(+), 0 deletions(-)\n\ndiff --git a/merge-base.c b/merge-base.c\nindex 07f5ab4..ed6d18c 100644\n--- a/merge-base.c\n+++ b/merge-base.c\n@@ -207,6 +207,18 @@ static int merge_base(struct commit *rev\n \t\t\tp->object.flags |= flags;\n \t\t\tinsert_by_date(p, &list);\n \t\t}\n+\t\t/* If the commit has a \"prior\" reference, add it */\n+\t\tif (commit->prior) {\n+\t\t\tstruct commit *prior;\n+\t\t\tprior = lookup_commit_reference_gently(commit->prior, 1);\n+\t\t\tif (prior) {\n+\t\t\t\tif ((prior->object.flags & flags) != flags) {\n+\t\t\t\t\tparse_commit(prior);\n+\t\t\t\t\tprior->object.flags |= flags;\n+\t\t\t\t\tinsert_by_date(prior, &list);\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n \t}\n \n \tif (!result)\n"},{"id":"19071","messageId":"20060425043107.18382.21313.stgit@localhost.localdomain","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"[PATCH 4/5] git-commit-tree: add support for prior","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T04:31:07Z","receivedAt":"2006-04-25T04:31:07Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nAdd support in git-commit-tree for -r as well as associated\ndocumentation.\n---\n\n Documentation/git-commit-tree.txt | 6 ++++++\n commit-tree.c | 26 +++++++++++++++++++++-----\n 2 files changed, 27 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt\nindex 27b3d12..e11ba1f 100644\n--- a/Documentation/git-commit-tree.txt\n+++ b/Documentation/git-commit-tree.txt\n@@ -20,6 +20,9 @@ A commit object usually has 1 parent (a \n to 16 parents. More than one parent represents a merge of branches\n that led to them.\n \n+A commit object can have 1 prior commit. This represents the previous\n+commit that this one replaces (including history).\n+\n While a tree represents a particular directory state of a working\n directory, a commit represents that state in \"time\", and explains how\n to get there.\n@@ -38,6 +41,8 @@ OPTIONS\n -p ::\n \tEach '-p' indicates the id of a parent commit object.\n \t\n+-r ::\n+\tOne '-r' indicates the id of a prior commit object.\n \n Commit Information\n ------------------\n@@ -45,6 +50,7 @@ Commit Information\n A commit encapsulates:\n \n - all parent object ids\n+- a prior object id (optional)\n - author name, email and date\n - committer name and email and the commit time.\n \ndiff --git a/commit-tree.c b/commit-tree.c\nindex 2d86518..6660b01 100644\n--- a/commit-tree.c\n+++ b/commit-tree.c\n@@ -61,8 +61,9 @@ static void check_valid(unsigned char *s\n */\n #define MAXPARENT (16)\n static unsigned char parent_sha1[MAXPARENT][20];\n+static unsigned char prior_sha1[21] = \"\\0\";\n \n-static const char commit_tree_usage[] = \"git-commit-tree [-p ]* < changelog\";\n+static const char commit_tree_usage[] = \"git-commit-tree [-p ]* [-r ] < changelog\";\n \n static int new_parent(int idx)\n {\n@@ -99,11 +100,22 @@ int main(int argc, char **argv)\n \tfor (i = 2; i < argc; i += 2) {\n \t\tchar *a, *b;\n \t\ta = argv[i]; b = argv[i+1];\n-\t\tif (!b || strcmp(a, \"-p\") || get_sha1(b, parent_sha1[parents]))\n+\t\tif (!b)\n \t\t\tusage(commit_tree_usage);\n-\t\tcheck_valid(parent_sha1[parents], commit_type);\n-\t\tif (new_parent(parents))\n-\t\t\tparents++;\n+\t\tif (!strcmp(a, \"-p\")) {\n+\t\t\tif (get_sha1(b, parent_sha1[parents]) < 0)\n+\t\t\t\tusage(commit_tree_usage);\n+\t\t\tcheck_valid(parent_sha1[parents], commit_type);\n+\t\t\tif (new_parent(parents))\n+\t\t\t\tparents++;\n+\t\t}\n+\t\telse if (!strcmp(a, \"-r\")) {\n+\t\t\tif (strcmp(&prior_sha1, \"\") || get_sha1(b, &prior_sha1) < 0)\n+\t\t\t\tusage(commit_tree_usage);\n+\t\t}\n+\t\telse {\n+\t\t\tusage(commit_tree_usage);\n+\t\t}\n \t}\n \tif (!parents)\n \t\tfprintf(stderr, \"Committing initial tree %s\\n\", argv[1]);\n@@ -118,6 +130,10 @@ int main(int argc, char **argv)\n \t */\n \tfor (i = 0; i < parents; i++)\n \t\tadd_buffer(&buffer, &size, \"parent %s\\n\", sha1_to_hex(parent_sha1[i]));\n+\tif (strcmp(&prior_sha1, \"\")) {\n+\t\tfprintf(stderr, \"Setting prior to %s\\n\", sha1_to_hex(&prior_sha1));\n+\t\tadd_buffer(&buffer, &size, \"prior %s\\n\", sha1_to_hex(&prior_sha1));\n+\t}\n \n \t/* Person/date information */\n \tadd_buffer(&buffer, &size, \"author %s\\n\", git_author_info(1));\n"},{"id":"19072","messageId":"20060425043107.18382.34865.stgit@localhost.localdomain","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"[PATCH 5/5] git-commit: add --prior to set prior link","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T04:31:07Z","receivedAt":"2006-04-25T04:31:07Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nAdd command-line support for --prior and add a description to the\nASCIIDOC\n---\n\n Documentation/git-commit.txt | 10 ++++++++++\n git-commit.sh | 19 +++++++++++++++++--\n 2 files changed, 27 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 6f2c495..ca5073c 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,6 +10,7 @@ SYNOPSIS\n [verse]\n 'git-commit' [-a] [-s] [-v] [(-c | -C) | -F | -m ]\n \t [--no-verify] [--amend] [-e] [--author ]\n+ [-p ]\n \t [--] [[-i | -o ]...]\n \n DESCRIPTION\n@@ -106,6 +107,15 @@ but can be used to amend a merge commit.\n \tindex and the latest commit does not match on the\n \tspecified paths to avoid confusion.\n \n+-p|--prior ::\n+\tSpecify a commit that this new commit is the next version of.\n+ Use when you want a branch to supercede another branch, but\n+ with a new commit history. It is also use for sub-projects,\n+ where commits on the parent tree mirror commits in the\n+ sub-project. does not have to exist in the local\n+ repository, if it is specified as a full 40-digit hex SHA1\n+ sum. Otherwise it is parsed as a local revision.\n+\n --::\n \tDo not interpret any more arguments as options.\n \ndiff --git a/git-commit.sh b/git-commit.sh\nindex 26cd7ca..3feb60d 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -3,7 +3,7 @@ #\n # Copyright (c) 2005 Linus Torvalds\n # Copyright (c) 2006 Junio C Hamano\n \n-USAGE='[-a] [-s] [-v] [--no-verify] [-m | -F | (-C|-c) ) [--amend] [-e] [--author ] [[-i | -o] ...]'\n+USAGE='[-a] [-s] [-v] [--no-verify] [-m | -F | (-C|-c) ) [--amend] [-e] [--author ] [-p ] [[-i | -o] ...]'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n \n@@ -200,6 +200,7 @@ log_given=\n log_message=\n verify=t\n verbose=\n+prior=\n signoff=\n force_author=\n only_include_assumed=\n@@ -344,6 +345,19 @@ do\n shift\n break\n ;;\n+ -p|--p|--pr|--pri|--prio|--prior)\n+ shift\n+ prior=\"$1\"\n+ if echo $prior | perl -ne 'exit 1 unless /^[0-9a-f]{40}$/i'\n+ then\n+ prior=`echo \"$prior\" | tr '[A-Z]' '[a-z]'`\n+ else\n+\t prior=`git-rev-parse \"$prior\"`\n+\t [ -n \"$prior\" ] || exit 1\n+ fi\n+ PRIOR=\"-r $prior\"\n+ shift\n+ ;;\n -*)\n usage\n ;;\n@@ -602,6 +616,7 @@ then\n \t\tPARENTS=$(git-cat-file commit HEAD |\n \t\t\tsed -n -e '/^$/q' -e 's/^parent /-p /p')\n \tfi\n+\t\n \tcurrent=$(git-rev-parse --verify HEAD)\n else\n \tif [ -z \"$(git-ls-files)\" ]; then\n@@ -673,7 +688,7 @@ then\n \t\ttree=$(GIT_INDEX_FILE=\"$TMP_INDEX\" git-write-tree) &&\n \t\trm -f \"$TMP_INDEX\"\n \tfi &&\n-\tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&\n+\tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS $PRIOR) &&\n \tgit-update-ref HEAD $commit $current &&\n \trm -f -- \"$GIT_DIR/MERGE_HEAD\" &&\n \tif test -f \"$NEXT_INDEX\"\n"},{"id":"19074","messageId":"20060425043106.18382.7251.stgit@localhost.localdomain","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"[PATCH 3/5] commit.c: parse 'prior' link","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2006-04-25T04:31:07Z","receivedAt":"2006-04-25T04:31:07Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nParse for the 'prior' link in a commit\n---\n\n commit.c | 12 ++++++++++++\n 1 files changed, 12 insertions(+), 0 deletions(-)\n\ndiff --git a/commit.c b/commit.c\nindex 2717dd8..e4bc396 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -260,6 +260,18 @@ int parse_commit_buffer(struct commit *i\n \t\t\tn_refs++;\n \t\t}\n \t}\n+\tif (!memcmp(bufptr, \"prior \", 6)) {\n+\t\tunsigned char prior[20];\n+\t\tif (get_sha1_hex(bufptr + 6, prior) || bufptr[46] != '\\n')\n+\t\t\treturn error(\"bad prior in commit %s\", sha1_to_hex(item->object.sha1));\n+\t\tbufptr += 47;\n+\n+\t\titem->prior = xmalloc(21);\n+\t\tstrncpy(item->prior, (char*)&prior, 20);\n+\t\titem->prior[20] = '\\0';\n+\t} else {\n+\t\titem->prior = 0;\n+\t}\n \tif (graft) {\n \t\tint i;\n \t\tstruct commit *new_parent;\n"},{"id":"19076","messageId":"444DA6F0.2090401@vilain.net","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-25T04:34:56Z","receivedAt":"2006-04-25T04:34:56Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Sam Vilain wrote:\n\n> In this case, the \"prior\" link would point to the last revision of\n> a patch. Tools would probably\n> \n>\n... support only doing this for selected, \"published\" patch chains\n"},{"id":"19077","messageId":"7vwtde2q1z.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T05:16:08Z","receivedAt":"2006-04-25T05:16:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> Examples of use cases this helps:\n\nMy reaction to this patch series is that you try to cover quite\ndifferent and unrelated things, without thinking things through,\nand end up covering nothing usefully. What is missing in these\n\"use cases\" is a coherent semantics.\n\nWhat the \"prior\" means to humans and tools. And my *guess* of\nwhat they mean suggests you are trying to make it mean many\nunrelated concepts.\n\n> 1. heads that represent topic branch merges\n>\n> This is the \"pu\" branch case, where the head is a merge of several\n> topic branches that is continually moved forward.\n\nFor usage like \"pu\", the previous \"pu\" head could be recorded as\none of the parents; you do not need anything special.\n\nThe reason I do not include the previous head when I reconstruct\n\"pu\" is because I explicitly *want* to drop history -- not\nhaving to carry forward a failed experiment is what is desired\nthere. Otherwise I would manage \"pu\" just like I currently do\n\"next\" and \"master\". So this is not a justification to add\nsomething new.\n\n> 2. revising published commits / re-basing\n>\n> This is what \"stg\" et al do. The tools allow you to commit,\n> rewind, revise, recommit, fast forward, etc.\n\nstg wants to have a link to the fork-point commit. I do not\nknow if it is absolutely necessary (you might be able to figure\nit out using merge-base, I dunno).\n\n> In this case, the \"prior\" link would point to the last revision of\n> a patch. Tools would probably\n\nProbably what...???\n\n> 3. sub-projects\n>\n> In this case, the commit on the \"main\" commit line would have a\n> \"prior\" link to the commit on the sub-project. The sub-project\n> would effectively be its own head with copied commits objects on\n> the main head.\n\nYou say you can have only one \"prior\" per commit, which makes\nthis unsuitable to bind multiple subprojects into a larger\nproject (the earlier \"bind\" proposal allows zero or more).\n\nWhen you, a human, see a \"prior\" link in \"git cat-file commit\"\noutput, what does that tell you? Is it \"the previous commit\nthis thing replaces?\" Or is it a commit in a different line of\ndevelopment which is its subproject? Or is it a commit that was\ncherry-picked from a different line? How would you tell? And\nassuming you _could_ somehow tell, how would it help you to know\nit?\n\nWhen the Plumbing and the Porcelain sees a \"prior\" link, what\nshould they do? It hugely depends on what that link means. You\nhave a patch to merge-base to include the prior commit of the\ncommit in question in the ancestry chain, but that is probably\nvalid only for case 1. and perhaps 2. If the link points at a\ncommit of otherwise unrelated subproject head, you would _never_\nwant to include that in the merge-base computation. Neither the\n\"this commit was taken out of context from otherwise unrelated\nbranch\" link you envision to use for 4. I think including\n\"prior\" to ancestry list for case 1. and 2. makes some sense in\nthe merge-base example only because (1) it does not have to be any\ndifferent from an ordinary \"parent\" to begin with for case 1.,\nand (2) it points at fork-point which is sort of a merge-base\nalready.\n\nThere may be some narrower concrete use case for which you can\ndevise coherent semantics, and teach tools and humans how to\ninterpret such inter-commit relationship that are _not_\nparent-child ancestry. For example, if you have one special\nlink to point at a \"cherry-picked\" commit, rebasing _could_ take\nadvantage of it. When your side branch tip is at D, and commit\nD has \"this was cherry-picked from commit E\" note, and if you\nare rebasing your work on top of F:\n\n A---B---C---D\n /\n o---o---E---F\n\nthe tool can notice that F can reach E and carry forward only A,\nB, and C on top of F, omitting D. So having such a link might\nbe useful. But if that is what you are going to do, I do not\nthink you would want to conflate that with other inter-commit\nrelationships, such as \"previous hydra cap\".\n\nOh, and you would need an update to rev-list --objects and\nfsck-objects if you are to add any new link to commit objects.\nOtherwise fetch/push would not get the related commits prior\npoints at, and prune will happily discard them. But before even\nbothering it, you need to come up with a semantics first.\n"},{"id":"19078","messageId":"7vpsj62pxp.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"20060425043106.18382.24344.stgit@localhost.localdomain","subject":"Re: [PATCH 1/5] add 'prior' link in commit structure","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T05:18:42Z","receivedAt":"2006-04-25T05:18:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> For now this is just recorded as a char* pointer, as it is not an\n> error condition for the commit not to be present locally.\n\nObject ancestry is parsed lazily, so you should not have to do this.\nJust point at another commit if you are to have only one (I\nrecommend against it) or have another commit_list, but when you\ninstantiate you may want to have a flag in the commit object\nitself that says \"this need not exist\".\n"},{"id":"19079","messageId":"7vlktu2pvn.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"20060425043106.18382.48165.stgit@localhost.localdomain","subject":"Re: [PATCH 2/5] git-merge-base: follow 'prior' links to find merge bases","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T05:19:56Z","receivedAt":"2006-04-25T05:19:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> From: Sam Vilain \n>\n> It is possible that a good merge base may be found looking via \"prior\"\n> links as well. We follow them where possible.\n\nYou need to define what \"prior\" means before making decision\nlike that. If \"prior\" can mean cherry-picked one from unrelated\nline of development, the above reasoning does not apply.\n"},{"id":"19080","messageId":"e2kgga$d7q$1@sea.gmane.org","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T06:44:08Z","receivedAt":"2006-04-25T06:44:08Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> This patch series implements \"prior\" links in commit objects. A\n> 'prior' link on a commit represents its historical precedent, as\n> opposed to the previous commit(s) that this commit builds upon.\n> \n> This is a proof of concept only; there is an outstanding bug (I put\n> the prior header right after parent, when it should really go after\n> author/committer), and room for improvement no doubt remain elsewhere.\n> Not to mention my shocking C coding style ;)\n\nI think \"prior\" link concept is to generic and is used for quite unrelated\nthings\n\n> Examples of use cases this helps:\n> \n> 1. heads that represent topic branch merges\n> \n> This is the \"pu\" branch case, where the head is a merge of several\n> topic branches that is continually moved forward.\n> \n> topic branches head\n> ,___. ,___.\n> | TA1 | | TB1 |\n> `---' `---' ,__.\n> ^\\_____^\\____| H1 |\n> `--'\n> \n> + some topic branch changes and a republish:\n> \n> ,___. ,___.\n> | TA1 | | TB1 |\n> `---' `---'^ ,__.\n> |^\\_____^\\____| H1 |\n> | | `--'\n> ,_|_. ,_|_. P\n> | TA2 | | TB2 | |\n> `---' `---'^ |\n> ^ ^ |\n> ,_|_. | |\n> | TA3 | | |\n> `---' | ,__.\n> ^\\______\\____| H2 |\n> `--'\n> \n> key: ^ = parent P = prior\n\nThis case is clear. You want to record previous head of \"pu\"-like branch,\nbut you also want to drop the history, so you don't want to record it as\none of parents. I'm not sure if this link would be informative only, or if\nit could be usefull e.g. in merge computing.\n \n> 2. revising published commits / re-basing\n> \n> This is what \"stg\" et al do. The tools allow you to commit,\n> rewind, revise, recommit, fast forward, etc.\n> \n> In this case, the \"prior\" link would point to the last revision of\n> a patch. Tools would probably support only doing this for selected, \n> \"published\" patch chains \n\nThis case is quite different. If I understand it correctly prior either\npoints to the previous patch in patch stack, or the bottom of the\nstack/patch stack attachment point. If this cannot be computed easily, it\ncould I guess be added, but perhaps using other name for link.\n\n> 3. sub-projects\n> \n> In this case, the commit on the \"main\" commit line would have a\n> \"prior\" link to the commit on the sub-project. The sub-project\n> would effectively be its own head with copied commits objects on\n> the main head.\n>\n> 4. tracking cherry picking\n> \n> In this case, the \"prior\" link just points to the commit that was\n> cherry picked. This is perhaps a little different, but an idea\n> that somebody else had for this feature.\n\nThose two are yet another case altogether, the \"prior\" link pointing to \"the\nsame\" commit in another history line. I agree with Junio that for (3)\n\"bind\" proposal (if I understand correctly it points to tree rather than to\ncommit) is more clean way to go. As to cherry picking (and perhaps\n\"cherry-pick on steroids\" aka rebase), there is truly 0-1 relation (either\nthis link is not needed at all, or there is only one commit to link to),\nbut I don't think it should have the same name as in case (1), as this is\nvery different. And there is a problem that the link might be dangling if\nwe deleted the branch we cherry-picked commit from, or did some history\nrewrite. Perhaps \"cherry\" would be better name for this link :-)\n\nAdditionally for each of those cases we have to consider how to compute the\nlink and which commands should be modified, which commands can make use of\nthe link and should be modified, should the link be to commit, tag, tree or\nblob, what we want to do with link when pulling/pushing/cloning into\nanother repository and which commands should be modified. Not only use case\nscenarios.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19081","messageId":"7v7j5e2jv7.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2kgga$d7q$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T07:29:48Z","receivedAt":"2006-04-25T07:29:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Additionally for each of those cases we have to consider how to compute the\n> link and which commands should be modified, which commands can make use of\n> the link and should be modified, should the link be to commit, tag, tree or\n> blob, what we want to do with link when pulling/pushing/cloning into\n> another repository and which commands should be modified. Not only use case\n> scenarios.\n\nThis last paragraph is a very good suggestion. The alleged \"use\ncases\" are just laudary list of wishes, if they are not\naccompanied by descriptions on what the modified data structure\nand added attribute _means_ and how they are _used_.\n\nHere is a related but not necessarily competing idle thought.\n\nHow about an ability to \"attach\" arbitrary objects to commit\nobjects? The commit object would look like:\n\n tree 0aaa3fecff73ab428999cb9156f8abc075516abe\n parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355\n parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504\n related a0e7d36193b96f552073558acf5fcc1f10528917 key\n related 0032d548db56eac9ea09b4ba05843365f6325b85 cherrypick\n author Junio C Hamano 1145943079 -0700\n committer Junio C Hamano 1145943079 -0700\n\n Merge branch 'pb/config' into next\n\n * pb/config:\n Deprecate usage of git-var -l for getting config vars list\n git-repo-config --list support\n\nThe format of \"related\" attribute is, keyword \"related\", SP, 40-byte\nhexadecimal object name, SP, and arbitrary sequence of bytes\nexcept LF and NUL. Let's call this arbitrary sequence of bytes\n\"the nature of relation\".\n\nThe semantics I would attach to these \"related\" links are as\nfollows:\n\n * To the \"core\" level git, they do not mean anything other than\n \"you must to have these objects, and objects reachable from\n them, if you are going to have this commit and claim your\n repository is without missing objects\".\n\nThat means \"git-rev-list --objects\" needs to list these objects\n(and if they are tags, commits, and trees, then what are\nreachable from them), and \"git-fsck\" needs to consider these\nrelated objects and objects reachable from them are reachable\nfrom this commit. NOTHING ELSE NEEDS TO BE DONE by the core\n(obviously, cat-file needs to show them, and commit-tree needs to\nrecord them, but that goes without saying).\n\nThen porcelains can agree on what different kinds of nature of\nrelation mean and do sensible things. The earlier \"omit the\ncherry-picked ones\" example I gave can examine \"cherrypick\".\n"},{"id":"19082","messageId":"e2kjul$ntq$1@sea.gmane.org","threadId":"3962","inReplyTo":"7v7j5e2jv7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T07:43:33Z","receivedAt":"2006-04-25T07:43:33Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Here is a related but not necessarily competing idle thought.\n> \n> How about an ability to \"attach\" arbitrary objects to commit\n> objects? The commit object would look like:\n> \n> tree 0aaa3fecff73ab428999cb9156f8abc075516abe\n> parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355\n> parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504\n> related a0e7d36193b96f552073558acf5fcc1f10528917 key\n> related 0032d548db56eac9ea09b4ba05843365f6325b85 cherrypick\n> author Junio C Hamano 1145943079 -0700\n> committer Junio C Hamano 1145943079 -0700\n> \n> Merge branch 'pb/config' into next\n> \n> * pb/config:\n> Deprecate usage of git-var -l for getting config vars list\n> git-repo-config --list support\n> \n> The format of \"related\" attribute is, keyword \"related\", SP, 40-byte\n> hexadecimal object name, SP, and arbitrary sequence of bytes\n> except LF and NUL. Let's call this arbitrary sequence of bytes\n> \"the nature of relation\".\n> \n> The semantics I would attach to these \"related\" links are as\n> follows:\n> \n> * To the \"core\" level git, they do not mean anything other than\n> \"you must to have these objects, and objects reachable from\n> them, if you are going to have this commit and claim your\n> repository is without missing objects\".\n> \n> That means \"git-rev-list --objects\" needs to list these objects\n> (and if they are tags, commits, and trees, then what are\n> reachable from them), and \"git-fsck\" needs to consider these\n> related objects and objects reachable from them are reachable\n> from this commit. NOTHING ELSE NEEDS TO BE DONE by the core\n> (obviously, cat-file needs to show them, and commit-tree needs to\n> record them, but that goes without saying).\n\nPerhaps there should be an option to specify that the link is optional, and\nthe object pointed can be gone missing. For example for cherrypick the\noriginal cherry-picked commit can either be removed completely, e.g. when\nthe original branch is deleted, or it can be modified breaking link when we\nrewrite history up to original commit on original branch.\n\nAlso all other commands which show commit (commit messsage at least) should\nbe considered for including \"related\" links...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19086","messageId":"BAYC1-PASMTP097C0E667E1CBC8B3FC2BCAEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"e2kjul$ntq$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T08:34:36Z","receivedAt":"2006-04-25T08:34:36Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 09:43:33 +0200\nJakub Narebski wrote:\n\n> Perhaps there should be an option to specify that the link is optional, and\n> the object pointed can be gone missing. For example for cherrypick the\n> original cherry-picked commit can either be removed completely, e.g. when\n> the original branch is deleted, or it can be modified breaking link when we\n> rewrite history up to original commit on original branch.\n> \n> Also all other commands which show commit (commit messsage at least) should\n> be considered for including \"related\" links...\n\nIf you're cherry-picking from a disposable branch, then you don't want to \ninclude a link to it in your new commit. Once you include the link, the \nsource commit should be protected from pruning just like any other piece \nof history. Otherwise there's no way for fsck-objects to know if a missing \nobject means corruption or not. So you need a way at commit time to\nrequest the explicit linkage.\n\nThis might be useful for bug tracking front ends that could automatically \nshow a hot fix migrating from devel, to testing, to release branches. With \nJunio's proposal, perhaps there's even a better keyword for these particular \nlinkages.\n\nSean.\n"},{"id":"19089","messageId":"BAYC1-PASMTP116C6B217F25F2ADAF0C67AEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"20060425043436.2ff53318.seanlkml@sympatico.ca","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T08:57:52Z","receivedAt":"2006-04-25T08:57:52Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 04:34:36 -0400\nsean wrote:\n\n> If you're cherry-picking from a disposable branch, then you don't want to \n> include a link to it in your new commit. Once you include the link, the \n> source commit should be protected from pruning just like any other piece \n> of history. Otherwise there's no way for fsck-objects to know if a missing \n> object means corruption or not. So you need a way at commit time to\n> request the explicit linkage.\n\nActually this implies that anyone pulling just this branch would potentially\nalso end up pulling large portions of other branches too. So maybe making\nthem optional is The Right Thing. In which case, we'd just have to accept \nthese as weaker than the parentage links and fsck-objects et. al. would have \nto tolerate such missing commits.\n\nSo now that i've clearly come down in favor of both sides of this argument,\ni'll leave the decision to smarter people than me.\n\nSean\n"},{"id":"19090","messageId":"e2kp27$8ne$1@sea.gmane.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP116C6B217F25F2ADAF0C67AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T09:10:56Z","receivedAt":"2006-04-25T09:10:56Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"sean wrote:\n\n> On Tue, 25 Apr 2006 04:34:36 -0400\n> sean wrote:\n> \n>> If you're cherry-picking from a disposable branch, then you don't want to\n>> include a link to it in your new commit. Once you include the link, the\n>> source commit should be protected from pruning just like any other piece\n>> of history. Otherwise there's no way for fsck-objects to know if a\n>> missing\n>> object means corruption or not. So you need a way at commit time to\n>> request the explicit linkage.\n> \n> Actually this implies that anyone pulling just this branch would\n> potentially\n> also end up pulling large portions of other branches too. So maybe\n> making\n> them optional is The Right Thing. In which case, we'd just have to accept\n> these as weaker than the parentage links and fsck-objects et. al. would\n> have to tolerate such missing commits.\n\nActually, this can be resolved using automatic history grafts to the remote\nrepository we pulled from, if the commit is not present on local side (and\nremoving graft when commit appears on local side).\n\nI was more concerned about size of repository required by keeping some parts\nof history which would be purged without those \"related\" links. But your\nconcern (pulling) is more important.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19091","messageId":"7vmzeax9gj.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2kp27$8ne$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T09:58:52Z","receivedAt":"2006-04-25T09:58:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Actually, this can be resolved using automatic history grafts to the remote\n> repository we pulled from, if the commit is not present on local side (and\n> removing graft when commit appears on local side).\n\nYou do not even need history grafts. The \"cherry-pick source\"\nwas a bad example. Maybe using \"related\" as a way to implement\n\"bind\" would have been a better example -- we want inter-commit\nrelationship that requires connectivity but without ancestry for\nthem.\n\nYou can just have two kinds of 'related'. One that means\nconnectivity, the other that does not.\n\nAt that point, the latter does not even have to belong to the\ncore. The Porcelains can make use of it as long as they agree\non a common convention and use that information consistently.\nIt does not even have to be \"related\" (which implies what comes\nafter \"related\" is an object name) -- it could be an arbitrary\nmetainformation that the core does not have to care. So an\nupdated suggestion is to have optional 0-or-more \"note\" and\n\"related\" fields. 'note' is followed by one token and\nadditional information. 'related' is followed by an object name\nthat needs the additional connectivity, and and additional\ninformation. For example:\n\n tree 0aaa3fecff73ab428999cb9156f8abc075516abe\n parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355\n parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504\n related a0e7d36193b96f552073558acf5fcc1f10528917 bind linux-2.6\n note cherrypick v1.3.0~12\n note origin \"next\" branch at junio's repository\n note rename \"foobar\" to \"barboz\"\n author Junio C Hamano 1145943079 -0700\n committer Junio C Hamano 1145943079 -0700\n\n Merge branch 'pb/config' into next\n\nThe core side can say \"Oh, this is a 'note' so I do not care\nwhat it is -- I'd just skip to the end of line\", while\nPorcelains that \"cat-file commit\" this object can grep for\n\"note\" and look at the first token to figure out what to do with\nit. The core needs to be aware of the 'related' ones and does\nthe connectivity crud using the object name, and Porcelains can\nuse the rest of the line to do intelligent things.\n\nNow, it is debatable that such an extra information like 'note'\nbelongs to the header that the core deals with. IIRC, Linus\nargued that he does not want to have arbitrary cruft in the\nheader and instead to have it as a comment in the message part\nwhen somebody talked about recording renames in the commit.\n\nWe have the author and the committer fields that is not used by\nthe core (only half of the committer field is used by the core\nto date-order the commit list). But I suspect most of the time\nsuch metainformation is useless to the end-user humans, so if I\nhave to vote I'd rather put them in the header, have the UI\nlayer filter them out unless asked when presenting the commit to\nthe humans, and give Porcelains freedom to do whatever they\nwish.\n\nThings are easier to filter out when they properly follow some\nstructure, so I'd rather have \"cruft\" in the header. Right now,\ngit-cherry-pick ends the commit message with \"(cherry picked\nfrom $commit commit)\". In theory, rebase can notice by parsing\ncommit log message, but it certainly would be easier and more\nrobust if we had a 'note' facility and a well established\nconvention to use it.\n"},{"id":"19092","messageId":"e2kset$lk2$1@sea.gmane.org","threadId":"3962","inReplyTo":"7vmzeax9gj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T10:08:54Z","receivedAt":"2006-04-25T10:08:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> Actually, this can be resolved using automatic history grafts to the\n>> remote repository we pulled from, if the commit is not present on local\n>> side (and removing graft when commit appears on local side).\n> \n> You do not even need history grafts. The \"cherry-pick source\"\n> was a bad example. Maybe using \"related\" as a way to implement\n> \"bind\" would have been a better example -- we want inter-commit\n> relationship that requires connectivity but without ancestry for\n> them.\n> \n> You can just have two kinds of 'related'. One that means\n> connectivity, the other that does not.\n\nGood idea.\n\nAnother problem for core git, but I think orthogonal to the \"related\"/\"note\"\ndistinction is if the relation (or note) should be used as helper in\nmerges, perhaps by some agreed upon convention on the\ncomment/description/value part (e.g. \"mergehelper\" or \"mergeinfo\").\n\nBTW. in your first example, what \"key\" relation should mean?\n\"cherrypick\" (which should be \"note\" as we don't need connectivity) is\nquite obvious (or equivalent \"origin\" if rebase wouldn't destroy the branch\npicked from).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19097","messageId":"Pine.LNX.4.64.0604250758000.3701@g5.osdl.org","threadId":"3962","inReplyTo":"20060425035421.18382.51677.stgit@localhost.localdomain","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T15:10:36Z","receivedAt":"2006-04-25T15:10:36Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Sam Vilain wrote:\n>\n> This patch series implements \"prior\" links in commit objects. A\n> 'prior' link on a commit represents its historical precedent, as\n> opposed to the previous commit(s) that this commit builds upon.\n\nI really don't think this is worth it.\n\nWe already have a very useful notion of \"prior\" commit that is used daily \n(well, weekly) for the Linux kernel, and it's used for one of the few \nplaces where this really makes unequivocal sense. \"git revert\".\n\nIt's also implemented in the only way that has clear and unambiguous \nsemantics: by putting the prior link into the free-form part. The reason \nthis is clear and unambiguous is that it makes it clear that it has no \nactual technical impact on any serious git strategy, ie there is never any \nquestion of \"What does it _mean_?\".\n\nAt the same time, it gives exactly what you actually _want_ for a prior \nlink: it makes it easy to look up the commit that was replaced, or fixed, \nor that is related, or just any random semantics that you can explain \neasily in the text.\n\nBoth gitk and qgit already support it, and it's trivially \ncut-and-pasteable from any log message to see what it is when you work on \nthe command line too.\n\nIn contrast, adding a new header is serious trouble:\n\n - What does it _mean_ from a technical angle? \n\n Does it matter for merging? One of your patches seems to make it so, \n which is _really_ confusing. Why should it? And does it affect anything \n else that git does?\n\n Does \"prior\" have any meaning for \"git-fsck-objects\" and/or for object \n pruning? For \"git fetch/pull\"?\n\n - What does it mean from a semantic standpoint?\n\n Is \"prior\" a note that something was reverted? Fixed? Changed? \n Cherry-picked? And if it is Cherry-picked, than I would flat-out refuse \n to ever merge with a tree that has it, because it pretty much by \n definition means that the object that \"prior\" points to simply doesn't \n _exist_ in my tree (since it was cherry-picked from somebody elses \n tree). Or that it means that my history got tangled up with the history \n of the failed branch that needed cherry-picking to clean up..\n\n - You say that there is just one \"prior\" parent, but why just one? \n There's no way to even _think_ about this, since it seems to have no \n actual semantic meaning.\n\nI think all the problems really boil down to \"What does this mean?\"\n\nWithout an answer to that question, it's just a random feature. It's \nsomething that you can use and mis-use, but that has no \"meaning\". It only \nhas whatever meaning you personally assign to it, but that implies that \ngit shouldn't parse it, and shouldn't care about it.\n\nWhich again says that it should act like the current free-form thing does \nso well - it has no meaning, but it allows easy lookups.\n\n\t\tLinus\n"},{"id":"19098","messageId":"Pine.LNX.4.64.0604250811230.3701@g5.osdl.org","threadId":"3962","inReplyTo":"7v7j5e2jv7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T15:21:22Z","receivedAt":"2006-04-25T15:21:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Junio C Hamano wrote:\n> \n> How about an ability to \"attach\" arbitrary objects to commit\n> objects? The commit object would look like:\n> \n> tree 0aaa3fecff73ab428999cb9156f8abc075516abe\n> parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355\n> parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504\n> related a0e7d36193b96f552073558acf5fcc1f10528917 key\n> related 0032d548db56eac9ea09b4ba05843365f6325b85 cherrypick\n\nThis would at the face of it seem a bit better, but the fact is, it's not.\n\nWithout _semantics_ for the different cases, it's just random crud.\n\nWhat does any of the fields _mean_ to git? In particular, if you cannot \ncome up with an _exact_ definition of what they mean for fsck, pull, push, \nand any other random thing (how to show them for logging? How do they \naffect merge bases?), then it's still just random free-form text, and it \nshould go into the random free-form section.\n\n> The semantics I would attach to these \"related\" links are as\n> follows:\n> \n> * To the \"core\" level git, they do not mean anything other than\n> \"you must to have these objects, and objects reachable from\n> them, if you are going to have this commit and claim your\n> repository is without missing objects\".\n\nOk, a real semantic meaning. However:\n\nTHAT IS COMPLETELY USELESS.\n\nIt sure isn't useful for cherry-picking, which so far is one of the only \n\"real examples\" of where this would actually be used. \n\nIt isn't useful for much anything else either, because you really have two \ncases:\n\n - the \"related\" commit is an indirect parent _anyway_ (for things like \n \"revert\", this would obviously be the case, since it doesn't generally \n make a lot of sense to revert something that has never touched your \n history). In this case, the git semantics end up being NULL, and you \n just have another relationship that doesn't actually add any new \n information to the tree.\n\n - the \"related\" commit is not actually in the set of _real_ parenthood at \n all, and actually points to a different branch (or possibly even \n different project).\n\n This case I'd sure as hell hate to have for the kernel, at least. I \n would have to add crap to my workflow to make sure that people do _not_ \n have these kinds of linkages that link in random parts of their project \n that doesn't actually have anything to do with the history I'm pulling.\n\nThose are the only two possible cases. Either it's an indirect parent, or \nit isn't. Neither one makes any sense: the first one is a no-op from your \nsemantic definition, and the second one is just crazy and you'll just find \nthat people have to protect themselves from other developers doing \nsomething crazy by mistake.\n\nI want the git objects to have clear and unambiguous semantics. I want \npeople to be able to explain exactly what the fields _mean_. No \"this \nrandom field could be used this random way\" crud, please.\n\n\t\t\tLinus\n"},{"id":"19099","messageId":"Pine.LNX.4.64.0604250833540.3701@g5.osdl.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604250811230.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T15:40:25Z","receivedAt":"2006-04-25T15:40:25Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Linus Torvalds wrote:\n> \n> I want the git objects to have clear and unambiguous semantics. I want \n> people to be able to explain exactly what the fields _mean_. No \"this \n> random field could be used this random way\" crud, please.\n\nBtw, if the whole point is a \"leave random porcelain a field that they can \nuse any way they want\", then I say \"Hell NO!\".\n\nRandom porcelain can already just maintain their own lists of \"related\" \nstuff, any way they want: you can keep it in a file in \".git/porcelain\", \ncalled \"list-commit-relationships\", or you could use a git blob for it and \nhave a reference to it in .git/refs/porcelain/relationships or whatever. \n\nIf it has no clear and real semantic meaning for core git, then it \nshouldn't be in the core git objects.\n\nThe absolute last thing we want is a \"random out\" that starts to mean \ndifferent things to different people, groups and porcelains.\n\nThat's just crazy, and it's how you end up with a backwards compatibility \nmess five years from now that is totally unresolvable, because different \nprojects end up having different meanings or uses for the fields, so \nconverting the database (if we ever find a better format, or somebody \nnotices that SHA1 can be broken by a five-year-old-with-a-crayon).\n\nThere's a reason \"minimalist\" actually ends up _working_. I'll take a UNIX \n\"system calls have meanings\" approach over a Windows \"there's fifteen \ndifferent flavors of 'open()', and we also support magic filenames with \nspecific meaning\" kind of thing.\n\n\t\t\tLinus\n"},{"id":"19100","messageId":"BAYC1-PASMTP086A906CFB378AB229C2D8AEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604250833540.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T16:17:00Z","receivedAt":"2006-04-25T16:17:00Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 08:40:25 -0700 (PDT)\nLinus Torvalds wrote:\n\n> On Tue, 25 Apr 2006, Linus Torvalds wrote:\n> > \n> > I want the git objects to have clear and unambiguous semantics. I want \n> > people to be able to explain exactly what the fields _mean_. No \"this \n> > random field could be used this random way\" crud, please.\n> \n> Btw, if the whole point is a \"leave random porcelain a field that they can \n> use any way they want\", then I say \"Hell NO!\".\n> \n> Random porcelain can already just maintain their own lists of \"related\" \n> stuff, any way they want: you can keep it in a file in \".git/porcelain\", \n> called \"list-commit-relationships\", or you could use a git blob for it and \n> have a reference to it in .git/refs/porcelain/relationships or whatever. \n> \n> If it has no clear and real semantic meaning for core git, then it \n> shouldn't be in the core git objects.\n> \n> The absolute last thing we want is a \"random out\" that starts to mean \n> different things to different people, groups and porcelains.\n> \n> That's just crazy, and it's how you end up with a backwards compatibility \n> mess five years from now that is totally unresolvable, because different \n> projects end up having different meanings or uses for the fields, so \n> converting the database (if we ever find a better format, or somebody \n> notices that SHA1 can be broken by a five-year-old-with-a-crayon).\n> \n> There's a reason \"minimalist\" actually ends up _working_. I'll take a UNIX \n> \"system calls have meanings\" approach over a Windows \"there's fifteen \n> different flavors of 'open()', and we also support magic filenames with \n> specific meaning\" kind of thing.\n> \n\nIt's a fair point. But adding a separate database to augment the core \ninformation has some downsides. That is, that information isn't pulled, \ncloned, or pushed automatically; it doesn't get to ride for free on top \nof the core.\n\nAccommodating extra git headers (or \"note\"'s in Junio's example) would allow\na developer to record the fact that he is integrating a patch taken \nfrom a commit in the devel branch and backporting it to the release \nbranch. Either by adding a note that references the bug tracking #, or \na commit sha1 from the devel branch that is already associated with the bug.\n\nOf course that information could be embedded in the free text area, but \nyou yourself have argued vigorously that it is brain damaged to try and rely\non parsing free form text for these types of situations. Most of the potential \nuses aren't really meant for a human to read while looking at the log anyway, \nthey just get in the way. Another option that you alluded to, was to \nstuff the information in another git object. But such an object would have \nto embed a reference to the original commit, thus you haven't really made \nchanging the SHA1 algorithm any easier. And then you also then have to jump \nthrough hoops to make sure that you pull the proper extra blobs that contain \ninformation about the real commits you just pulled.\n\nBut if the information is in the actual commit header it gets to tag along\nfor free with never any worry it will be separated from the commit in question.\nSo when the developer above updates his official repo the bug tracker system \ncan notice that the bug referenced in its system has had a patch backported \nand take whatever action is desired. \n\nOf course there are other ways to do this, but integrating it into git means it\ngets a free ride on the core, and it shouldn't really get in the way of core \nany more than email X- headers get in the way of email flowing.\n\nSean\n"},{"id":"19101","messageId":"e2lijt$aco$1@sea.gmane.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604250833540.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T16:27:03Z","receivedAt":"2006-04-25T16:27:03Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Tue, 25 Apr 2006, Linus Torvalds wrote:\n>> \n>> I want the git objects to have clear and unambiguous semantics. I want\n>> people to be able to explain exactly what the fields _mean_. No \"this\n>> random field could be used this random way\" crud, please.\n> \n> Btw, if the whole point is a \"leave random porcelain a field that they can\n> use any way they want\", then I say \"Hell NO!\".\n\nThe generic commit links \"related\" which is fsck-able at least and \"note\"\nwhich is not. It is idea somewhat on the level of providing _extended\nattributes_ in VFS in Linux kernel, IMVHO.\n\n\"note\" can be considere cruft, \"related\" is fsck-able and pull-able so has\nmeaning for core (even if not all \"note\" and/or \"related\" links have any\nrepercussion for merging for example).\n\nSo far there are following core git ideas of using this feature (akin to\nusing extended attributes for ACL, or SELinux properties):\n\n1. \"related\" link \"bind\" for better support of subprojects. Useful if some\nparts of project are developed independently (e.g. lm_sensors or ALSA was\nin Linux kernel, xdiff for git, somelibrary or somemodule for someproject\netc.).\n2. \"note\" link \"cherrypicked\" for cherry-picking, rebase etc., for example\nto not apply the same commit twice. Useful in merging after cherry picking.\n\nAdditionally there are following less certain ideas\n\n3. \"prior\" link in the sense of prior state of frequently rebased branch\nlike git's \"pu\" (case (1) in first post in this thread)\n4. \"depend\" link for creating darc-esque dependency partial ordering of\ncommits (patches), for better merge perhaps\n5. \"note\" link \"rename\" (or more generic \"contents related\") for remembering\nrenames/file moving, file splitting, contents moving and copying, including\ncorrecting automatic \"rename\" detection at merge (i.e. remembering false\npositives and false negatives). Useful in subsequent merges and information\ncommands (log, whatchanged, annotate/blame, diff).\n6. \"note\" link \"origin\" to remember for where the commit was pulled.\n\nNote that none of those are non-core Porcelain ideas.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19102","messageId":"Pine.LNX.4.64.0604250952490.3701@g5.osdl.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP086A906CFB378AB229C2D8AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T17:04:21Z","receivedAt":"2006-04-25T17:04:21Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, sean wrote:\n> \n> It's a fair point. But adding a separate database to augment the core \n> information has some downsides. That is, that information isn't pulled, \n> cloned, or pushed automatically; it doesn't get to ride for free on top \n> of the core.\n\nBut the point is, we don't generally _want_ to pull, push, or clone this \ncrud.\n\nI for one would literally have to add code to say \"if any commit we poll \nhas this random field, I refuse to pull\". \n\nThere's two ways to have true interoperability (and in a distributed \nsystem, that's the thing that matters):\n\n - keep on piling on the sh*t\n - keep it simple so that people know exactly what the rules are.\n\nGuess which one I am religiously in favour of.\n\nThat's my whole point: the \"rules\" for this suggested \"prior\" or \"related\" \nfield simply don't exist, and it doesn't even seem to be the case that \npeople can agree what it _means_ in that nobody has actually explained \nwhat the thing would do and why you would use it.\n\nIf you cannot explain to the other side what a field is used for, then \nthat field - by definition - is not useful for the other side. It will \njust result in confusion, because different users will have different \nnotions of what to do with the field (if anything).\n\nSo some users might consider it to have meaning, and actually do different \nthings when it exists. Others would ignore it entirely. Yet thirds would \nignore it, but consider it a link that must exist - which would break \nwhenever those people would interact with the people who ignore it, and \nthink that it's superfluous.\n\nThis is why it has to have real meaning. If there are no rules, things \nwill break. Some things will pull them, others won't, yet third things \nwill do random things.\n\nIf you just want to have something that \"follows\" an archive, it's easy \nenough to do: have a totally separate ref, that is a real branch, but may \nnot even contain any files at all. You can - perfectly validly - have a \nchain of commits where all the information is in the \"free-form\" text area \nas far as git is concerned, but where the trees are all empty.\n\nYou'll find that all git users can pull such a commit, and you can use all \nthe normal git ops on them, and you can hide your own metadata in there. \nAnd it would still be a valid git tree - your metadata would be your \nprivate thing, and you can keep it along-side the \"normal\" git data, and \nyou can have your own \"extended fsck\", and \"git pull/push\" still continues \nto work. \n\nJunio does something like that with the \"todo\" branch, for example (it's \nhuman-readable, not automated, but that doesn't really change anything). \nYou can do\n\n\tgit ls-tree todo\n\tgit cat-file blob todo:Porcelainistas | less -S\n\nand in general do anything you damn well please there. WITHOUT making \nup any new (and unnecessary) format semantics that nobody else cares \nabout and that don't have very well-specified meaning.\n\n\t\tLinus\n"},{"id":"19103","messageId":"Pine.LNX.4.64.0604251004410.3701@g5.osdl.org","threadId":"3962","inReplyTo":"e2lijt$aco$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T17:11:13Z","receivedAt":"2006-04-25T17:11:13Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Jakub Narebski wrote:\n> \n> The generic commit links \"related\" which is fsck-able at least and \"note\"\n> which is not. It is idea somewhat on the level of providing _extended\n> attributes_ in VFS in Linux kernel, IMVHO.\n\nAnd nobody actually uses extended attributes either, do they?\n\nPlus it's _not_ fsck'able, since the thing doesn't even have any valid \nsemantics. You guys can't even agree on whether the object must exist or \nnot. \n\nAnyway, I'm not interested. I'm violently opposed to the mess that is \ndarcs and other crapola. The WHOLE point of git is to have well-defined \nsemantics and get away from the horrors that other systems have done, \nwhere they have allowed any random crap to \"make sense\". \n\nIf you want darcs-like semantics where there are no rules, just use darcs, \nfor chrissake! And if you want to base it on git because you've noticed \nthat git is (a) stable, (b) fast and (c) has developed remarkably well, \nthen think for a second _why_ git is stable, fast, and well-developed. \nIt's that exactly because it has clear semantics, and no room for random \ncrud.\n\nGit tracks contents, and the well-defined history of how those contents \ncame to be. Git does NOT track \"additional notes\" left by the developer \nthat have weak semantics. Git does not track when a developer says \"I \nrenamed a file\".\n\nFor exactly the same reason, git should not track it when a developer says \n\"I think this commit is related to that commit\". It's not hard data, that \nhas hard and clear semantics.\n\nOnce you start adding data that has no clear semantics, you're screwed. At \nthat point, it's a \"track guesses\" game, not a \"track contents\" game.\n\n\t\t\tLinus\n"},{"id":"19104","messageId":"e2lmm3$rts$1@sea.gmane.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251004410.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T17:36:30Z","receivedAt":"2006-04-25T17:36:30Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Tue, 25 Apr 2006, Jakub Narebski wrote:\n>> \n>> The generic commit links \"related\" which is fsck-able at least and \"note\"\n>> which is not. It is idea somewhat on the level of providing _extended\n>> attributes_ in VFS in Linux kernel, IMVHO.\n> \n> And nobody actually uses extended attributes either, do they?\n\nFedora's SELinux does use them, IIRC.\n\nWell, people do use X-* headers in mail (sean's example), and some of them\ngot promoted from X-* to ordinary mail header status.\n\n> Plus it's _not_ fsck'able, since the thing doesn't even have any valid\n> semantics. You guys can't even agree on whether the object must exist or\n> not.\n\nErm, further on we did agree \n http://permalink.gmane.org/gmane.comp.version-control.git/19142\n (Message-Id: <7vmzeax9gj.fsf@assigned-by-dhcp.cox.net>). \n\"related\" links means that object must exist. \"note\" is what name says, just\nnote and doesn't even need to point to object.\n\n> For exactly the same reason, git should not track it when a developer says\n> \"I think this commit is related to that commit\". It's not hard data, that\n> has hard and clear semantics.\n> \n> Once you start adding data that has no clear semantics, you're screwed. At\n> that point, it's a \"track guesses\" game, not a \"track contents\" game.\n\nWell, the best example, i.e. remembering cherry picking has well defined\nsemantic (added when cherry-picking, used when merging, object does need\nnot to exist) but not well defined form. Currently the convention for\nfree-form is used, which has its advantages and disadvantages as pointed\nout by Junio.\n\n\n[somewhat unrelated note]\n> Git tracks contents, and the well-defined history of how those contents\n> came to be. Git does NOT track \"additional notes\" left by the developer\n> that have weak semantics. Git does not track when a developer says \"I\n> renamed a file\".\n\nBut I'd like Git to remember when I corrected false positives in \"rename\"\ndetection during merge, and added undetected automatically renames/file\ncontents copying and/or moving. Whether it would be done by saving the\ninformation in commit header, commit free-for, or somewhere else...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19105","messageId":"BAYC1-PASMTP091348C4C33C5A0E83C012AEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251004410.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T17:52:50Z","receivedAt":"2006-04-25T17:52:50Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 10:11:13 -0700 (PDT)\nLinus Torvalds wrote:\n\n> Once you start adding data that has no clear semantics, you're screwed. At \n> that point, it's a \"track guesses\" game, not a \"track contents\" game.\n\nThen shouldn't Git stop tracking commit comments; they're just developer\nguesses. ;o) Adding a free-form header is no different than adding a \nfew more lines of free form text at the bottom of the commit message, in \nneither case does it change the nice clean git semantics.\n\nSean\n"},{"id":"19106","messageId":"Pine.LNX.4.64.0604251053100.3701@g5.osdl.org","threadId":"3962","inReplyTo":"e2lmm3$rts$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T17:57:45Z","receivedAt":"2006-04-25T17:57:45Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Jakub Narebski wrote:\n> \n> Erm, further on we did agree \n\nHell no \"we\" didn't.\n\nSince I totally refuse to touch anything like that.\n\nI even told you exactly why, for things like the suggested \"cherry-pick\" \nthing.\n\nWhich still remains the \"best\" example. And I say \"best\", because as an \nexample it totally sucks. Again, for reasons I made very clear.\n\nThe fact is, there is _zero_ reason for this field to exist. Nobody has \nactually mentioned a single use that is really valid and that people can \nagree on across different uses.\n\nSo here's the challenge: name _one_ thing that people actually can agree \non, and that adds real measurable _value_ from a core git standpoint. \nSomething where the semantics actually change what git does.\n\nThe \"track it with pull/push\" thing is NOT one such thing, however much \nyou protest. We already _have_ that thing. It's called a \"ref\", and it's \nreally really easy to create anywhere in .git/refs/, and the tools already \nknow how to use it.\n\n\t\tLinus\n"},{"id":"19107","messageId":"Pine.LNX.4.64.0604251058490.3701@g5.osdl.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251053100.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T18:06:32Z","receivedAt":"2006-04-25T18:06:32Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Linus Torvalds wrote:\n> \n> The \"track it with pull/push\" thing is NOT one such thing, however much \n> you protest. We already _have_ that thing. It's called a \"ref\", and it's \n> really really easy to create anywhere in .git/refs/, and the tools already \n> know how to use it.\n\nBtw, there are other cases for that. For example, \"parent\" is a \nwell-specified thing that actually has very clear and unambiguous meaning. \n\nAnd we had a much better proposals (in the sense that it had real \nsuggested _meaning_ and semantics) over the last few months for things \nlike sub-projects (trees that point to other commits) or last year a \ndiscussion about \"container objects\" (like the current tags, but listing \nmultiple objects instead of just one).\n\nAll of which had clear and unambiguous semantics (but were not done for \nother reasons - maybe the sub-project still remains on the horizon, the \n\"container objects\" thing doesn't seem to have gone anywhere).\n\n\t\t\tLinus\n"},{"id":"19108","messageId":"Pine.LNX.4.64.0604251106400.3701@g5.osdl.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP091348C4C33C5A0E83C012AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T18:08:31Z","receivedAt":"2006-04-25T18:08:31Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, sean wrote:\n\n> On Tue, 25 Apr 2006 10:11:13 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n> > Once you start adding data that has no clear semantics, you're screwed. At \n> > that point, it's a \"track guesses\" game, not a \"track contents\" game.\n> \n> Then shouldn't Git stop tracking commit comments; they're just developer\n> guesses. ;o)\n\nNo, they are pure content, and git doesn't actually give them any semantic \nmeaning.\n\nWHICH IS OK. I even suggested that you put this thing into that \"pure \ncontent\" part.\n\n> Adding a free-form header is no different than adding a few more lines \n> of free form text at the bottom of the commit message, in neither case \n> does it change the nice clean git semantics.\n\nWhich is exactly what I told you to do. Just don't make it a git header. \n\nWe do that already. Look at \"git revert\". Ooh. Aah. It works today.\n\nJust don't make it something that changes semantics, and that git parses \nand \"understands\". Because git clearly doesn't understand it at all, since \nyou didn't define it to have any meaning that _can_ be understood.\n\n\t\tLinus\n"},{"id":"19109","messageId":"BAYC1-PASMTP04D82622D9D5DA7E352079AEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251106400.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T18:14:12Z","receivedAt":"2006-04-25T18:14:12Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)\nLinus Torvalds wrote:\n\n> Which is exactly what I told you to do. Just don't make it a git header. \n\nWell I just don't see how making it a header, or plopping it at the\nend of a commit message makes an iota of difference to git, while it \ncan help porcelain.\n\n> We do that already. Look at \"git revert\". Ooh. Aah. It works today.\n\nNice. Gotta love git.\n \n> Just don't make it something that changes semantics, and that git parses \n> and \"understands\". Because git clearly doesn't understand it at all, since \n> you didn't define it to have any meaning that _can_ be understood.\n\nBut that's exactly the point, it's no different than extending git to be\nable to store more than one comment. Comment1 Comment2 Comment3. \nPure content that git need not give any semantic meaning. Git has a \nlimitation of only a single comment today, there's no semantic damage\nto extending git to allow multiple comments. And there are a few \napplications, like bug tracking etc, which could use such a feature \nto good effect.\n\nSean\n"},{"id":"19111","messageId":"e2lpgb$64l$1@sea.gmane.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251058490.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T18:24:38Z","receivedAt":"2006-04-25T18:24:38Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Tue, 25 Apr 2006, Linus Torvalds wrote:\n>> \n>> The \"track it with pull/push\" thing is NOT one such thing, however much\n>> you protest. We already _have_ that thing. It's called a \"ref\", and it's\n>> really really easy to create anywhere in .git/refs/, and the tools\n>> already know how to use it.\n\nI agree(d) that tracking pull/push with extra commit header fields is not a\ngood example.\n \n> Btw, there are other cases for that. For example, \"parent\" is a\n> well-specified thing that actually has very clear and unambiguous meaning.\n\nIn single parent case, \"parent\" means that we modified tree pointed by the\nparent. Multiple parent case suggests that we combined trees pointed by\nparents, most probable by merge. I'd rather we not use parent for anything\nelse.\n\n> And we had a much better proposals (in the sense that it had real\n> suggested _meaning_ and semantics) over the last few months for things\n> like sub-projects (trees that point to other commits)\n\nWasn't it commits pointing to other trees (or to commits)? \"bind\" field\nproposal suggests it. And it could be implemented using 'X-*' \"related\"\nheaders in commit.\n\n related a0e7d36193b96f552073558acf5fcc1f10528917 bind linux-2.6\n\nvs. proposed\n\n bind f6a8248420395bc9febd66194252fc9957b0052d linux/\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19112","messageId":"Pine.LNX.4.64.0604251125010.3701@g5.osdl.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP04D82622D9D5DA7E352079AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T18:26:25Z","receivedAt":"2006-04-25T18:26:25Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, sean wrote:\n\n> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n> > Which is exactly what I told you to do. Just don't make it a git header. \n> \n> Well I just don't see how making it a header, or plopping it at the\n> end of a commit message makes an iota of difference to git, while it \n> can help porcelain.\n\nIt can't help porcelain.\n\nIf we have undefined or bad semantics for it, the only thing it can do is \n_hurt_ porcelain, because it will cause confusion down the line.\n\nSemantics for data objects are _the_ most important part of a SCM. Pretty \nmuch any project, in fact. \n\nAnd bad or weakly defined semantics will invariably cause problems later.\n\n> But that's exactly the point, it's no different than extending git to be\n> able to store more than one comment.\n\nSo why argue for it?\n\nJust use the existing comment field.\n\n\t\tLinus\n"},{"id":"19113","messageId":"e2lq2l$64l$2@sea.gmane.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP04D82622D9D5DA7E352079AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T18:34:25Z","receivedAt":"2006-04-25T18:34:25Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"sean wrote:\n\n> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n>> Which is exactly what I told you to do. Just don't make it a git header.\n> \n> Well I just don't see how making it a header, or plopping it at the\n> end of a commit message makes an iota of difference to git, while it \n> [storing information in X-* like header] can help porcelain.\n\nAnd [graphical] history browsers like gitk or qgit.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19114","messageId":"e2lqf1$a5k$1@sea.gmane.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251125010.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T18:41:00Z","receivedAt":"2006-04-25T18:41:00Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> So why argue for it?\n> \n> Just use the existing comment field.\n\nFor the same reason there exist X-* _header_ fields in email.\n\nAdditionally, in \"related\" links we require that object exist (core git),\nregardless of detailed semantics.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19115","messageId":"BAYC1-PASMTP03E0B5376ACFF165B29ED1AEBF0@CEZ.ICE","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251125010.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-25T18:45:25Z","receivedAt":"2006-04-25T18:45:25Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 25 Apr 2006 11:26:25 -0700 (PDT)\nLinus Torvalds wrote:\n\n> It can't help porcelain.\n> \n> If we have undefined or bad semantics for it, the only thing it can do is \n> _hurt_ porcelain, because it will cause confusion down the line.\n> \n> Semantics for data objects are _the_ most important part of a SCM. Pretty \n> much any project, in fact. \n> \n> And bad or weakly defined semantics will invariably cause problems later.\n\nTake your example of how git-revert works today, it copies the comment from \nthe original, thus keeping this semantic-free meta-data intact between\nrelated commits. However, you'd have to jump through hoops to accomplish\nthis same simple task with any third party meta data, unless it was \nburried inside the commit message text.\n \n> So why argue for it?\n> \n> Just use the existing comment field.\n\nThe last argument you and I had was me taking the other side, saying that \nit was fine for git to parse the free form text area to extract information; \nyou rightfully showed me why that was wrong.\n\nIt's no different for a bug tracker or other 3rd party software that wants\nto interface with git, it's bad design to force them to parse a single\nfree form text comment into individual pieces to extract their meta data.\nEspecially when git could easily add the ability to add multple comments\nto each commit. \n\nSean\n"},{"id":"19116","messageId":"Pine.LNX.4.64.0604251151350.3701@g5.osdl.org","threadId":"3962","inReplyTo":"e2lqf1$a5k$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T18:52:08Z","receivedAt":"2006-04-25T18:52:08Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Jakub Narebski wrote:\n> \n> Additionally, in \"related\" links we require that object exist (core git),\n> regardless of detailed semantics.\n\nAnd as I've now mentioned a hundred times, that's just unacceptable to me. \nNo suggested use of this has actually been useful, that I can tell.\n\n\t\tLinus\n"},{"id":"19117","messageId":"Pine.LNX.4.64.0604251155530.3701@g5.osdl.org","threadId":"3962","inReplyTo":"BAYC1-PASMTP03E0B5376ACFF165B29ED1AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T19:00:02Z","receivedAt":"2006-04-25T19:00:02Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, sean wrote:\n> \n> It's no different for a bug tracker or other 3rd party software that wants\n> to interface with git, it's bad design to force them to parse a single\n> free form text comment into individual pieces to extract their meta data.\n> Especially when git could easily add the ability to add multple comments\n> to each commit. \n\nGit _does_ make that easy. It's called the \"tree\". It's where you add any \narbitrary files to a commit.\n\nThe point here is that core git should do one thing, and one thing only. \nYou can then build up any policy you want on top of that. But in order for \ncore git to be stable, it has to have nice rules about what it cares \nabout, and what it does not.\n\nAnd the rule is: git cares about the commit header, but not about the \nfree-form. Which means that anything it doesn't care about, it goes into \nthe free-form section, not into some \"X-header\" section.\n\nWhatever you build on TOP of git can have its own rules in that free-form \nsection. For example, the kernel project has this \"X-header\" thing called \nthe \"sign-off\", and git itself picked it up. There's even some support to \nadd it automatically to commits (the same way we add the \"revert\" info \nautomatically to commits), but nobody claims that git should \"parse\" that \ninformation, or that it should be part of the \"header\".\n\n\t\tLinus\n"},{"id":"19118","messageId":"7vr73lwkdt.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251125010.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T19:00:30Z","receivedAt":"2006-04-25T19:00:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 25 Apr 2006, sean wrote:\n>\n>> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)\n>> Linus Torvalds wrote:\n>> \n>> > Which is exactly what I told you to do. Just don't make it a git header. \n>> \n>> Well I just don't see how making it a header, or plopping it at the\n>> end of a commit message makes an iota of difference to git, while it \n>> can help porcelain.\n>\n> It can't help porcelain.\n>\n> If we have undefined or bad semantics for it, the only thing it can do is \n> _hurt_ porcelain, because it will cause confusion down the line.\n>\n> Semantics for data objects are _the_ most important part of a SCM. Pretty \n> much any project, in fact. \n>\n> And bad or weakly defined semantics will invariably cause problems later.\n>\n>> But that's exactly the point, it's no different than extending git to be\n>> able to store more than one comment.\n>\n> So why argue for it?\n>\n> Just use the existing comment field.\n\nActually, it does help Porcelain to be able to mark unrelated\ncrud as 'note'. Sane people (including git barebone\nPorcelainish) would just ignore it. Unless --pretty=raw is used\nthe 'note' headers will not be shown. It would unclutter\nthings for us.\n\nIf different Porcelains use \"the existing comment field\" by\ndefining certain mark-up to embed their own data, it has the\nsame \"weak semantics causing confusion down the line\" issue,\n_and_ the crud will be shown to the end user by \"git log\".\n\nSo I am starting to be actually in favor of the 'note' header.\n\nEarlier somebody wondered if that has impact on merge semantics.\nI think we do _not_ care. The core level does not track how\nthings changed (the operation to make preimage to postimage),\nbut tracks what the results of changes are (the content).\n\nSome \"misguided\" set of Porcelains may come up with a convention\nto record renames and token-replaces in the 'note' header to\nsay:\n\n\ttree 0000000000000000000000000000000000000000\n parent 0000000000000000000000000000000000000000\n\tauthor A U Thor 000000000 +0000\n\tcommitter C O Mitter 000000000 +0000\n\tnote rename hello.c world.c\n note token-replace s/cache/index/\n\n Replaced old nomenclature 'cache' to 'index'. Oh, while\n at it, I renamed hello.c to world.c.\n\nBut unlike systems that records the transformation from preimage\nto postimage, we record the postimage (on \"tree\" header) and\npreimage (by the way of \"parent\" header). We (as the core and\nPorcelain that do not use \"note\") do not even need to look at\nwhat 'note' says. The Porcelains that _do_ look at the note may\ntry to take advantage of it, and if they make better result that\nwould be a good thing. I suspect such 'note rename' provided by\nthe end user is not trustworthy at times, so a Porcelain that\nrelies on that may make silent mismerge. You may claim that is\nthe reason why you do not want to pull from a tree managed with\nsuch a Porcelain.\n\nBut at the end of the day what matters is the content, and\npeople.\n\nYou will not be using such a Porcelain yourself, but when you\nfetch the above commit, which records its tree and its parents,\ngit barebone Porcelainish merge will just do what it has always\ndone, without even looking at 'note'. It's not like use of\n'note' on the other end is forcing you to take a note on them.\n\nRefusing to merge from a tree that is managed with a Porcelain\nthat uses the information in 'note rename' for its own operation\n(maybe because we believe such Porcelain tends to make silent\nmismerges more often) does not make much more sense than\nrefusing to merge from a tree whose developer uses vi (because\nit tends to lose \"missing LF at the end of file\"). The content\nmatters, so you would check the merge result; and 'note' thing\nis opt-in, which we opt out.\n\nAlso you ultimately trust people -- \"I will pull from his tree,\nbecause I know he is careful and has good taste\". Now the tool\nthey use _may_ be part of their taste, but any tool can be\nmisused (remember you stayed away from pulling things that have\nOctopus?)\n\nI am less (a lot less) sure about the 'related' header now,\nwhich will be the topic of a separate message.\n"},{"id":"19119","messageId":"e2lrk5$ed5$1@sea.gmane.org","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251151350.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-25T19:00:48Z","receivedAt":"2006-04-25T19:00:48Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> \n> \n> On Tue, 25 Apr 2006, Jakub Narebski wrote:\n>> \n>> Additionally, in \"related\" links we require that object exist (core git),\n>> regardless of detailed semantics.\n\nAnd history browsers (gitk, qgit) can use it, drawing line, regardless of\nsemantics.\n\n> And as I've now mentioned a hundred times, that's just unacceptable to me.\n> No suggested use of this has actually been useful, that I can tell.\n\nI don't mean we shouldn't define semantic for each use of \"related\" or\n\"note\" header. Just like email X-* headres have detailed form and semantic\n(long, long time ago Sender was X-Sender for example ;-). It's just a\ntoolkit.\n\nAs to suggested \"related\" (requiring object to exists) headers: \"bind\",\n\"prior\", and perhaps \"revert\".\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19120","messageId":"Pine.LNX.4.64.0604251204320.3701@g5.osdl.org","threadId":"3962","inReplyTo":"7vr73lwkdt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T19:09:33Z","receivedAt":"2006-04-25T19:09:33Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Junio C Hamano wrote:\n> \n> Actually, it does help Porcelain to be able to mark unrelated\n> crud as 'note'. \n\nA \"note\" header that explicitly has no meaning _what-so-ever_ for git \nwould be fine. Then the semantics are well-defined, and they really do \nboil down to: random strings that git will ignore, and that won't normally \nbe shown by \"git log\".\n\nThose are actually real semantics, the same way the current \"content\" is \nreal semantics: we don't care about it at all, and we _guarantee_ that we \ndon't care about it.\n\nThe problem with the proposed \"related\" thing was that it was somethign \nthat git was supposed to care about, but since it had no sane semantics, \nthere was no way to _make_ git care about it sanely. That was the problem.\n\nSo I'm not objecting to adding headers. I'm objecting to adding headers \nthat have insane or badly defined semantics where we might be asked to do \nsomething for them and different versions of git migth do different \nthings. \n\n\t\t\tLinus\n"},{"id":"19121","messageId":"7vslo1v4zw.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251155530.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T19:18:11Z","receivedAt":"2006-04-25T19:18:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And the rule is: git cares about the commit header, but not about the \n> free-form. Which means that anything it doesn't care about, it goes into \n> the free-form section, not into some \"X-header\" section.\n>\n> Whatever you build on TOP of git can have its own rules in that free-form \n> section. For example, the kernel project has this \"X-header\" thing called \n> the \"sign-off\", and git itself picked it up. There's even some support to \n> add it automatically to commits (the same way we add the \"revert\" info \n> automatically to commits), but nobody claims that git should \"parse\" that \n> information, or that it should be part of the \"header\".\n\nThen we should drop the author header and make it part of free\nform text. The core does not give any meaning to it. And the\nname part of the commit header as well. The only thing\nused by the core is the timestamp of the commit.\n\nMy initial 'related' without 'note' was flawed - it used\ncherry-pick as an example of 'related' when it clearly should\nhave been 'note' (no connectivitiy required).\n\nHaving said what I wanted to say about 'note', let's clarify\nwhat I have in mind about the 'related' that _means_\nconnectivity. As I said, I am far less convinced it is a good\nthing than I am about 'note' by now, but just for the sake of\ncompleteness of the discussion.\n\nI tend to agree with you that ability to misuse 'related' (I'd\ncall it 'link' to make it clear that it means connectivity) to\nfetch/push \"related\" objects, with an unclear definition of\nrelated-ness, is a bad thing. Even if we fetched the objects\nthat are claimed to be related to the main project, if we do not\nknow what to do with them, it is not useful.\n\nAnd for well defined connectivity, we could give separate names,\njust like we have 'tree' and 'parent' in the commit header.\nThat's how \"bind commit\" was initially proposed. It was not\n'link bind'.\n\nThe suggestion of 'link bind' came primarily from the pain I\nexperienced when I taught rev-list --objects and fsck-objects\nabout it in the jc/bind branch. If the only thing asked to the\ncore by 'link' is to make sure the related objects are made\navailable, and Porcelains take responsibility after they are\nmade available, we would be better off teaching the commit\nparser how to parse 'link' (regardless of its nature of linkage)\nand teach rev-list --objects and fsck-objects to do connectivity\njust once, rather than adding 'bind' now and then having to do\nthe same backward incompatible change when adding something else\nthat requires connectivity.\n\nThere definitely needs to be an ability to specify a list of\n\"nature of links this repository accepts\", if we were to do\n'link'. It probably should default to an empty set. rev-list\n--objects would include objects pointed by 'link' only when the\nrepository wants such links to be honored. fsck-objects will\ndeclare an object that is reachable only by a 'link' that is not\naccepted by the repository \"uninteresting\" and let git-prune\nremove it.\n"},{"id":"19122","messageId":"Pine.LNX.4.64.0604251233340.3701@g5.osdl.org","threadId":"3962","inReplyTo":"7vslo1v4zw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T19:34:25Z","receivedAt":"2006-04-25T19:34:25Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Junio C Hamano wrote:\n> \n> Then we should drop the author header and make it part of free\n> form text. The core does not give any meaning to it.\n\nSure it does. It's an integral part of logging: we not only verify the \nformat, we also have multiple different ways of showing it. So it \ndefinitely changes the way we \"act\", very fundamentally.\n\n\t\tLinus\n"},{"id":"19123","messageId":"7vodypv3gz.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"Pine.LNX.4.64.0604251233340.3701@g5.osdl.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T19:51:08Z","receivedAt":"2006-04-25T19:51:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 25 Apr 2006, Junio C Hamano wrote:\n>> \n>> Then we should drop the author header and make it part of free\n>> form text. The core does not give any meaning to it.\n>\n> Sure it does. It's an integral part of logging: we not only verify the \n> format, we also have multiple different ways of showing it. So it \n> definitely changes the way we \"act\", very fundamentally.\n\nUnfair ;-). I'd consider \"git log\" semi-Porcelain and consider\nrev-list and cat-file the true core level.\n\nBut you already made it clear that you are not opposed to 'note'\nwith a clear semantics \"we _ignore_ it\", the point was moot.\n\nSorry for the noise.\n"},{"id":"19124","messageId":"Pine.LNX.4.64.0604251256050.3701@g5.osdl.org","threadId":"3962","inReplyTo":"7vodypv3gz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-25T19:58:31Z","receivedAt":"2006-04-25T19:58:31Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Apr 2006, Junio C Hamano wrote:\n> >\n> > Sure it does. It's an integral part of logging: we not only verify the \n> > format, we also have multiple different ways of showing it. So it \n> > definitely changes the way we \"act\", very fundamentally.\n> \n> Unfair ;-). I'd consider \"git log\" semi-Porcelain and consider\n> rev-list and cat-file the true core level.\n\nWell, \"git log\" is really just \"git-rev-list --pretty\", so whichever way \nyou turn, it's there.\n\nI come from a slightly different background, where \"core git\" in many ways \noriginally was about \"what I use\" and the whole \"porcelain\" side ends up \nbeing \"what people who need hand-holding use\" ;)\n\nOf course, it expanded a bit from that original definition ;)\n\n\t\tLinus\n"},{"id":"19125","messageId":"8801.1146003428@lotus.CS.Berkeley.EDU","threadId":"3962","inReplyTo":"e2lrk5$ed5$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-04-25T22:17:08Z","receivedAt":"2006-04-25T22:17:08Z","isPatch":true,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Jakub Narebski writes:\n - I don't mean we shouldn't define semantic for each use of \"related\" or\n - \"note\" header. Just like email X-* headres have detailed form and semantic\n - (long, long time ago Sender was X-Sender for example ;-). It's just a\n - toolkit.\n\nYou just proved Linus's point. Ever have to parse\narchives of old mail? There are many different ways\nof saying the same thing, and many of the same way\nof saying different things. It's pure hell.\n\nAnd people expect you to get the X-* headers correct\nfor whatever definition of correct they happen to have\nat the moment. ugh. You have many de-facto semantics\nfor the same headers, and no way to disambiguate them.\n\nPeople will need to parse and understand git archives\nthirty+ years from now. Don't place this curse on\nthem.\n\nJason\n"},{"id":"19127","messageId":"444EAE63.1070006@vilain.net","threadId":"3962","inReplyTo":"7v7j5e2jv7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-25T23:18:59Z","receivedAt":"2006-04-25T23:18:59Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n>Here is a related but not necessarily competing idle thought.\n>\n>How about an ability to \"attach\" arbitrary objects to commit\n>objects? The commit object would look like:\n>\n> tree 0aaa3fecff73ab428999cb9156f8abc075516abe\n> parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355\n> parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504\n> related a0e7d36193b96f552073558acf5fcc1f10528917 key\n> related 0032d548db56eac9ea09b4ba05843365f6325b85 cherrypick\n> author Junio C Hamano 1145943079 -0700\n> committer Junio C Hamano 1145943079 -0700\n> \n>\n\nI agree with the criticisms of the patchset, and I think this is\nprobably a more comprehensive and less ambiguous solution. I originally\nthought that the use cases were close enough together that they could be\ncalled the same thing, but I see now that they are not.\n\nIMHO one important goal is to stop \"parent\" from meaning anything other\nthan:\n\n1. for a regular commit, the base for this change. The change consists\nof the differences between the two trees.\n2. for a \"merge\", the merge parents for this change. The change consists\nof all differences between the index merges (allowing duplicate blobs at\neach location) and the final merged tree.\n\nIf you were to, for a moving merge head, just record the previous merge\nas a \"parent\", then it would make it difficult to look at the commit\nhistory to figure out which parent links represent the last merge, and\nwhich represent the merge bases.\n\nThis suggestion fixes that problem nicely, while being nice and flexible\nfor solving the other problems too.\n\n> Merge branch 'pb/config' into next\n>\n> * pb/config:\n> Deprecate usage of git-var -l for getting config vars list\n> git-repo-config --list support\n>\n>The format of \"related\" attribute is, keyword \"related\", SP, 40-byte\n>hexadecimal object name, SP, and arbitrary sequence of bytes\n>except LF and NUL. Let's call this arbitrary sequence of bytes\n>\"the nature of relation\".\n>\n>The semantics I would attach to these \"related\" links are as\n>follows:\n>\n> * To the \"core\" level git, they do not mean anything other than\n> \"you must to have these objects, and objects reachable from\n> them, if you are going to have this commit and claim your\n> repository is without missing objects\".\n> \n>\n\nThis is essentially correct, however you have already described a use\ncase where you want the behaviour to be to lose the previous commit chain:\n\n>The reason I do not include the previous head when I reconstruct\n>\"pu\" is because I explicitly *want* to drop history -- not\n>having to carry forward a failed experiment is what is desired\n>there. Otherwise I would manage \"pu\" just like I currently do\n>\"next\" and \"master\". So this is not a justification to add\n>something new.\n> \n>\n\nIn this case, I think that there are types of relations that are more\nalong the lines of \"don't bother following this link by default, but\nwarn/fail if it is unavailable depending on the user preferences\".\n\ngit-fsck could then have options to prune (or archive) certain types of\noptional relations. This way people can still record complete history if\nthey like. And people who want to mark portions of history as bad (such\nas, violating copyright law) have a clear way to state that intent.\n\n>That means \"git-rev-list --objects\" needs to list these objects\n>(and if they are tags, commits, and trees, then what are\n>reachable from them), and \"git-fsck\" needs to consider these\n>related objects and objects reachable from them are reachable\n>from this commit. NOTHING ELSE NEEDS TO BE DONE by the core\n>(obviously, cat-file needs to show them, and commit-tree needs to\n>record them, but that goes without saying).\n> \n>\n\nOk, I'll investigate that.\n\n>Then porcelains can agree on what different kinds of nature of\n>relation mean and do sensible things. The earlier \"omit the\n>cherry-picked ones\" example I gave can examine \"cherrypick\".\n> \n>\n\nSounds good. Let things evolve.\n\nSam.\n"},{"id":"19128","messageId":"444EAE7C.5010402@vilain.net","threadId":"3962","inReplyTo":"7vwtde2q1z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-25T23:19:24Z","receivedAt":"2006-04-25T23:19:24Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n>> 2. revising published commits / re-basing\n>>\n>> This is what \"stg\" et al do. The tools allow you to commit,\n>> rewind, revise, recommit, fast forward, etc.\n>> \n>>\n>\n>stg wants to have a link to the fork-point commit. I do not\n>know if it is absolutely necessary (you might be able to figure\n>it out using merge-base, I dunno).\n> \n>\n\n\"stg pull\" and \"stg pick\" could conceivably link individual patches in a\npatchset to their precedent in a previous series. This would make\nlooking at the evolution of individual patches over time more feasible.\n\n>> In this case, the \"prior\" link would point to the last revision of\n>> a patch. Tools would probably\n>> \n>>\n>\n>Probably what...???\n> \n>\n\n...probably support this as an explicit operation - ie \"publish\", so\nthat winding whilst developing is not tracked.\n\n>> 3. sub-projects\n>>\n>> In this case, the commit on the \"main\" commit line would have a\n>> \"prior\" link to the commit on the sub-project. The sub-project\n>> would effectively be its own head with copied commits objects on\n>> the main head.\n>> \n>>\n>\n>You say you can have only one \"prior\" per commit, which makes\n>this unsuitable to bind multiple subprojects into a larger\n>project (the earlier \"bind\" proposal allows zero or more).\n> \n>\n\nIt would still support that. Each commit to the sub-project involves a\nchange to the tree of the \"main\" commit line (a copy of the commit into\na sub-directory of it). The advantage is that the \"tree\" in the main\ncommit is the combined tree, you don't need to treat the case specially\nto just get the contents out.\n\nThis is kind of like how SVK works by default - you have one local\nrepository, inside which you track remote repositories. Each commit on\nthe upstream repository is copied individually into your own repository.\nSo your local repository numbers easily reach into tens of thousands\n(small numbers in git land, I know) while the upstream revisions are\njust in the thousands.\n\n>There may be some narrower concrete use case for which you can\n>devise coherent semantics, and teach tools and humans how to\n>interpret such inter-commit relationship that are _not_\n>parent-child ancestry. For example, if you have one special\n>link to point at a \"cherry-picked\" commit, rebasing _could_ take\n>advantage of it. When your side branch tip is at D, and commit\n>D has \"this was cherry-picked from commit E\" note, and if you\n>are rebasing your work on top of F:\n>\n> A---B---C---D\n> /\n> o---o---E---F\n>\n>the tool can notice that F can reach E and carry forward only A,\n>B, and C on top of F, omitting D. So having such a link might\n>be useful. But if that is what you are going to do, I do not\n>think you would want to conflate that with other inter-commit\n>relationships, such as \"previous hydra cap\".\n> \n>\n\nRight, I see the problem, a strong argument for a more generic solution\nas you presented.\n\nSam.\n"},{"id":"19132","messageId":"e2mv30$k08$1@sea.gmane.org","threadId":"3962","inReplyTo":"444EAE7C.5010402@vilain.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T05:06:05Z","receivedAt":"2006-04-26T05:06:05Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> Junio C Hamano wrote:\n\n>>> 3. sub-projects\n>>>\n>>> In this case, the commit on the \"main\" commit line would have a\n>>> \"prior\" link to the commit on the sub-project. The sub-project\n>>> would effectively be its own head with copied commits objects on\n>>> the main head.\n>>>\n>>\n>>You say you can have only one \"prior\" per commit, which makes\n>>this unsuitable to bind multiple subprojects into a larger\n>>project (the earlier \"bind\" proposal allows zero or more).\n> \n> It would still support that. Each commit to the sub-project involves a\n> change to the tree of the \"main\" commit line (a copy of the commit into\n> a sub-directory of it). The advantage is that the \"tree\" in the main\n> commit is the combined tree, you don't need to treat the case specially\n> to just get the contents out.\n\nAs far as I understand, for subproject commit \"bind\" link (and perhaps the\nkeyword/name \"link\" or \"ref\" would be better than \"related\") point to other\nsubprojects commits (trees), while the Sam's \"prior (3)\" example link would\npoint to the toplevel project (gathering all subprojects) commit, and it\nwould probably be named/noted \"toplevel\", not \"prior\".\n\nAm I correct?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19133","messageId":"e2n01t$m8j$1@sea.gmane.org","threadId":"3962","inReplyTo":"e2mv30$k08$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T05:22:34Z","receivedAt":"2006-04-26T05:22:34Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> [...] Sam's \"prior (3)\" example\n> link would point to the toplevel project (gathering all subprojects)\n> commit, and it would probably be named/noted \"toplevel\", not \"prior\".\n\nOr \"master\" (like \"master document\" in DTP).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19134","messageId":"7vzmi8sxt1.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2n01t$m8j$1@sea.gmane.org","subject":"[OT] Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-26T05:36:26Z","receivedAt":"2006-04-26T05:36:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Jakub Narebski wrote:\n>\n>> [...] Sam's \"prior (3)\" example\n>> link would point to the toplevel project (gathering all subprojects)\n>> commit, and it would probably be named/noted \"toplevel\", not \"prior\".\n>\n> Or \"master\" (like \"master document\" in DTP).\n\n(Offtopic) isn't \"master\" in DTP more like template?\n"},{"id":"19136","messageId":"e2n4am$1vn$1@sea.gmane.org","threadId":"3962","inReplyTo":"7vzmi8sxt1.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [OT] Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T06:35:32Z","receivedAt":"2006-04-26T06:35:32Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> Jakub Narebski wrote:\n>>\n>>> [...] Sam's \"prior (3)\" example\n>>> link would point to the toplevel project (gathering all subprojects)\n>>> commit, and it would probably be named/noted \"toplevel\", not \"prior\".\n>>\n>> Or \"master\" (like \"master document\" in DTP).\n> \n> (Offtopic) isn't \"master\" in DTP more like template?\n\nWell, in (La)TeX \"master document\" is a document on it's own rights,\nsubdocuments are transcluded using some kind of \"include\"-like command.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19137","messageId":"7vlktssudl.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2n4am$1vn$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-26T06:50:30Z","receivedAt":"2006-04-26T06:50:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> Jakub Narebski writes:\n>> \n>>> Jakub Narebski wrote:\n>>>\n>>>> [...] Sam's \"prior (3)\" example\n>>>> link would point to the toplevel project (gathering all subprojects)\n>>>> commit, and it would probably be named/noted \"toplevel\", not \"prior\".\n>>>\n>>> Or \"master\" (like \"master document\" in DTP).\n>> \n>> (Offtopic) isn't \"master\" in DTP more like template?\n>\n> Well, in (La)TeX \"master document\" is a document on it's own rights,\n> subdocuments are transcluded using some kind of \"include\"-like command.\n\n(Offtopic) Ah, the hard-core stuff. I had something else in\nmind (\"master page\" in \"DTP for dummies\"), sorry for the\nconfusion.\n\n(On topic again)\n\nLink from subproject commit back to the toplevel might work for\nsome kind of subprojects, but it would not work for the\nsubproject support that frequently comes up on this list. The\ndevelopment of an embedded Linux device, where a Linux kernel\nsource tree is grafted at kernel/ subdirectory of the toplevel\nproject. The \"prior\" link would be placed in the commit that\nbelong to the kernel subproject, but that would never be merged\nto the Linus kernel (why should he care about one particular\nembedded device's development history). The link must go from\nthe toplevel to generic parts reusable out of the context of the\ncombined project.\n"},{"id":"19138","messageId":"444F1859.8040504@vilain.net","threadId":"3962","inReplyTo":"e2mv30$k08$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-26T06:51:05Z","receivedAt":"2006-04-26T06:51:05Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jakub Narebski wrote:\n\n>>It would still support that. Each commit to the sub-project involves a\n>>change to the tree of the \"main\" commit line (a copy of the commit into\n>>a sub-directory of it). The advantage is that the \"tree\" in the main\n>>commit is the combined tree, you don't need to treat the case specially\n>>to just get the contents out.\n>> \n>>\n>\n>As far as I understand, for subproject commit \"bind\" link (and perhaps the\n>keyword/name \"link\" or \"ref\" would be better than \"related\") point to other\n>subprojects commits (trees), while the Sam's \"prior (3)\" example link would\n>point to the toplevel project (gathering all subprojects) commit, and it\n>would probably be named/noted \"toplevel\", not \"prior\".\n>\n>Am I correct?\n> \n>\n\nI don't think you quite get my meaning.\n\nWhat I'm saying is that with the right kind of general purpose relation\nbetween commits, you don't need \"bind\" at all.\n\nFirstly, you would have your sub-project as its own commit line. That is\na fairly straightforward thing.\n\nSecondly, the project that includes it has a corresponding commit for\neach commit on the sub-project. This commit changes the portion of the\nouter project's tree where the sub-project is bound.\n\nThis means that you don't need to understand this \"bind\" relation to be\nable to extract the tree, and keeps the model simple at the expense of\nan extra tree object or three per commit. It also does not restrict the\nmanner of the \"binding\", porcelains or users are free to do it\nselectively, for instance.\n\nActually there is large similarity to this and cherry-picking. In\nessence you're cherry picking every single commit from a different\ncommit heirarchy, except that you are applying the patches into a\nsub-directory.\n\nSam.\n"},{"id":"19139","messageId":"e2n72h$aqe$1@sea.gmane.org","threadId":"3962","inReplyTo":"7vlktssudl.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T07:22:23Z","receivedAt":"2006-04-26T07:22:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> (On topic again)\n> \n> Link from subproject commit back to the toplevel might work for\n> some kind of subprojects, but it would not work for the\n> subproject support that frequently comes up on this list. The\n> development of an embedded Linux device, where a Linux kernel\n> source tree is grafted at kernel/ subdirectory of the toplevel\n> project. The \"prior\" link would be placed in the commit that\n> belong to the kernel subproject, but that would never be merged\n> to the Linus kernel (why should he care about one particular\n> embedded device's development history). The link must go from\n> the toplevel to generic parts reusable out of the context of the\n> combined project.\n\nYes, I guess subproject support is most needed for the \"third-party embedded\n(sub)project\", when one sometimes have to modify (sub)project files, and\nperhaps have to watch for the (sub)project version. Hmmm... if one used\nTailor (to allow for projects not managed under GIT, though I wonder if it\nwould be possible to link up project without [externally available] SCM)\none could use this approach for managing distribution packages, like RPMS\nor debs...\n\nDo I understand correctly that toplevel (master project) commits have tree\nwhich points to combined tree, and \"bind\" links which points to the\nsubprojects commits whose trees make up the overall tree, or does the\nmaster tree points to tree containing only toplevel files (overall Makefile\nfor example, INSTALL or README for the whole project including\nsubprojects,...)?\n\n\nBTW. I have lately stumbled upon (somewhat Vault and Subversion biased)\n http://software.ericsink.com/Beyond_CheckOut_and_CheckIn.html\nRead about Share and Pin -- it's about subprojects (when you edit out the\nflawed \"branch as folder\" approach of author). I wonder if it could be\neasily implemented in \"subprojects for GIT\" proposal... Of course we can do\nbetter, i.e. original subproject repository doesn't need to be on the same\nmachine, we can use remote repository.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19140","messageId":"7virowrd1y.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2n72h$aqe$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-26T07:50:01Z","receivedAt":"2006-04-26T07:50:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Do I understand correctly that toplevel (master project) commits have tree\n> which points to combined tree, and \"bind\" links which points to the\n> subprojects commits whose trees make up the overall tree, or does the\n> master tree points to tree containing only toplevel files (overall Makefile\n> for example, INSTALL or README for the whole project including\n> subprojects,...)?\n\nThe plan for \"bind commit\" was to have the toplevel commit to\ncontain:\n\n\ttree -- this covers the whole tree including subprojects\n parent -- list of parents in the toplevel project\n bind -- commit object name of subproject, plus which\n\t directory to graft its tree onto.\n\nAnd a subproject commit, unless it contains subsubproject, would\nlook like just an ordinary commit. Its tree would match the\nentry in the tree the toplevel commit at the path in \"bind\" line\nof the top-level commit.\n\nSome reading material, from newer to older:\n\n * http://www.kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=Subpro.txt\n\n This talks about the overall \"vision\" on how the user-level\n interaction might look like, with a sketch on how the core-level\n would help Porcelain to implement that interaction. Most of the\n core-level support described there is in the \"bind commit\"\n changes, except \"update-index --bind/-unbind\" to record the\n information on bound subprojects in the index file.\n\n * http://thread.gmane.org/gmane.comp.version-control.git/15072\n\n This was the thread that led to the above proposal.\n\n * http://thread.gmane.org/gmane.comp.version-control.git/14486\n\n This is older. It touches an alternative \"gitlink\" approach,\n which I meant to prototype but never got around to.\n\n Surprisingly, these two threads are mostly noise-free and\n literally every message is worth reading.\n\nSome old but working core-side code is available at jc/bind\nbranch of public git.git repository.\n\n> BTW. I have lately stumbled upon (somewhat Vault and Subversion biased)\n> http://software.ericsink.com/Beyond_CheckOut_and_CheckIn.html\n> Read about Share and Pin -- it's about subprojects (when you edit out the\n> flawed \"branch as folder\" approach of author).\n\nNot really. You can easily do that by checking out another\nproject in a separate subdirectory.\n\nMy private working area for git.git is structured like this:\n\n\t/home/junio/git.junio/.git\n \t\t Makefile\n COPYING\n Documentation/\n ...\n Meta/.git\n Meta/TODO\n Meta/Make\n Meta/TO\n Meta/WI\n ...\n\nNotice two .git directories? That's right. \n\nThe top-level .git repository has the familiar branches like\n\"maint\", \"master\", \"next\", \"pu\", in addition to various topic\nbranches.\n\nMeta/.git is a separate repository that is a clone of \"todo\"\nbranch of git.git repository. The top-level .git repository\ndoes not even have \"todo\" branch. I just happen to push into\nthe same public repository git.git at kernel.org from these two\nseparate repositories.\n\nThe Meta/ repository is \"pinned\" to a specific version, without\nhaving any funky \"Pin feature\", no thank you, because I have\nfull control of when I update what is checked out in the Meta/\ndirectory.\n\nWhat you _might_ want is a reverse of Pinning. Sometimes, you\nwould want to make sure subproject part is at least this version\nor later to build other parts of the whole.\n\nBut for my particular \"Meta/\" directory, I do not need such a\nlinkage. The major reason I do not keep TODO in the main\nproject is because it is supposed to be a task list for me\nacross \"maint\", \"master\" and \"next\". I do not want it to\nfluctuate whenever I work on different branches.\n\n-jc\n"},{"id":"19142","messageId":"e2nbrl$p6l$1@sea.gmane.org","threadId":"3962","inReplyTo":"7virowrd1y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T08:44:03Z","receivedAt":"2006-04-26T08:44:03Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> BTW. I have lately stumbled upon (somewhat Vault and Subversion biased)\n>> http://software.ericsink.com/Beyond_CheckOut_and_CheckIn.html\n>> Read about Share and Pin -- it's about subprojects (when you edit out the\n>> flawed \"branch as folder\" approach of author).\n\nBy the way I mentioned this link only because it *might* be interesting what\nothers need subproject support for and how others think of it and implement\nit.\n\n> Not really. You can easily do that by checking out another\n> project in a separate subdirectory.\n> \n> My private working area for git.git is structured like this:\n> \n> /home/junio/git.junio/.git\n> Makefile\n> COPYING\n> Documentation/\n> ...\n> Meta/.git\n> Meta/TODO\n> Meta/Make\n> Meta/TO\n> Meta/WI\n> ...\n> \n> Notice two .git directories? That's right.\n[...] \n> Meta/.git is a separate repository that is a clone of \"todo\"\n> branch of git.git repository. The top-level .git repository\n> does not even have \"todo\" branch. I just happen to push into\n> the same public repository git.git at kernel.org from these two\n> separate repositories.\n\nAnd top-level .git repository is told to ignore Meta directory?\n\nInteresting idea...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19143","messageId":"7v7j5cr8ub.fsf@assigned-by-dhcp.cox.net","threadId":"3962","inReplyTo":"e2nbrl$p6l$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-26T09:21:00Z","receivedAt":"2006-04-26T09:21:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n>> Notice two .git directories? That's right.\n> [...] \n>> Meta/.git is a separate repository that is a clone of \"todo\"\n>> branch of git.git repository. The top-level .git repository\n>> does not even have \"todo\" branch. I just happen to push into\n>> the same public repository git.git at kernel.org from these two\n>> separate repositories.\n>\n> And top-level .git repository is told to ignore Meta directory?\n\nYes, I have .git/info/exclude that says something like this:\n\n/.mailmap\n*~\n/Meta\n+*\n"},{"id":"19144","messageId":"e2neen$4mp$1@sea.gmane.org","threadId":"3962","inReplyTo":"7virowrd1y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T09:28:21Z","receivedAt":"2006-04-26T09:28:21Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> And a subproject commit, unless it contains subsubproject, would\n> look like just an ordinary commit. Its tree would match the\n> entry in the tree the toplevel commit at the path in \"bind\" line\n> of the top-level commit.\n> \n> Some reading material, from newer to older:\n> \n> * http://www.kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=Subpro.txt\n> \n> This talks about the overall \"vision\" on how the user-level\n> interaction might look like, with a sketch on how the core-level\n> would help Porcelain to implement that interaction. Most of the\n> core-level support described there is in the \"bind commit\"\n> changes, except \"update-index --bind/-unbind\" to record the\n> information on bound subprojects in the index file.\n\nBy the way, this file talks about (1) \"using\"/\"userspace\"/\"embedder\"\nsubproject holding 'appliance/', and toplevel (master) holding toplevel\nMakefile, or (2) 'using' subproject holding both 'appliance/' and toplevel\nMakefile with the help of --exclude. \n\nAnother option would be to have only \"embedded\"/\"used\"/\"requirement\" be\nsubproject holding 'kernel-2.6', and 'appliance/' hold by toplevel (master)\ncommit. Perhaps not the best solution for 'kernel + userspace tools'\nexample, but might be better workflow for 'application + library' or\n'application + engine' example. \n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19148","messageId":"444F58B0.6090603@op5.se","threadId":"3962","inReplyTo":"BAYC1-PASMTP086A906CFB378AB229C2D8AEBF0@CEZ.ICE","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-26T11:25:36Z","receivedAt":"2006-04-26T11:25:36Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"sean wrote:\n> On Tue, 25 Apr 2006 08:40:25 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n> \n>>On Tue, 25 Apr 2006, Linus Torvalds wrote:\n>>\n>>>I want the git objects to have clear and unambiguous semantics. I want \n>>>people to be able to explain exactly what the fields _mean_. No \"this \n>>>random field could be used this random way\" crud, please.\n>>\n>>Btw, if the whole point is a \"leave random porcelain a field that they can \n>>use any way they want\", then I say \"Hell NO!\".\n>>\n>>Random porcelain can already just maintain their own lists of \"related\" \n>>stuff, any way they want: you can keep it in a file in \".git/porcelain\", \n>>called \"list-commit-relationships\", or you could use a git blob for it and \n>>have a reference to it in .git/refs/porcelain/relationships or whatever. \n>>\n>>If it has no clear and real semantic meaning for core git, then it \n>>shouldn't be in the core git objects.\n>>\n>>The absolute last thing we want is a \"random out\" that starts to mean \n>>different things to different people, groups and porcelains.\n>>\n>>That's just crazy, and it's how you end up with a backwards compatibility \n>>mess five years from now that is totally unresolvable, because different \n>>projects end up having different meanings or uses for the fields, so \n>>converting the database (if we ever find a better format, or somebody \n>>notices that SHA1 can be broken by a five-year-old-with-a-crayon).\n>>\n>>There's a reason \"minimalist\" actually ends up _working_. I'll take a UNIX \n>>\"system calls have meanings\" approach over a Windows \"there's fifteen \n>>different flavors of 'open()', and we also support magic filenames with \n>>specific meaning\" kind of thing.\n>>\n> \n> \n> It's a fair point. But adding a separate database to augment the core \n> information has some downsides. That is, that information isn't pulled, \n> cloned, or pushed automatically; it doesn't get to ride for free on top \n> of the core.\n> \n> Accommodating extra git headers (or \"note\"'s in Junio's example) would allow\n> a developer to record the fact that he is integrating a patch taken \n> from a commit in the devel branch and backporting it to the release \n> branch. Either by adding a note that references the bug tracking #, or \n> a commit sha1 from the devel branch that is already associated with the bug.\n> \n\nThis information is something I, as a human, would definitely want to \nread. What's the point of recording it in the commit-header if we're not \ngoing to show it to users anyway? I'm with Linus on this one. Keep \nheaders as simple as possible.\n\n> Of course that information could be embedded in the free text area, but \n> you yourself have argued vigorously that it is brain damaged to try and rely\n> on parsing free form text for these types of situations.\n\nWhy would there be a need to parse it? The entire *point* of history is \nto present it to readers in an as accessible and understandable way as \npossible. Git's sha1 hashes mean absolutely nothing, so a note saying \nsomething was cherry-picked from commit \n\"89987987ad987aef987987aff987987d\" on branch \"devel\" will be pointless \nunless the one doing the committing states the why as well as the what \nin the commit-message anyways.\n\nBesides, only developers will likely ever look at the commit-messages, \nand they will likely only ever do it when they are bisecting or looking \nfor the implementation date of a certain feature or other.\n\n> Most of the potential \n> uses aren't really meant for a human to read while looking at the log anyway, \n> they just get in the way.\n\nI still fail to see a use case for this. Could you give me some examples \nto when information recorded isn't meant for being presented to the user?\n\n> \n> But if the information is in the actual commit header it gets to tag along\n> for free with never any worry it will be separated from the commit in question.\n> So when the developer above updates his official repo the bug tracker system \n> can notice that the bug referenced in its system has had a patch backported \n> and take whatever action is desired. \n> \n\nWe already have something like this. All commits with a top-line message \ncontaining \"bug #\" followed by a number automatically updates our \nbugtracking system with the commit-message in its entirety. If the word \nbefore \"bug #\" matches \"fix.*\" then the status of the bug is set to that.\n\nThis might seem cumbersome to some but it's really very straightforward, \nand for a couple of reasons it's a very good solution:\n1. Devs who Do It Right don't have to fiddle with their browser just to \nenter the info twice, so they learn fast. :)\n2. BT history (viewed by non-devs too) gets updated with accurate \ninformation promptly.\n3. No matter how you solve the problem you're going to need to write a \ncustom commit/update hook anyway, so this is as good as having the info \nin the note.\n4. The info going to the BT is easily modifiable, so if someone screws \nup they can fix it later. Fixing an already written git commit takes \nsome doing if there are commits on top.\n\n> Of course there are other ways to do this, but integrating it into git means it\n> gets a free ride on the core, and it shouldn't really get in the way of core \n> any more than email X- headers get in the way of email flowing.\n> \n\nTrue. I've suggested before that arbitrary headers could be added to git \ncommits by prefixing them with X- (preferrably followed by an abbrev of \nthe porcelain name adding the note). This way it's easy to filter, you \nget the free ride, and porcelains can do whatever they want while core \ngit can strip everything following the sequence \"\\nX-\" up to and \nincluding the next newline.\n\nThis way you have only one special byte-sequence with special meaning \nthat the plumbing has to know it should ignore, which is a lot more \nextensible (not to mention easier to code).\n\nIn addition, if those X- lines aren't included in the sha1 computation \nthey can easily be removed and added to without affecting the ancestry \nchain. This would probably have quite a performance impact though.\n\nThat said, I don't think even \"X-\" headers is a very good idea. Perhaps \ni've just got poor imagination but I can't think of a good use for them.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"19150","messageId":"e2nne7$4sp$1@sea.gmane.org","threadId":"3962","inReplyTo":"444F58B0.6090603@op5.se","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T12:01:41Z","receivedAt":"2006-04-26T12:01:41Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> I've suggested before that arbitrary headers could be added to git\n> commits by prefixing them with X- (preferrably followed by an abbrev of\n> the porcelain name adding the note). This way it's easy to filter, you\n> get the free ride, and porcelains can do whatever they want while core\n> git can strip everything following the sequence \"\\nX-\" up to and\n> including the next newline.\n> \n> This way you have only one special byte-sequence with special meaning\n> that the plumbing has to know it should ignore, which is a lot more\n> extensible (not to mention easier to code).\n> \n> In addition, if those X- lines aren't included in the sha1 computation\n> they can easily be removed and added to without affecting the ancestry\n> chain. This would probably have quite a performance impact though.\n> \n> That said, I don't think even \"X-\" headers is a very good idea. Perhaps\n> i've just got poor imagination but I can't think of a good use for them.\n\nWell, the \"note\" headers are just that, but instead of prefixing 'extra'\nheaders with \"X-\" you prefix them with \"note \".\n\nI think that the \"note\" (or X-) headers should be included in calculating\nsha1, as the free-form of commit (the comment) is.\n\nAs to use: for now 'git cherry-pick' and 'git revert' records the commit\npicked or commit reverted in free form. It could be recorded in \"note\"\nheader, or additionally as \"note\" header. 'git rebase' could also record\nthe original commit e.g. as \"note original \".\n\nAnd it would be the place for Porcelain to record simple information which\nis of use to them, but usualy not interesting to user, so it would be\nbetter if it wouldn't pollute free-form/comment area.\n\n\nThe \"prior\" (for saving \"pu\"-like branches previous state) and \"bind\" (for\nmanaging subprojects) I think should be rather of \"related\"/\"link\" kind.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19152","messageId":"e2nprc$cie$1@sea.gmane.org","threadId":"3962","inReplyTo":"7vslo1v4zw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-26T12:42:51Z","receivedAt":"2006-04-26T12:42:51Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> My initial 'related' without 'note' was flawed - it used\n> cherry-pick as an example of 'related' when it clearly should\n> have been 'note' (no connectivitiy required).\n[...]\n> There definitely needs to be an ability to specify a list of\n> \"nature of links this repository accepts\", if we were to do\n> 'link'. It probably should default to an empty set. rev-list\n> --objects would include objects pointed by 'link' only when the\n> repository wants such links to be honored. fsck-objects will\n> declare an object that is reachable only by a 'link' that is not\n> accepted by the repository \"uninteresting\" and let git-prune\n> remove it.\n\nI think that perhaps connectivity should be more fine-grained than this.\nNamely we might want links which are not fsck-able nor pulled (and can be\ndangling), but will prevent object pointed from being pruned. The\n\"original\" (or \"cherrypick\") relation comes to mind.\n\nOf course that can be configured per repository...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19253","messageId":"e2vuuj$nhp$1@sea.gmane.org","threadId":"3962","inReplyTo":"e2kset$lk2$1@sea.gmane.org","subject":"Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-29T14:59:12Z","receivedAt":"2006-04-29T14:59:12Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> \n>> Jakub Narebski writes:\n>> \n>>> Actually, this can be resolved using automatic history grafts to the\n>>> remote repository we pulled from, if the commit is not present on local\n>>> side (and removing graft when commit appears on local side).\n>> \n>> You do not even need history grafts. The \"cherry-pick source\"\n>> was a bad example. Maybe using \"related\" as a way to implement\n>> \"bind\" would have been a better example -- we want inter-commit\n>> relationship that requires connectivity but without ancestry for\n>> them.\n>> \n>> You can just have two kinds of 'related'. One that means\n>> connectivity, the other that does not.\n> \n> Good idea.\n> \n> Another problem for core git, but I think orthogonal to the\n> \"related\"/\"note\" distinction is if the relation (or note) should be used\n> as helper in merges, perhaps by some agreed upon convention on the\n> comment/description/value part (e.g. \"mergehelper\" or \"mergeinfo\").\n\nScratch that. It would be better for merge strategy just to check for\ndefined set of \"links\" and \"notes\", e.g. \"prior\" (pu-prior) and\n\"original\" (cherrypick).\n\nBut there would be problem with connectivity provided by \"link\" relations,\nnamely info/grafts file, which deal only with parents. For example when we\ncauterize history using grafts (e.g. for shallow clone) the \"link\" like\n\"prior\" reaching to the cut-off part of the history might make your day ;-)\n\nWell, we could always drop all the connectivity, and make\n link sha1 description...\nshortcut for\n note link sha1 description...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"}]}