{"thread":{"id":"3114","subject":"What is in git.git","startedAt":"2006-01-21T08:03:12Z","lastAt":"2006-01-24T01:52:42Z","messageCount":14,"participants":["Junio C Hamano","Alexander Litvinov","Josef Weidendorfer","Petr Baudis","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14972","messageId":"7v3bjiuhxb.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":null,"subject":"What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T08:03:12Z","receivedAt":"2006-01-21T08:03:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The \"bind commit\" experiments for subproject support is coming\nalong rather nicely.  Near the tip of the \"pu\" branch, there\nare:\n\n - read-tree --prefix;\n - write-tree --prefix and write-tree --exclude;\n - commit-tree --bind;\n - fsck-objects and convert-objects that understand \"bind\" lines\n   in commit objects;\n - rev-list --objects that understand \"bind\" lines\n   in commit objects;\n\nI think the first four are more-or-less well debugged.\n\nI am reasonably confident that I did not break rev-list for\nrepositories without \"bind\" commits, but I have no clue how\ncorrect it is when dealing with commits with \"bind\" lines.  This\nis the last major remaining piece of the puzzle, and the rest is\njust the matter of scripting.  I'd be sending out a request for\nhelp on the rev-list in a separate message.\n\nThere still is no barebone Porcelainish work done using these\nchanges.  The attached script demonstrates a superproject that\nbinds two subprojects with their own development histories.\n\n-- >8 --\n#!/bin/sh\nrm -fr .git\ngit init-db\n: >main\nfor i in 1 2\ndo\n\techo \"Version #$i of primary subproject\" >main\n\tgit add main\n\tgit commit -a -m \"`cat main`\"\n\tgit tag main-$i\ndone\ngit branch main\nrm -f .git/refs/heads/master .git/index\n\nmkdir dir\n: >sub1\n: >dir/sub2\nfor i in A B C\ndo\n\techo \"subproject sub1 ($i)\" >sub1\n\techo \"subproject dir/sub2 ($i)\" >dir/sub2\n\tgit add sub1 dir/sub2\n\tgit commit -a -m \"subproject #$i\"\n\tgit tag subpro-$i\ndone\ngit branch subpro\nrm -fr dir sub1 main\nrm -f .git/refs/heads/master .git/index\n\ngit read-tree main-1\ngit read-tree --prefix=sub/ subpro-A\ntoptree=`git write-tree`\ntopcommit=$(echo \"Initial top commit\" |\ngit commit-tree $toptree \\\n\t--bind `git rev-parse --verify main-1` / \\\n\t--bind  `git rev-parse --verify subpro-A` sub/)\necho $topcommit >.git/refs/heads/master\ngit tag top-1A\n\ngit read-tree main-1\ngit read-tree --prefix=sub/ subpro-B\ntoptree=`git write-tree`\ntopcommit=$(echo \"Second top commit\" |\ngit commit-tree $toptree \\\n\t-p `git rev-parse --verify top-1A` \\\n\t--bind `git rev-parse --verify main-1` / \\\n\t--bind  `git rev-parse --verify subpro-B` sub/)\necho $topcommit >.git/refs/heads/master\ngit tag top-1B\n\ngit read-tree main-2\ngit read-tree --prefix=sub/ subpro-C\ntoptree=`git write-tree`\ntopcommit=$(echo \"Third top commit\" |\ngit commit-tree $toptree \\\n\t-p `git rev-parse --verify top-1B` \\\n\t--bind `git rev-parse --verify main-2` / \\\n\t--bind  `git rev-parse --verify subpro-C` sub/)\necho $topcommit >.git/refs/heads/master\ngit tag top-2C\n\ngit log\n\ngit rev-list --objects top-1A..top-2C |\ngit name-rev --tags --stdin\n"},{"id":"14978","messageId":"200601211633.03479.lan@ac-sw.com","threadId":"3114","inReplyTo":"200601211524.03096.lan@ac-sw.com","subject":"Re: What is in git.git","fromName":"Alexander Litvinov","fromEmail":"lan@ac-sw.com","sentAt":"2006-01-21T10:33:03Z","receivedAt":"2006-01-21T10:33:03Z","isPatch":false,"sender":{"key":"lan@ac-sw.com","avatar":null},"body":"> 1. Can I bind some branch instead of tag (commit) ?\n> 2. Is it possible to commit changes of subpro's file in master branch into\n> subpro branch to make this changes visible to master-2 ?\n\nOne more comment: it seems to me it is not possible to make two branches on \nseparate subprojects with the same name.\n"},{"id":"14979","messageId":"200601211636.02340.lan@ac-sw.com","threadId":"3114","inReplyTo":"7v3bjiuhxb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What is in git.git","fromName":"Alexander Litvinov","fromEmail":"lan@ac-sw.com","sentAt":"2006-01-21T10:36:02Z","receivedAt":"2006-01-21T10:36:02Z","isPatch":false,"sender":{"key":"lan@ac-sw.com","avatar":null},"body":"Somehow first mail was not reached the list, resending it.\n\n> The \"bind commit\" experiments for subproject support is coming\n> along rather nicely.  Near the tip of the \"pu\" branch, there\n> are:\n...\n>\n> I think the first four are more-or-less well debugged.\n>\n> I am reasonably confident that I did not break rev-list for\n> repositories without \"bind\" commits, but I have no clue how\n> correct it is when dealing with commits with \"bind\" lines.  This\n> is the last major remaining piece of the puzzle, and the rest is\n> just the matter of scripting.  I'd be sending out a request for\n> help on the rev-list in a separate message.\n>\n> There still is no barebone Porcelainish work done using these\n> changes.  The attached script demonstrates a superproject that\n> binds two subprojects with their own development histories.\n\nI tested this with your script. It works well. But I have found some \ndownsides.\n\nsubpro and main are separate projects and master is the join of them. If I \nwant to modify subpro I have to checkout subpro branch, edit files. When I \nhave to got to master and bind new version of subpro to it. Worse, if I will \nedit subpro's files bined to master branch changes will go to master branch \ninstead of subpro's history. As a result all other project (imagine master-2) \nthat use subpro will lose this change.\n\n1. Can I bind some branch instead of tag (commit) ?\n2. Is it possible to commit changes of subpro's file in master branch into \nsubpro branch to make this changes visible to master-2 ?\n\nThanks for attention.\nAlexander Litvinov.\n"},{"id":"14993","messageId":"7vek31mkyg.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"200601211636.02340.lan@ac-sw.com","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T19:37:11Z","receivedAt":"2006-01-21T19:37:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I suspect there is an misunderstanding or two, because I did not\nrepeat what the other parts (Porcelain-ish) would do and\neverything fits together.  For that, you need to refer to a\ncouple of earlier messages from me on the \"RFC: Subprojects\"\nthread [*1*], and perhas use some imagination, because the\noutline I did back then was done without having much of what are\nin \"pu\" today and I may have got some details wrong.  The\nmessage you are responding to was to give a demonstation of the\ncurrent status of how the core part works.\n\nAlexander Litvinov <lan@ac-sw.com> writes:\n\n>> 1. Can I bind some branch instead of tag (commit) ?\n\nThe \"bind\" line describes relationship among specific points in\ndevelopment histories of subprojects and superprojects so it\nneeds to use commit object names.\n\nIf you mean by \"binding a branch\", to record how each subproject\nrelates to the toplevel project (i.e. \"the subproject bound to\nX/ subdirectory of the toplevel project comes from branch Y\"),\nthat information needs to be somewhere, but recording it in the\ncommit object goes against the whole git philosophy.\n\nBranch naming is a local matter.  \"master\" in my repository\nrepresents a different development history of the project from\nwhat your \"master\" does.  The subproject I happen to use the\n\"subpro\" branch to keep track of might be called \"sub\" in yours.\nRecording the name \"subpro\" on a \"bind\" line in a commit object\nmakes that commit object useless when you fetch such a commit\nfrom my repository.\n\n>> 2. Is it possible to commit changes of subpro's file in\n>> master branch into subpro branch to make this changes visible\n>> to master-2 ?\n\nYou are way ahead of what I am putting in \"pu\".  That is all\nresponsibility of the scripting part that use the core part;\nrefer to the outline in earlier messages on the subprojects\nthread.\n\nI think the above relates to this part of what you said:\n\n> subpro and main are separate projects and master is the join\n> of them. If I want to modify subpro I have to checkout subpro\n> branch, edit files. When I have to got to master and bind new\n> version of subpro to it.\n\nI do not see any problem with this.  The core level tools in\n\"pu\" supports that mode of operation.  They also support another\nmode of operation, checking out the whole thing and making a\ncommit for subprojects.\n\n> Worse, if I will edit subpro's files bined to master branch\n> changes will go to master branch instead of subpro's history.\n\nSimply untrue.\n\nEven though I will use present tense (e.g. \"the checkout command\nnotices\") in the following, you should remember that the current\nset of barebone Porcelainish scripts have not been taught about\nany of this.\n\nYou need to keep a file that describes how your repository is\ntracking the development histories of each subproject in\n$GIT_DIR/bind, that would look like:\n\n\tmaster main=/ subpro=sub/\n\nmeaning:\n\n\tIn this repository, the project whose history is kept\n\ttrack of by \"master\" branch binds the projects whose\n\thistory is kept track of by \"subpro\" branch at sub/ and\n\tanother project that holds the rest whose history is\n\tkept track by \"main\" branch.\n\nYou can have more than one branches for subprojects and the\ncombined project.  Just have more lines in $GIT_DIR/bind,\nlike so, to achieve that [*2*]:\n\n     master main=/ subpro=sub/\n     master20 main2=/ subpro=sub/\n     master02 main2=/ subpro2=sub/\n\t...\n\nTo work on the example project, there are two alternative\nworkflows that can be supported:\n\n1. You can be on \"master\" branch (i.e. checking out everything\n   at the right place), and make necessary changes, be they at\n   toplevel or sub/ directory.  \n\n   The checkout command notices you are on \"master\" branch, and\n   you are checking out a bound commit which has \"bind\" lines\n   for / and sub/ directories.  When committing, a single \"git\n   commit\" may make potentially three commits.  (1) If you want\n   to commit changes you made to sub/ part, that is committed to\n   \"subpro\" branch; (2) If you want to commit changes to the\n   rest, that is committed to \"main\" branch; (3) and a commit to\n   the \"master\" branch is made to record the state of the whole\n   thing.\n\n2. You can work on an individual subproject without bothering\n   the combined project.  You can have another repository to do\n   developments of the project this repository uses \"subpro\"\n   branch to keep track of.  When that work in the other\n   repository on a subproject is ready to be integrated into the\n   whole, you would fetch/merge the subproject part into this\n   repository from there, advancing \"subpro\" branch head in this\n   repository.\n\n   When this happens, you can notice that the commit on the\n   \"bind\" line for sub/ part does not match the branch head that\n   keeps track of that part of the tree (i.e. \"subpro\")\n   anymore, and can update sub/ part by merging.\n\n> One more comment: it seems to me it is not possible to make\n> two branches on separate subprojects with the same name.\n\nThis is precisely why I said \"the branch naming is a local\nissue\", and the commit object does not record branch name.  In\nthe above workflow #2, there is no reason for the other\nrepository that develops the sub/ subproject part to name its\nprimary branch \"subpro\".  Most likely it is named \"master\"\nthere, and the combined project would fetch its advancement by\nissuing:\n\n\t$ git fetch ../subprorepo master:subpro\n\nIf you have more than one branches in the other repository and\nwould want to use that instead, you would fetch from that branch\nnot from master there.\n\nYou can also keep more than one branch for a subproject inside\nthe combined repository and have more than one $GIT_DIR/bind\nlines that describe different superprojects that bind different\nbranches of the same subproject at the same location in the\ncorresponding superproject branch..\n\n\n[Footnote]\n\n*1* Here are a couple of key messages in the thread, that\nattempt to describe how the things would fit together:\n\n    http://article.gmane.org/gmane.comp.version-control.git/14781\n    http://article.gmane.org/gmane.comp.version-control.git/14809\n\n*2* Theoretically you could have NxMxOx... master project\nbranches for subprojects with N, M, O,... branches, but in\npractice, the combined project is an integration field, and most\nof the combinations are not something you are interested in.\n\nNot all of the N branches in a subproject need to be directly\nintegrated into the whole --- most of them are used only while\ncoming up with the version of the subproject that is suitable\nfor the integration.\n"},{"id":"15011","messageId":"7vu0bxjk5j.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"7vek31mkyg.fsf@assigned-by-dhcp.cox.net","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T22:22:48Z","receivedAt":"2006-01-21T22:22:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Alexander Litvinov <lan@ac-sw.com> writes:\n>...\n>> subpro and main are separate projects and master is the join\n>> of them. If I want to modify subpro I have to checkout subpro\n>> branch, edit files. When I have to got to master and bind new\n>> version of subpro to it.\n>\n> I do not see any problem with this....\n>...\n>> Worse, if I will edit subpro's files bined to master branch\n>> changes will go to master branch instead of subpro's history.\n>\n> Simply untrue.\n\nSorry, these came out somewhat in a wrong way, so let me\nclarify.\n\nWhat I meant was that there isn't anything coded so far that\nmakes your worries real issues yet, and I do not intend to code\nPorcelainish scripts that are broken in the ways you see as\nproblems in your message.\n\nThe point you raised are valid concerns.  You need to keep them\nin mind when you start writing subproject aware version of\ngit-checkout, git-commit and git-merge commands (among other\nthings I might have forgotten, but I think these three covers\npretty much everything).  You are welcome to beat me to it,\nsince I am not planning to do them right away.\n"},{"id":"15013","messageId":"200601220033.26321.Josef.Weidendorfer@gmx.de","threadId":"3114","inReplyTo":"7vek31mkyg.fsf@assigned-by-dhcp.cox.net","subject":"Re: What is in git.git","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-01-21T23:33:25Z","receivedAt":"2006-01-21T23:33:25Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 21 January 2006 20:37, you wrote:\n> Alexander Litvinov <lan@ac-sw.com> writes:\n> >> 1. Can I bind some branch instead of tag (commit) ?\n> ... \n> If you mean by \"binding a branch\", to record how each subproject\n> relates to the toplevel project (i.e. \"the subproject bound to\n> X/ subdirectory of the toplevel project comes from branch Y\"),\n> that information needs to be somewhere, but recording it in the\n> commit object goes against the whole git philosophy.\n\nThe original gitlink proposal did exactly this: it recorded\nthe place where a subproject is bound by putting a gitlink into\na tree. This way, the binding point can be changed, and is subject to\nversioning itself.\n\nI just realized that this is not currently possible with the bind lines.\nWhat about the following usage szenario:\n- in a superproject, I use a subproject X implementing some lib by \n  binding it at X/. My Makefile recurses into X/ for this.\n  This is recorded at commit point (A)\n- later on, I realize I need another lib from a probject Y; I want\n  to put the libs X and Y into subdirectory lib/ of my superproject;\n  i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.\n  The Makefile is changed accordingly to build the subprojects.\n  This is recorded at commit point (B)\n\nA $GITDIR/bind alone will no work, as moving back to (A) would keep\nthe binding point of subproject, and make is broken.\n\nI understand that \"moving binding point of X from X/ to lib/X/\" is not\nrepresentable within the index as a simple change. Is this the main issue\nfor your \"against the whole git philosophy\"?\n\nI think it still is quite useful to put the binding point into bind lines of the\ncommit. Of course, moving a binding point has to go together with a new commit.\n\n> You need to keep a file that describes how your repository is\n> tracking the development histories of each subproject in\n> $GIT_DIR/bind, that would look like:\n> \n> \tmaster main=/ subpro=sub/\n\nWhat about putting $GITDIR/bind information directly into reference files?\n\n $HOME/gitproj> cat .git/refs/heads/master\n 92347432598...\n bind main=/\n bind subpro=sub/\n\nThis way, you can rename/copy heads, and the binding info will stay with\nthe commit.\nThis also is nice for subprojects that do not need the bind lines, but similar\nto current cogito subproject proposal:\n\n  92347432598...\n  main=/\n  subpro=sub/\n\nwould be the same superproject/subproject configuration without commiting\nbind lines.\n\nJosef\n"},{"id":"15020","messageId":"7v64odj821.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"200601220033.26321.Josef.Weidendorfer@gmx.de","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T02:44:06Z","receivedAt":"2006-01-22T02:44:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> The original gitlink proposal did exactly this: it recorded\n> the place where a subproject is bound by putting a gitlink into\n> a tree. This way, the binding point can be changed, and is subject to\n> versioning itself.\n>\n> I just realized that this is not currently possible with the bind lines.\n> What about the following usage szenario:\n> - in a superproject, I use a subproject X implementing some lib by \n>   binding it at X/. My Makefile recurses into X/ for this.\n>   This is recorded at commit point (A)\n> - later on, I realize I need another lib from a probject Y; I want\n>   to put the libs X and Y into subdirectory lib/ of my superproject;\n>   i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.\n>   The Makefile is changed accordingly to build the subprojects.\n>   This is recorded at commit point (B)\n\nThe original gitlink proposal records commit object name in the\nlink object itself, so do bind lines in the commit object in\nbound commit proposal.  In either way, you need to deal with the\nsubproject relocation at the Porcelain level.\n\nI was hoping that, upon seeing these two commits (let's say we\nare dealing with two-way merge aka \"checkout\"):\n\n\tIn commit 1:\n\t\tbind xxxxx... X/\n\n\tIn commit 2:\n\t\tbind yyyyy... lib/X/\n                bind zzzzz... lib/Y/\n\nthe tool could notice that xxxxx... and yyyyy... are related in\ntheir ancestry chain, detect the relocation of subprojects, and\nupdate the $GIT_DIR/bind file (maybe with some help from the end\nuser).  We can do something similar in gitlink approach as well.\n\n> A $GITDIR/bind alone will no work, as moving back to (A) would keep\n> the binding point of subproject, and make is broken.\n\nI do not see why.  $GIT_DIR/bind can be adjusted by the tool\nupon checkout to reflect the reorganized tree.\n\n> What about putting $GITDIR/bind information directly into reference files?\n>\n>  $HOME/gitproj> cat .git/refs/heads/master\n>  92347432598...\n>  bind main=/\n>  bind subpro=sub/\n\nI think that would also work.  Although I do not immediately see\nmajor difference in expressiveness either way, that may be a\ncleaner way to achieve what we want to do.\n"},{"id":"15026","messageId":"20060122031237.GU28365@pasky.or.cz","threadId":"3114","inReplyTo":"200601220033.26321.Josef.Weidendorfer@gmx.de","subject":"Re: What is in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-22T03:12:37Z","receivedAt":"2006-01-22T03:12:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Just-in-case panic response...\n\nDear diary, on Sun, Jan 22, 2006 at 12:33:25AM CET, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > You need to keep a file that describes how your repository is\n> > tracking the development histories of each subproject in\n> > $GIT_DIR/bind, that would look like:\n> > \n> > \tmaster main=/ subpro=sub/\n> \n> What about putting $GITDIR/bind information directly into reference files?\n> \n>  $HOME/gitproj> cat .git/refs/heads/master\n>  92347432598...\n>  bind main=/\n>  bind subpro=sub/\n> \n> This way, you can rename/copy heads, and the binding info will stay with\n> the commit.\n\nPlease don't. I can see no real advantage to separate files (except for\nthe very rare case of rename/copy/removal of heads) except for massive\nporcelain breakage and significant clutter-up of all the code dealing\nwith refs.\n\nPlease leave our poor refs alone. :) They are fine as they are - simple\none-value thing.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"15040","messageId":"Pine.LNX.4.64.0601221106330.25300@iabervon.org","threadId":"3114","inReplyTo":"200601220033.26321.Josef.Weidendorfer@gmx.de","subject":"Re: What is in git.git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-01-22T17:53:51Z","receivedAt":"2006-01-22T17:53:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 22 Jan 2006, Josef Weidendorfer wrote:\n\n> On Saturday 21 January 2006 20:37, you wrote:\n> > Alexander Litvinov <lan@ac-sw.com> writes:\n> > >> 1. Can I bind some branch instead of tag (commit) ?\n> > ... \n> > If you mean by \"binding a branch\", to record how each subproject\n> > relates to the toplevel project (i.e. \"the subproject bound to\n> > X/ subdirectory of the toplevel project comes from branch Y\"),\n> > that information needs to be somewhere, but recording it in the\n> > commit object goes against the whole git philosophy.\n> \n> The original gitlink proposal did exactly this: it recorded\n> the place where a subproject is bound by putting a gitlink into\n> a tree. This way, the binding point can be changed, and is subject to\n> versioning itself.\n> \n> I just realized that this is not currently possible with the bind lines.\n> What about the following usage szenario:\n> - in a superproject, I use a subproject X implementing some lib by \n>   binding it at X/. My Makefile recurses into X/ for this.\n>   This is recorded at commit point (A)\n> - later on, I realize I need another lib from a probject Y; I want\n>   to put the libs X and Y into subdirectory lib/ of my superproject;\n>   i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.\n>   The Makefile is changed accordingly to build the subprojects.\n>   This is recorded at commit point (B)\n> \n> A $GITDIR/bind alone will no work, as moving back to (A) would keep\n> the binding point of subproject, and make is broken.\n\nI think you're misunderstanding the use of the \"bind\" file or equivalent. \nIt isn't a configuration file that specifies where the subprojects go; \nit's a state file that tracks where the subprojects currently are. The \ncommits by themselves are sufficient to indentify the locations of the \nsubprojects, and the bind file would be written by \"git checkout\" reading \na commit with subprojects. It's used to create the next commit, in much \nthe same way that MERGE_HEAD is used to create the next commit by storing \ninformation between the git call that starts a merge that needs user \ninteraction and the git call to commit the merge.\n\nSo moving back to (A) wouldn't keep the binding point of subproject, \nbecause it would rewrite bind to what it had been.\n\nI'm going to suggest again keeping this information in the index file (but \nnot in the index data structure, so the changes to the code are only in \nthe library routines to read and write the file, and, of course, anything \nthat's actually trying to manipulate the binding locations). I started \nworking on a patch to pu to skip S_IFDIR entries from the index file when \nbuilding the table in memory, and that was straightforward, but I got into \nsysadmin issues when I was going to test giving it something to skip.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15043","messageId":"7vu0bwdo08.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"Pine.LNX.4.64.0601221106330.25300@iabervon.org","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T20:08:23Z","receivedAt":"2006-01-22T20:08:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> I think you're misunderstanding the use of the \"bind\" file or equivalent. \n>...\n> So moving back to (A) wouldn't keep the binding point of subproject, \n> because it would rewrite bind to what it had been.\n\nA lot better said than my version of the response.  Thanks.\n\n> I'm going to suggest again keeping this information in the index file (but \n> not in the index data structure, so the changes to the code are only in \n> the library routines to read and write the file, and, of course, anything \n> that's actually trying to manipulate the binding locations). I started \n> working on a patch to pu to skip S_IFDIR entries from the index file when \n> building the table in memory, and that was straightforward, but I got into \n> sysadmin issues when I was going to test giving it something to skip.\n\nI have been thinking about this one, and having read that\nread-cache code I think the coding is not too involved.\n\nMy current inclination is to use the same version number (2) by\ndefault and promote it to a new version number (3) once you add\nsubproject-binding information to the index file.  Then current\ntools would keep working on repositories created or operated\nupon with the new tools, as long as the project does not use the\nnew feature.\n"},{"id":"15044","messageId":"Pine.LNX.4.64.0601221512470.25300@iabervon.org","threadId":"3114","inReplyTo":"7vu0bwdo08.fsf@assigned-by-dhcp.cox.net","subject":"Re: What is in git.git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-01-22T20:26:27Z","receivedAt":"2006-01-22T20:26:27Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 22 Jan 2006, Junio C Hamano wrote:\n\n> I have been thinking about this one, and having read that\n> read-cache code I think the coding is not too involved.\n> \n> My current inclination is to use the same version number (2) by\n> default and promote it to a new version number (3) once you add\n> subproject-binding information to the index file.  Then current\n> tools would keep working on repositories created or operated\n> upon with the new tools, as long as the project does not use the\n> new feature.\n\nI think bumping the index file version number shouldn't be too big a deal; \nindex files are rarely used by different versions, except for the case \nwhere you've installed a new version of git, and that's generally a later \nversion, not an earlier one.\n\nIt might make sense to add logic to make the stable series accept version \n3 files without special entries, though. And maybe future-proof by having \nit look for unexpected flags and give a \"too new version\" error for them, \neven if the version number is within range. (I.e., if we add more special \nentry types later, it would tell you if your index file uses a feature \nthat the version of git you're using doesn't support, even if the version \nnumber hasn't changed, and we reserve changing the version number for \nthings where the file wouldn't read right at all or something previously \nlegal changes meaning.)\n\nOn a side topic, is there any reason not to convert ls-tree to use struct\ntree, and kill the other tree-object-parsing code, which doesn't seem to \nbe used by anything else?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15046","messageId":"7vlkx8c86b.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"Pine.LNX.4.64.0601221512470.25300@iabervon.org","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T20:35:40Z","receivedAt":"2006-01-22T20:35:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On a side topic, is there any reason not to convert ls-tree to use struct\n> tree, and kill the other tree-object-parsing code, which doesn't seem to \n> be used by anything else?\n\nls-tree _might_ be doing something struct tree interface does\nnot support, but I do not know.\n\nIf you are inclined to, please go wild ;-).\n"},{"id":"15047","messageId":"7vbqy4c7vy.fsf@assigned-by-dhcp.cox.net","threadId":"3114","inReplyTo":"200601220033.26321.Josef.Weidendorfer@gmx.de","subject":"Re: What is in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T20:41:53Z","receivedAt":"2006-01-22T20:41:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> I understand that \"moving binding point of X from X/ to lib/X/\" is not\n> representable within the index as a simple change. Is this the main issue\n> for your \"against the whole git philosophy\"?\n\nNo.  I meant an exposure of local branch names by recording them\nin the commit object, and nothing else, by that comment.\n\nInstead of using an extra $GIT_DIR/bind file extending what we\nrecord in the index file is OK.  $GIT_INDEX_FILE, $GIT_DIR/HEAD,\nand $GIT_DIR/bind pretty much go hand-in-hand anyway and they\n_are_ local to the repository, just like branch names are, so I\ndo not have any problem with using local branch names in these\nplaces, but not in a commit object (or gitlink object for that\nmatter).\n"},{"id":"15076","messageId":"200601240252.42499.Josef.Weidendorfer@gmx.de","threadId":"3114","inReplyTo":"7v64odj821.fsf@assigned-by-dhcp.cox.net","subject":"Re: What is in git.git","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-01-24T01:52:42Z","receivedAt":"2006-01-24T01:52:42Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Sunday 22 January 2006 03:44, you wrote:\n> \tIn commit 1:\n> \t\tbind xxxxx... X/\n\nAh, OK, sorry.\nThis was a misunderstanding from my side; please forget the\nother suggestion about change reference files, too ;-)\n\nJosef\n"}]}