{"thread":{"id":"7633","subject":"Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","startedAt":"2007-04-12T22:43:23Z","lastAt":"2007-04-16T16:32:29Z","messageCount":15,"participants":["Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39238","messageId":"Pine.LNX.4.64.0704121533560.4061@woody.linux-foundation.org","threadId":"7633","inReplyTo":null,"subject":"Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-12T22:43:23Z","receivedAt":"2007-04-12T22:43:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nJunio, I've been running \"next\", because of working on the submodule \nstuff.\n\nI just did some trivial kernel stuff: applied seven patches, and tried to \ndo a \"pull\". And whoa, that failed. I get this:\n\n\t[torvalds@woody linux]$ dotest ~/doit\n\t7 patch(es) to process.\n\n\t.. all apply fine ..\n\n\t[torvalds@woody linux]$ git pull master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus\n\tremote: Generating pack...\n\t...\n\tUnpacking 22 objects\n\t 100% (22/22) done\n\tYour index is based on '80584ff3b99c36ead7e130e453b3a48b18072d18' commit, but the branch tip you are on is at '6a04de6dbe1772d98fddf5099738d6f508e86e21'\n\nThat \"80584ff..\" commit is the commit *before* the \"dotest\", and HEAD is \n(correctly) 6a04de.. that is the end result of the \"dotest\". That \"dotest\" \nthing is just because \"git-applymbox\" isn't in my brain stem:\n\n\t[torvalds@woody linux]$ alias dotest\n\talias dotest='git-applymbox -u'\n\nso it's not actually anything strange.\n\nDoing a \"git reset\" obviously fixed it, but if I didn't know that you had \nbeen working on that \"index BASE\" thing, I would have been very worried.\n\nThat index base thing is definitely *not* ready for merging into master \nyet!\n\n\t\tLinus\n"},{"id":"39243","messageId":"7virc1i443.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704121533560.4061@woody.linux-foundation.org","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-12T23:07:24Z","receivedAt":"2007-04-12T23:07:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That index base thing is definitely *not* ready for merging into master \n> yet!\n\nHeh, I know, as I even left applymbox unpatched (there is a\ntrivial change made to git-am which should be portable to\napplymbox) more or less on purpose to see if anybody noticed\n;-).\n\nI've sent messages to the list asking for help in testing and\nfixing for a handful times already, and, if we do not count\nShawn mentioning one glitch on #git, this is the first time\nanybody said anything about the series. I am kind of depressed\nthat you are bringing it up now.\n"},{"id":"39251","messageId":"7vbqhti0nr.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704121533560.4061@woody.linux-foundation.org","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T00:22:00Z","receivedAt":"2007-04-13T00:22:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That \"80584ff..\" commit is the commit *before* the \"dotest\", and HEAD is \n> (correctly) 6a04de.. that is the end result of the \"dotest\". That \"dotest\" \n> thing is just because \"git-applymbox\" isn't in my brain stem:\n>\n> \t[torvalds@woody linux]$ alias dotest\n> \talias dotest='git-applymbox -u'\n>\n> so it's not actually anything strange.\n\nThis will teach applymbox the index base safety, but it shows\nthat the division between applymbox and applypatch makes things\nless efficient than how git-am can do the same. In 5ddb93e that\nteaches the same to git-am, we need to deal with the index base\nonly once at the beginning to check and once at the end to\nupdate. applypatch being a separate program means we cannot do\nthat easily inside applymbox.\n\n-- >8 --\n[PATCH] Teach applypatch about the index base\n\nSigned-off-by: Junio C Hamano \n---\n git-applypatch.sh | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/git-applypatch.sh b/git-applypatch.sh\nindex 8df2aee..c6d88e4 100755\n--- a/git-applypatch.sh\n+++ b/git-applypatch.sh\n@@ -14,6 +14,8 @@\n USAGE=' []'\n . git-sh-setup\n \n+check_base || exit\n+\n case \"$#\" in 3|4) ;; *) usage ;; esac\n \n final=.dotest/final-commit\n@@ -205,6 +207,7 @@ parent=$(git-rev-parse --verify HEAD) &&\n commit=$(git-commit-tree $tree -p $parent <\"$final\") || exit 1\n echo Committed: $commit\n git-update-ref -m \"applypatch: $SUBJECT\" HEAD $commit $parent || exit\n+git update-index --set-base \"$commit\"\n \n if test -x \"$GIT_DIR\"/hooks/post-applypatch\n then\n-- \n1.5.1.1.772.gab9f7\n"},{"id":"39254","messageId":"Pine.LNX.4.64.0704121812440.4061@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7vbqhti0nr.fsf@assigned-by-dhcp.cox.net","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-13T01:15:40Z","receivedAt":"2007-04-13T01:15:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Apr 2007, Junio C Hamano wrote:\n> \n> This will teach applymbox the index base safety, but it shows\n> that the division between applymbox and applypatch makes things\n> less efficient than how git-am can do the same.\n\nHey, I'd happily use git-am too..\n\nIf you want to deprecare git-applymbox, why don't you just make it an \nalias for git-am, potentially doing the defaults and command line argument \nconversion?\n\nI certainly don't care about the *implementation* details. As long as my \nmailbox applicator continues to work ;)\n\n\t\t\tLinus\n"},{"id":"39257","messageId":"7vlkgxgc9d.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704121812440.4061@woody.linux-foundation.org","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T03:54:22Z","receivedAt":"2007-04-13T03:54:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 12 Apr 2007, Junio C Hamano wrote:\n>> \n>> This will teach applymbox the index base safety, but it shows\n>> that the division between applymbox and applypatch makes things\n>> less efficient than how git-am can do the same.\n>\n> Hey, I'd happily use git-am too..\n>\n> If you want to deprecare git-applymbox, why don't you just make it an \n> alias for git-am, potentially doing the defaults and command line argument \n> conversion?\n\nI'd rather not.\n\nThe whole reason I did not _enhance_ git-applymbox but wrote a\nseparate git-am was because I found git-applymbox's command line\nparameter quite insane and felt that supporting it at the same\ntime doing a saner command line parameter was too much kludge.\n"},{"id":"39261","messageId":"Pine.LNX.4.64.0704122115240.4061@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7vlkgxgc9d.fsf@assigned-by-dhcp.cox.net","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-13T04:16:25Z","receivedAt":"2007-04-13T04:16:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Apr 2007, Junio C Hamano wrote:\n> \n> The whole reason I did not _enhance_ git-applymbox but wrote a\n> separate git-am was because I found git-applymbox's command line\n> parameter quite insane and felt that supporting it at the same\n> time doing a saner command line parameter was too much kludge.\n\nHeh. I'll try to make my alias be\n\n\talias dotest='git-am --utf8'\n\nand see what happens ;)\n\n\t\tLinus\n"},{"id":"39262","messageId":"7vfy74hpog.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704122115240.4061@woody.linux-foundation.org","subject":"Re: Some index-base bug in \"next\" branch (\"git-applymbox\"-related?)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T04:19:11Z","receivedAt":"2007-04-13T04:19:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 12 Apr 2007, Junio C Hamano wrote:\n>> \n>> The whole reason I did not _enhance_ git-applymbox but wrote a\n>> separate git-am was because I found git-applymbox's command line\n>> parameter quite insane and felt that supporting it at the same\n>> time doing a saner command line parameter was too much kludge.\n>\n> Heh. I'll try to make my alias be\n>\n> \talias dotest='git-am --utf8'\n>\n> and see what happens ;)\n>\n> \t\tLinus\n\nYou should not need -u; it's default these days.\n"},{"id":"39386","messageId":"7vbqhp4diw.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704121533560.4061@woody.linux-foundation.org","subject":"Reverting the whole index-base series","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-15T19:56:55Z","receivedAt":"2007-04-15T19:56:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That index base thing is definitely *not* ready for merging into master \n> yet!\n\nI have been thinking about the approach using index-base to\nguard against somebody else updating the tip of branch you are\ncurrently on (let's call that \"gremlin updates (to the HEAD)\"\nfor lack of better wording). Unlike the earlier cache-tree\nbased write-tree optimization, it turns out to be an uphill\nbattle to make it an \"opt-in\" enhancement [*1*].\n\nThis is primarily because updating the branch tip is not tied\nclosely to writing out a commit, and writing out a commit is not\ntied closely to writing out a tree (to be contained in that\ncommit) out of the index.\n\nIf a command creates a commit that has HEAD as a parent, treats\nwhat is in the index as derived from HEAD, and/or modifies the\nindex and/or HEAD and leaves the index in a state suitable to\ncreate the next commit out of that has the HEAD commit as a\nparent, in order to make such a command aware of the index-base\nbased guard, the rules are:\n\n (1) You are relying on the index to be actually based on the\n HEAD you are going to record as one of the parents of the\n resulting commit. Hence, you need to make sure the HEAD\n agrees with the commit the current index is based on. The\n former can be read with 'rev-parse --verify HEAD', and the\n latter can be read from the BASE extension ('update-index\n --get-base').\n\n The design goal is not to require everybody to be\n index-base aware. So if the index does not record BASE,\n the check should succeed, assuming the HEAD has not been\n moved.\n\n (2) In order to leave the index in a state suitable to create\n the next commit out of that has the updated HEAD commit as\n a parent, you need to tell the next command that performs\n the check (1) which commit the index is based on. Use\n 'update-index --set-base' to record the commit you think\n the index is based on.\n\n The design goal again is not to require everybody to be\n index-base aware. Because most basic operations would not\n usually move HEAD when they update index, read_cache()\n followed by write_cache() can just keep the base if one is\n already recorded in the index, but read-tree by default\n invalidates the base, as any command that makes the index\n based on a different commit needs to lose the base by\n default (if the command is updated to be index-base aware,\n instead of losing the base, it would record the right base,\n of course).\n\nUpdating HEAD commit without changing the index can be done in\ntwo ways. Building on top of HEAD (write-tree then commit-tree\nthen update-ref), or changing the HEAD commit (using\nsymbolic-ref to switch branches). I do not think there is a\nsane way to make this \"opt-in\", and that is where recently\ntriggered problems come from (applymbox problem was noticed by\nLinus; I have a small patch for contrib/emacs/git.el, git-gui,\nquiltimport, and git-svn). If we make symbolic-ref and\nupdate-ref invalidate the base recorded in the index by default\nto avoid false positives, that would make the feature \"opt-in\",\nbut that would defeat the whole point of detecting gremlin\nupdate, which would update the ref using these exact commands.\n\nWhich leads me to conclude that the current approach based on\nindex-base needs to be rethought. For now, I'll revert the\nwhole index base series from 'next'; git will remember it if we\nneed it later ;-).\n\n\n[Footnote]\n\n*1* Making it an \"opt-in\" enhancement to optimize write-tree\n using cache-tree was simpler, as there was only one place\n that actually writes out the contents of the index. When\n the command updates paths with well-defined API implemented\n in read-cache.c, we can incrementally invalidate the\n cache-tree we originally read from the index and write the\n modified cache-tree out to keep write-tree optimized. When\n keeping track of cache-tree entries and incrementally\n invalidating affected paths is more trouble than its worth,\n on the other hand, we can just invalidate the cache-tree\n upfront. So the commands that do not want to bother\n spending cycles to keep cache-tree up-to-date can easily be\n prevented from writing out an out-of-sync cache-tree to\n confuse later write-tree.\n"},{"id":"39403","messageId":"Pine.LNX.4.64.0704151356450.5473@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7vbqhp4diw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Reverting the whole index-base series","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-15T21:01:28Z","receivedAt":"2007-04-15T21:01:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Apr 2007, Junio C Hamano wrote:\n> \n> I have been thinking about the approach using index-base to\n> guard against somebody else updating the tip of branch you are\n> currently on (let's call that \"gremlin updates (to the HEAD)\"\n> for lack of better wording). Unlike the earlier cache-tree\n> based write-tree optimization, it turns out to be an uphill\n> battle to make it an \"opt-in\" enhancement [*1*].\n\nI never understood what you were trying to do.\n\nThe SHA1 doesn't really help.\n\nIf \"next\" and \"pu\" are the same, and you have \"next\" checked out, and you \npush into \"pu\", what happens? Since the two branches were the same, the \nSHA1 was the same before, so the BASE commit in the index will be the one \nthat is updated.\n\nThe only thing that matters is that if you update the branch that HEAD \npoints to, and then you'd always need to do something special, but I don't \nsee that it has anything to do with what the \"BASE\" commit was.. It's \npurely a matter of \"what does HEAD point to\", independently of the index.\n\nBut no, I wasn't following that series, so I probably totally \nmisunderstood what you were going after..\n\n\t\tLinus\n"},{"id":"39406","messageId":"7vfy712uva.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704151356450.5473@woody.linux-foundation.org","subject":"Re: Reverting the whole index-base series","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-15T21:25:13Z","receivedAt":"2007-04-15T21:25:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> If \"next\" and \"pu\" are the same, and you have \"next\" checked out, and you \n> push into \"pu\", what happens? Since the two branches were the same, the \n> SHA1 was the same before, so the BASE commit in the index will be the one \n> that is updated.\n\nBut it does not matter if \"pu\" was not checked out. You will be\nbuilding on top of \"next\" which was not changed.\n\n> The only thing that matters is that if you update the branch that HEAD \n> points to, and then you'd always need to do something special, but I don't \n> see that it has anything to do with what the \"BASE\" commit was.. It's \n> purely a matter of \"what does HEAD point to\", independently of the index.\n>\n> But no, I wasn't following that series, so I probably totally \n> misunderstood what you were going after..\n\nCould be.\n\nThe issue in short was about:\n\n\t$ git checkout $branch\n\nAt this point you think your HEAD is at $branch head, and you\nare working towards building a commit that has that commit as\none of the parents.\n\nThen a gremlin updates the commit HEAD points at. Maybe\nsomebody else pushed into $branch. Or you had another working\ntree that shares refs (but not index nor HEAD -- perhaps set up\nwith contrib/workdir/git-new-workdir) with this repository and\nmade a commit there by mistake on the branch.\n\nAnd you try to make a commit.\n\n\t$ git commit\n\nThe work you did in your repository were mostly based on the\ncontents of the commit you checked out but this \"git commit\"\nwill create a commit on top of something else (i.e. the one the\ngremlin updated to).\n\nTo detect this case, we needed to record \"which commit are we\nexpecting to base the next commit on\". The place to record that\ninformation does not have to be in the index (I could have\npicked a separate file .git/current-head-commit and stored the\ninformation there), but the index was a convenient place to do\nso.\n\nSo it does not have anything to do with the index, but very much\nabout the HEAD. The problem was about keeping it in sync with\nwhat really was going on in the repository / working tree.\n"},{"id":"39424","messageId":"Pine.LNX.4.64.0704151632140.5473@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7vfy712uva.fsf@assigned-by-dhcp.cox.net","subject":"Re: Reverting the whole index-base series","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-15T23:33:46Z","receivedAt":"2007-04-15T23:33:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Apr 2007, Junio C Hamano wrote:\n> >\n> > But no, I wasn't following that series, so I probably totally \n> > misunderstood what you were going after..\n> \n> Could be.\n> \n> The issue in short was about:\n> \n> \t$ git checkout $branch\n> \n> At this point you think your HEAD is at $branch head, and you\n> are working towards building a commit that has that commit as\n> one of the parents.\n> \n> Then a gremlin updates the commit HEAD points at.\n\nAhh, ok. I was kind of expecting that you'd actually do something at \n\"receive-pack\" time instead, not at the next commit. That would also solve \nit - just have an option saying \"update the working tree when receiving\". \n\nAnd since I thought that was what you were aiming at, I didn't see why you \nwanted to hide the previous commit in the index..\n\nAll clear now. My confusion.\n\n\t\tLinus\n"},{"id":"39426","messageId":"7vhcrh1a2w.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704151632140.5473@woody.linux-foundation.org","subject":"Re: Reverting the whole index-base series","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-15T23:39:35Z","receivedAt":"2007-04-15T23:39:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 15 Apr 2007, Junio C Hamano wrote:\n>> >\n>> > But no, I wasn't following that series, so I probably totally \n>> > misunderstood what you were going after..\n>> \n>> Could be.\n>> \n>> The issue in short was about:\n>> \n>> \t$ git checkout $branch\n>> \n>> At this point you think your HEAD is at $branch head, and you\n>> are working towards building a commit that has that commit as\n>> one of the parents.\n>> \n>> Then a gremlin updates the commit HEAD points at.\n>\n> Ahh, ok. I was kind of expecting that you'd actually do something at \n> \"receive-pack\" time instead, not at the next commit. That would also solve \n> it - just have an option saying \"update the working tree when receiving\". \n\nI specifically did not want to do that, as it would break\nexisting workflow of pushing into a live repository, knowing the\nbranch might be checked out at the remote.\n\nAlso, the case of multiple working trees sharing the same refs/\nnamespace cannot be solved by trapping receive-pack alone.\n"},{"id":"39431","messageId":"Pine.LNX.4.64.0704151652420.5473@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7vhcrh1a2w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Reverting the whole index-base series","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-15T23:58:24Z","receivedAt":"2007-04-15T23:58:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Apr 2007, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> >\n> > Ahh, ok. I was kind of expecting that you'd actually do something at \n> > \"receive-pack\" time instead, not at the next commit. That would also solve \n> > it - just have an option saying \"update the working tree when receiving\". \n> \n> I specifically did not want to do that, as it would break\n> existing workflow of pushing into a live repository, knowing the\n> branch might be checked out at the remote.\n\nYeah. That said, maybe we could make it an option. There's really a few \ndifferent things we could do:\n\n (a) what we do now - the working tree and index is totally unaffected\n (b) do a \"git-read-tree -m old new\" and if that fails, fail the push.\n This would at least ensure the *index* matches\n (b') same as (b), but with \"-u\" to actually check it out\n (c) do a \"git-read-tree --reset new\"\n (c') same as (c), but with \"-u\"\n\nand we could just keep the *default* the same, but allow the receiving \nside to say what it wants to happen.\n\n> Also, the case of multiple working trees sharing the same refs/\n> namespace cannot be solved by trapping receive-pack alone.\n\nRight. I think any working-tree thing would have to be conditional on the \nreceive being done on a non-bare git repository (obviously) and we'd only \nupdate the directory that the push was aimed at.\n\nSo if somebody does\n\n\tgit push remote:my-git-tree/.git/\n\nthen we'd *always* do (a), since we pushed into the \"bare\" part, but if \nsomebody did\n\n\tgit push remote:my-git-tree\n\nand the receiver ended up doing a \"cd .git\", it would remember what the \nchecked-out tree was and update that one (and no other).\n\n\t\t\tLinus\n"},{"id":"39433","messageId":"7v8xct18m0.fsf@assigned-by-dhcp.cox.net","threadId":"7633","inReplyTo":"Pine.LNX.4.64.0704151652420.5473@woody.linux-foundation.org","subject":"Re: Reverting the whole index-base series","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-16T00:11:19Z","receivedAt":"2007-04-16T00:11:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> ... That said, maybe we could make it an option. There's really a few \n> different things we could do:\n>\n> (a) what we do now - the working tree and index is totally unaffected\n> (b) do a \"git-read-tree -m old new\" and if that fails, fail the push.\n> This would at least ensure the *index* matches\n> (b') same as (b), but with \"-u\" to actually check it out\n> (c) do a \"git-read-tree --reset new\"\n> (c') same as (c), but with \"-u\"\n>\n> and we could just keep the *default* the same, but allow the receiving \n> side to say what it wants to happen.\n\nYeah, throw another one in:\n\n (d) what we do now, but detach HEAD.\n\n> So if somebody does\n>\n> \tgit push remote:my-git-tree/.git/\n>\n> then we'd *always* do (a), since we pushed into the \"bare\" part, but if \n> somebody did\n>\n> \tgit push remote:my-git-tree\n>\n> and the receiver ended up doing a \"cd .git\", it would remember what the \n> checked-out tree was and update that one (and no other).\n\nI suspect that this would make the pending \"GIT_WORK_TREE\"\nseries more interesting.\n"},{"id":"39553","messageId":"Pine.LNX.4.64.0704160931550.5473@woody.linux-foundation.org","threadId":"7633","inReplyTo":"7v8xct18m0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Reverting the whole index-base series","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-16T16:32:29Z","receivedAt":"2007-04-16T16:32:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Apr 2007, Junio C Hamano wrote:\n> \n> > ... That said, maybe we could make it an option. There's really a few \n> > different things we could do:\n> \n> Yeah, throw another one in:\n> \n> (d) what we do now, but detach HEAD.\n\nYeah, that actually sounds like a really nice option. I think that's the \none I'd personally use.\n\n\t\tLinus\n"}]}