{"thread":{"id":"15918","subject":"Re: Untracked working tree files","startedAt":"2008-10-15T18:56:54Z","lastAt":"2008-10-16T14:49:21Z","messageCount":24,"participants":["david@lang.hm","Andrew Morton","Linus Torvalds","Nicolas Pitre","Junio C Hamano","Ingo Molnar","Paolo Ciarrocchi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93218","messageId":"20081015115654.fb34438f.akpm@linux-foundation.org","threadId":"15918","inReplyTo":null,"subject":"Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T18:56:54Z","receivedAt":"2008-10-15T18:56:54Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"I often get this (running git 1.5.6.rc0 presently):\n\ny:/usr/src/git26> git-checkout linux-next\nerror: Untracked working tree file 'arch/x86/kernel/apic.c' would be overwritten by merge.\n\nwhich screws things up.  I fix it by removing the offending file, which\ngets irritating because git bails out after the first such instance, so\nI need to rerun git-checkout once per file (there are sometimes tens of them).\n\nShould this be happening?  I don't know what causes it, really.  All\nI've been doing in that directory is running `git-checkout' against\nvarious maintainers' trees.  95% of the time this works OK but\neventually git seems to get all confused and the above happens.\n\nIs there some way in which I can work around this with a single command\nrather than having to run git-checkout once per offending file?  I\nsuppose a good old `rm -rf *' would do it...\n\nThanks.\n"},{"id":"93116","messageId":"alpine.DEB.1.10.0810151208100.7808@asgard.lang.hm","threadId":"15918","inReplyTo":"20081015115654.fb34438f.akpm@linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-15T19:09:25Z","receivedAt":"2008-10-15T19:09:25Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 15 Oct 2008, Andrew Morton wrote:\n\n> Date: Wed, 15 Oct 2008 11:56:54 -0700\n> From: Andrew Morton <akpm@linux-foundation.org>\n> To: git@vger.kernel.org\n> Subject: Untracked working tree files\n> \n> I often get this (running git 1.5.6.rc0 presently):\n>\n> y:/usr/src/git26> git-checkout linux-next\n> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be overwritten by merge.\n>\n> which screws things up.  I fix it by removing the offending file, which\n> gets irritating because git bails out after the first such instance, so\n> I need to rerun git-checkout once per file (there are sometimes tens of them).\n\nwhat I do when I run into this is \"git reset --hard HEAD\" which makes all \nfiles in the working directory match HEAD, and then I can do the other \ncheckout.\n\nDavid Lang\n\n> Should this be happening?  I don't know what causes it, really.  All\n> I've been doing in that directory is running `git-checkout' against\n> various maintainers' trees.  95% of the time this works OK but\n> eventually git seems to get all confused and the above happens.\n>\n> Is there some way in which I can work around this with a single command\n> rather than having to run git-checkout once per offending file?  I\n> suppose a good old `rm -rf *' would do it...\n>\n> Thanks.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"93117","messageId":"alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm","threadId":"15918","inReplyTo":"alpine.DEB.1.10.0810151208100.7808@asgard.lang.hm","subject":"Re: Untracked working tree files","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-15T19:14:34Z","receivedAt":"2008-10-15T19:14:34Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 15 Oct 2008, david@lang.hm wrote:\n\n> On Wed, 15 Oct 2008, Andrew Morton wrote:\n>\n>> Date: Wed, 15 Oct 2008 11:56:54 -0700\n>> From: Andrew Morton <akpm@linux-foundation.org>\n>> To: git@vger.kernel.org\n>> Subject: Untracked working tree files\n>> \n>> I often get this (running git 1.5.6.rc0 presently):\n>> \n>> y:/usr/src/git26> git-checkout linux-next\n>> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be \n>> overwritten by merge.\n>> \n>> which screws things up.  I fix it by removing the offending file, which\n>> gets irritating because git bails out after the first such instance, so\n>> I need to rerun git-checkout once per file (there are sometimes tens of \n>> them).\n>\n> what I do when I run into this is \"git reset --hard HEAD\" which makes all \n> files in the working directory match HEAD, and then I can do the other \n> checkout.\n\nI think you can also do git checkout -f head to force the checkout to \noverwrite all files\n\nthe fact that git will happily leave modified things in the working \ndirectory appears to be very helpful for some developers, but it's also a \nbig land mine for others.\n\nis there a way to disable this?\n\nDavid Lang\n"},{"id":"93120","messageId":"20081015122407.f06e8f53.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T19:24:07Z","receivedAt":"2008-10-15T19:24:07Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 15 Oct 2008 12:14:34 -0700 (PDT)\ndavid@lang.hm wrote:\n\n> On Wed, 15 Oct 2008, david@lang.hm wrote:\n> \n> > On Wed, 15 Oct 2008, Andrew Morton wrote:\n> >\n> >> Date: Wed, 15 Oct 2008 11:56:54 -0700\n> >> From: Andrew Morton <akpm@linux-foundation.org>\n> >> To: git@vger.kernel.org\n> >> Subject: Untracked working tree files\n> >> \n> >> I often get this (running git 1.5.6.rc0 presently):\n> >> \n> >> y:/usr/src/git26> git-checkout linux-next\n> >> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be \n> >> overwritten by merge.\n> >> \n> >> which screws things up.  I fix it by removing the offending file, which\n> >> gets irritating because git bails out after the first such instance, so\n> >> I need to rerun git-checkout once per file (there are sometimes tens of \n> >> them).\n> >\n> > what I do when I run into this is \"git reset --hard HEAD\" which makes all \n> > files in the working directory match HEAD, and then I can do the other \n> > checkout.\n\nI was using this but it seems it wasn't in the right place in the script.\n\n\n> I think you can also do git checkout -f head to force the checkout to \n> overwrite all files\n\nOK, I'll try that.\n\n> the fact that git will happily leave modified things in the working \n> directory appears to be very helpful for some developers, but it's also a \n> big land mine for others.\n\nThese files weren't modified.  By me, at least.  git might have\n\"modified\" them, but it has all the info necessary to know that the\nfile has no uncommitted changes.\n\n> is there a way to disable this?\n> \n> David Lang\n"},{"id":"93122","messageId":"20081015122621.a9674d75.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T19:26:21Z","receivedAt":"2008-10-15T19:26:21Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 15 Oct 2008 12:14:34 -0700 (PDT)\ndavid@lang.hm wrote:\n\n> On Wed, 15 Oct 2008, david@lang.hm wrote:\n> \n> > On Wed, 15 Oct 2008, Andrew Morton wrote:\n> >\n> >> Date: Wed, 15 Oct 2008 11:56:54 -0700\n> >> From: Andrew Morton <akpm@linux-foundation.org>\n> >> To: git@vger.kernel.org\n> >> Subject: Untracked working tree files\n> >> \n> >> I often get this (running git 1.5.6.rc0 presently):\n> >> \n> >> y:/usr/src/git26> git-checkout linux-next\n> >> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be \n> >> overwritten by merge.\n> >> \n> >> which screws things up.  I fix it by removing the offending file, which\n> >> gets irritating because git bails out after the first such instance, so\n> >> I need to rerun git-checkout once per file (there are sometimes tens of \n> >> them).\n> >\n> > what I do when I run into this is \"git reset --hard HEAD\" which makes all \n> > files in the working directory match HEAD, and then I can do the other \n> > checkout.\n\nI do\n\n\tgit-reset --hard HEAD\n\tgit-reset --hard linux-next\n\tgit-checkout linux-next\n\nand get\n\nerror: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.\ny\n\ngrr.\n\n> I think you can also do git checkout -f head to force the checkout to \n> overwrite all files\n\nyup, that fixed it.  whee, thanks.\n\n> the fact that git will happily leave modified things in the working \n> directory appears to be very helpful for some developers, but it's also a \n> big land mine for others.\n> \n> is there a way to disable this?\n> \n> David Lang\n"},{"id":"93125","messageId":"alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org","threadId":"15918","inReplyTo":"alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm","subject":"Re: Untracked working tree files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-15T19:31:40Z","receivedAt":"2008-10-15T19:31:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Oct 2008, david@lang.hm wrote:\n> \n> the fact that git will happily leave modified things in the working directory\n> appears to be very helpful for some developers, but it's also a big land mine\n> for others.\n\nHmm. It doesn't actually do that normally. If you switch between trees, \ngit will (or _should_) remove the old files that it knows about. If you \nget a lot of left-over turds, there's something wrong.\n\nIt could be a git bug, of course. That said, especially considering the \nsource of this, I wonder if it's just that Andrew ends up using all those \nnon-git scripts on top of a git tree, and then that can result in git \n*not* knowing about a certain file, and then when switching between trees \n(with either git checkout or with git reset), the data that was created \nwith non-git tools gets left behind and now git will be afraid to \noverwrite it.\n\nSo yes, there are ways to force it (both \"git checkout -f\"  and \"git reset \n--hard\" having already been mentioned), but the need for that - especially \nif it's common - is a bit discouraging.\n\nEspecially since it's still possible that it's some particular mode of git \nusage that leaves those things around. Andrew - have you any clue what it \nis that triggers the behavior?\n\n(By the filename, I realize it's a file that doesn't exist in one tree or \nthe other, and which doesn't get removed at some point. But have you had \nmerge failures, for example? Is it perhaps a file that was created during \na non-clean merge, and then got left behind due to the merge being \naborted? It would be interesting to know what led up to this..)\n\n\t\t\tLinus\n"},{"id":"93126","messageId":"alpine.LFD.2.00.0810151531140.26244@xanadu.home","threadId":"15918","inReplyTo":"20081015122621.a9674d75.akpm@linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-15T19:32:21Z","receivedAt":"2008-10-15T19:32:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Oct 2008, Andrew Morton wrote:\n\n> I do\n> \n> \tgit-reset --hard HEAD\n> \tgit-reset --hard linux-next\n> \tgit-checkout linux-next\n> \n> and get\n> \n> error: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.\n> y\n> \n> grr.\n\nWhat about simply:\n\n\tgit-checkout -f linux-next\n\n\nNicolas\n"},{"id":"93127","messageId":"alpine.LFD.2.00.0810151533090.26244@xanadu.home","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151531140.26244@xanadu.home","subject":"Re: Untracked working tree files","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-15T19:34:05Z","receivedAt":"2008-10-15T19:34:05Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Oct 2008, Nicolas Pitre wrote:\n\n> On Wed, 15 Oct 2008, Andrew Morton wrote:\n> \n> > I do\n> > \n> > \tgit-reset --hard HEAD\n> > \tgit-reset --hard linux-next\n> > \tgit-checkout linux-next\n> > \n> > and get\n> > \n> > error: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.\n> > y\n> > \n> > grr.\n> \n> What about simply:\n> \n> \tgit-checkout -f linux-next\n\nNever mind -- you apparently did that already with success.\n\n\nNicolas\n"},{"id":"93129","messageId":"alpine.DEB.1.10.0810151240220.7808@asgard.lang.hm","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-15T19:42:25Z","receivedAt":"2008-10-15T19:42:25Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 15 Oct 2008, Linus Torvalds wrote:\n\n> On Wed, 15 Oct 2008, david@lang.hm wrote:\n>>\n>> the fact that git will happily leave modified things in the working directory\n>> appears to be very helpful for some developers, but it's also a big land mine\n>> for others.\n>\n> Hmm. It doesn't actually do that normally. If you switch between trees,\n> git will (or _should_) remove the old files that it knows about. If you\n> get a lot of left-over turds, there's something wrong.\n>\n> It could be a git bug, of course. That said, especially considering the\n> source of this, I wonder if it's just that Andrew ends up using all those\n> non-git scripts on top of a git tree, and then that can result in git\n> *not* knowing about a certain file, and then when switching between trees\n> (with either git checkout or with git reset), the data that was created\n> with non-git tools gets left behind and now git will be afraid to\n> overwrite it.\n>\n> So yes, there are ways to force it (both \"git checkout -f\"  and \"git reset\n> --hard\" having already been mentioned), but the need for that - especially\n> if it's common - is a bit discouraging.\n>\n> Especially since it's still possible that it's some particular mode of git\n> usage that leaves those things around. Andrew - have you any clue what it\n> is that triggers the behavior?\n\nI see it fairly frequently when switching between different branches of a \nproject.\n\nI also see it when I try applying a patch to a tree, then want to get up \nto date with that tree (in this case it really is different)\n\nIt could be that git is looking to see if the file is the same as the old \ntree had it before checking out the new tree. if it isn't for any reason \nit sounds the alert.\n\nDavid Lang\n\n> (By the filename, I realize it's a file that doesn't exist in one tree or\n> the other, and which doesn't get removed at some point. But have you had\n> merge failures, for example? Is it perhaps a file that was created during\n> a non-clean merge, and then got left behind due to the merge being\n> aborted? It would be interesting to know what led up to this..)\n>\n> \t\t\tLinus\n>\n"},{"id":"93130","messageId":"20081015124949.b657a8db.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T19:49:49Z","receivedAt":"2008-10-15T19:49:49Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 15 Oct 2008 12:31:40 -0700 (PDT)\nLinus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Wed, 15 Oct 2008, david@lang.hm wrote:\n> > \n> > the fact that git will happily leave modified things in the working directory\n> > appears to be very helpful for some developers, but it's also a big land mine\n> > for others.\n> \n> Hmm. It doesn't actually do that normally. If you switch between trees, \n> git will (or _should_) remove the old files that it knows about. If you \n> get a lot of left-over turds, there's something wrong.\n> \n> It could be a git bug, of course. That said, especially considering the \n> source of this, I wonder if it's just that Andrew ends up using all those \n> non-git scripts on top of a git tree, and then that can result in git \n> *not* knowing about a certain file, and then when switching between trees \n> (with either git checkout or with git reset), the data that was created \n> with non-git tools gets left behind and now git will be afraid to \n> overwrite it.\n\nI treat my git directory as a read-only thing.  I only ever modify it\nwith git commands.\n\n> So yes, there are ways to force it (both \"git checkout -f\"  and \"git reset \n> --hard\" having already been mentioned), but the need for that - especially \n> if it's common - is a bit discouraging.\n> \n> Especially since it's still possible that it's some particular mode of git \n> usage that leaves those things around. Andrew - have you any clue what it \n> is that triggers the behavior?\n\nSorry, no, I haven't seen a pattern.\n\n> (By the filename, I realize it's a file that doesn't exist in one tree or \n> the other, and which doesn't get removed at some point. But have you had \n> merge failures, for example? Is it perhaps a file that was created during \n> a non-clean merge, and then got left behind due to the merge being \n> aborted? It would be interesting to know what led up to this..)\n\nThat's certainly a possibility - I get a lot of merge failures.  A real\nlot.  And then quite a bit of rebasing goes on, especially in\nlinux-next.  And then there's all the other stuff which Stephen does on\ntop of the underlying trees to get something releasable happening.\n"},{"id":"93131","messageId":"alpine.LFD.2.00.0810151247560.3288@nehalem.linux-foundation.org","threadId":"15918","inReplyTo":"alpine.DEB.1.10.0810151240220.7808@asgard.lang.hm","subject":"Re: Untracked working tree files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-15T19:56:26Z","receivedAt":"2008-10-15T19:56:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Oct 2008, david@lang.hm wrote:\n> \n> I see it fairly frequently when switching between different branches of a\n> project.\n\nSo, at least for any normal switch, assuming file 'a' doesn't exist in the \nother branch, you really should have a few different cases:\n\n - you have a dirty file, and git should say something like\n\n\terror: You have local changes to 'file'; cannot switch branches.\n\n   because it refuses to modify the file to match the other branch (which \n   includes removing it) if it doesn't match the index.\n\n   So this case shouldn't leave anything behind.\n\n - You have that extra file, but it's not in the index.\n\n   If it's in your current HEAD, we should still notice it with something \n   like:\n\n\terror: Untracked working tree file 'tree' would be removed by merge.\n\n   because now it's untracked (not in the index), but the switching \n   between branches tries to essentially \"apply\" the difference between \n   your current HEAD and the new branch, and finds that the difference \n   involves removing a file that git isn't tracking.\n\nSee?\n\nHOWEVER.\n\nIf you're used to doing \"git checkout -f\" or \"git reset --hard\", both of \nthose checks are just ignored. After all, you asked for a forced switch. \n\nAnd at least in the second case, what I think happens is that git won't \nremove the file it doesn't know about, so you'll have a \"turd\" left \naround.\n\nSo yes, you can certainly get these kinds of left-overs, but they really \nshould be only happening if you \"force\" something. Do you do that often?\n\n\t\t\tLinus\n"},{"id":"93133","messageId":"alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org","threadId":"15918","inReplyTo":"20081015124949.b657a8db.akpm@linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-15T20:08:36Z","receivedAt":"2008-10-15T20:08:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Oct 2008, Andrew Morton wrote:\n> \n> I treat my git directory as a read-only thing.  I only ever modify it\n> with git commands.\n\nOk. \n\n> > (By the filename, I realize it's a file that doesn't exist in one tree or \n> > the other, and which doesn't get removed at some point. But have you had \n> > merge failures, for example? Is it perhaps a file that was created during \n> > a non-clean merge, and then got left behind due to the merge being \n> > aborted? It would be interesting to know what led up to this..)\n> \n> That's certainly a possibility - I get a lot of merge failures.  A real\n> lot.  And then quite a bit of rebasing goes on, especially in\n> linux-next.  And then there's all the other stuff which Stephen does on\n> top of the underlying trees to get something releasable happening.\n\nIs \"git checkout -f\" part of the scripting? Or \"git reset --hard\"?\n\nSo what I could imagine is happening is:\n\n - you have a lot of automated merging\n\n - a merge goes south with a data conflict, and since it's all automated, \n   you just want to throw it away. So you do \"git reset --force\" to do \n   that.\n\n - but what \"git reset --hard\" means is to basically ignore all error \n   cases, including any unmerged entries that it just basically ignores.\n\n - so it did set the tree back, but the whole point of \"--hard\" is that it \n   ignores error cases, and doesn't really touch them.\n\nNow, I don't think we ever really deeply thought about what the error \ncases should do when they are ignored. Should the file that is in some \nstate we don't like be removed? Or should we just ignore the error and \nreturn without removing the file? Generally git tries to avoid touching \nthings it doesn't understand, but I do think this may explain some pain \nfor you, and it may not be the right thing in this case.\n\n(And when I say \"this case\", I don't really know whether you use \"git \ncheckout -f\" or \"git reset --hard\" or something else, so I'm not even \ngoing to say I'm sure exactly _which_ case \"this case\" actually us :)\n\nOf course, the cheesy way for you to fix this may be to just add a\n\n\tgit clean -dqfx\n\nto directly after whatever point where you decide to reset and revert to \nan earlier stage. That just says \"force remove all files I don't know \nabout, including any I might ignore\". IOW, \"git reset --hard\" will \nguarantee that all _tracked_ files are reset, but if you worry about some \nother crud that could have happened due to a failed merge, that additional \n\"git clean\" may be called for.\n\nOf course, it's going to read the whole directory tree and that's not \nreally cheap, but especially if you only do this for error cases, it's \nprobably not going to be any worse. And I'm assuming you're not compiling \nin that tree, so you probably don't want to save object files (you can \nremove the \"x\" part, but then you could still at least in theory get a \nfilename clash with something that is ignored and thus didn't get cleaned \nup).\n\n\t\t\tLinus\n"},{"id":"93135","messageId":"alpine.DEB.1.10.0810151314110.7808@asgard.lang.hm","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151247560.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-15T20:17:46Z","receivedAt":"2008-10-15T20:17:46Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 15 Oct 2008, Linus Torvalds wrote:\n\n> On Wed, 15 Oct 2008, david@lang.hm wrote:\n>>\n>> I see it fairly frequently when switching between different branches of a\n>> project.\n>\n> So, at least for any normal switch, assuming file 'a' doesn't exist in the\n> other branch, you really should have a few different cases:\n>\n> - you have a dirty file, and git should say something like\n>\n> \terror: You have local changes to 'file'; cannot switch branches.\n>\n>   because it refuses to modify the file to match the other branch (which\n>   includes removing it) if it doesn't match the index.\n>\n>   So this case shouldn't leave anything behind.\n>\n> - You have that extra file, but it's not in the index.\n>\n>   If it's in your current HEAD, we should still notice it with something\n>   like:\n>\n> \terror: Untracked working tree file 'tree' would be removed by merge.\n>\n>   because now it's untracked (not in the index), but the switching\n>   between branches tries to essentially \"apply\" the difference between\n>   your current HEAD and the new branch, and finds that the difference\n>   involves removing a file that git isn't tracking.\n\none place that I know I've run into it frequently is in an internal \nproject that I did not properly setup .gitignore and did \"git add .\" and \n\"git commit -a\" to. that projects repository contains the compiled \nbinaries and I frequently get these errors when switching trees.\n\nthat sounds like the first case.\n\nI've seen discussion of a new sequencer functionality, would it allow me \nto define a .gitignore file and re-create the repository as if that file \nhad existed all along?\n\nDavid Lang\n\n> See?\n>\n> HOWEVER.\n>\n> If you're used to doing \"git checkout -f\" or \"git reset --hard\", both of\n> those checks are just ignored. After all, you asked for a forced switch.\n>\n> And at least in the second case, what I think happens is that git won't\n> remove the file it doesn't know about, so you'll have a \"turd\" left\n> around.\n>\n> So yes, you can certainly get these kinds of left-overs, but they really\n> should be only happening if you \"force\" something. Do you do that often?\n>\n> \t\t\tLinus\n>\n"},{"id":"93138","messageId":"20081015132309.76d3cc28.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T20:23:09Z","receivedAt":"2008-10-15T20:23:09Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)\nLinus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Wed, 15 Oct 2008, Andrew Morton wrote:\n> > \n> > I treat my git directory as a read-only thing.  I only ever modify it\n> > with git commands.\n> \n> Ok. \n> \n> > > (By the filename, I realize it's a file that doesn't exist in one tree or \n> > > the other, and which doesn't get removed at some point. But have you had \n> > > merge failures, for example? Is it perhaps a file that was created during \n> > > a non-clean merge, and then got left behind due to the merge being \n> > > aborted? It would be interesting to know what led up to this..)\n> > \n> > That's certainly a possibility - I get a lot of merge failures.  A real\n> > lot.  And then quite a bit of rebasing goes on, especially in\n> > linux-next.  And then there's all the other stuff which Stephen does on\n> > top of the underlying trees to get something releasable happening.\n> \n> Is \"git checkout -f\" part of the scripting? Or \"git reset --hard\"?\n\nwell, this script has been hacked on so many times I'm not sure what\nit does any more.\n\nPresently the main generate-a-diff function is\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit checkout \"$upstream\"\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\tgit merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\tgit diff --patch-with-stat ORIG_HEAD\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\nusually invoked as\n\ndoit origin v2.6.27\ndoit origin linux-next\n\netc.\n\nthe above seemed fairly busted, so I'm now using\n\n        git checkout -f \"$upstream\"\n        git reset --hard \"$upstream\"\n        git fetch \"$tree\" || exit 1\n\nwhich seems a bit more sensible.  Perhaps I should do the reset before\nthe checkout, dunno.\n\nThat function has been through sooooooo many revisions and each time\nsome scenario get fixed (more like \"improved\"), some other scenario\ngets busted (more like \"worsened\").  The above sorta mostly works,\nalthough it presently generates thirty-odd rejects against\ngit://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git#auto-latest,\nwhich is way above my fix-it-manually threshold.  linux-next is still\ndead because it's taking Stephen over two days to fix the mess he's\nbeen fed so I'm madly rebasing everything on mainline over here.\n\n\n> So what I could imagine is happening is:\n> \n>  - you have a lot of automated merging\n> \n>  - a merge goes south with a data conflict, and since it's all automated, \n>    you just want to throw it away. So you do \"git reset --force\" to do \n>    that.\n\ndidn't know about --force.\n\n>  - but what \"git reset --hard\" means is to basically ignore all error \n>    cases, including any unmerged entries that it just basically ignores.\n> \n>  - so it did set the tree back, but the whole point of \"--hard\" is that it \n>    ignores error cases, and doesn't really touch them.\n> \n> Now, I don't think we ever really deeply thought about what the error \n> cases should do when they are ignored. Should the file that is in some \n> state we don't like be removed? Or should we just ignore the error and \n> return without removing the file? Generally git tries to avoid touching \n> things it doesn't understand, but I do think this may explain some pain \n> for you, and it may not be the right thing in this case.\n\nYeah, there's no easy solution here, and I suspect the real solution is\n\"read programmer's mind\".  Providing a reliable override (like -f) is a\nsensible solution.\n\n> (And when I say \"this case\", I don't really know whether you use \"git \n> checkout -f\" or \"git reset --hard\" or something else, so I'm not even \n> going to say I'm sure exactly _which_ case \"this case\" actually us :)\n> \n> Of course, the cheesy way for you to fix this may be to just add a\n> \n> \tgit clean -dqfx\n> \n> to directly after whatever point where you decide to reset and revert to \n> an earlier stage. That just says \"force remove all files I don't know \n> about, including any I might ignore\". IOW, \"git reset --hard\" will \n> guarantee that all _tracked_ files are reset, but if you worry about some \n> other crud that could have happened due to a failed merge, that additional \n> \"git clean\" may be called for.\n\nOK, I'll try git clean -dqfx if it blows up again.\n\n> Of course, it's going to read the whole directory tree and that's not \n> really cheap, but especially if you only do this for error cases, it's \n> probably not going to be any worse. And I'm assuming you're not compiling \n> in that tree, so you probably don't want to save object files (you can \n> remove the \"x\" part, but then you could still at least in theory get a \n> filename clash with something that is ignored and thus didn't get cleaned \n> up).\n"},{"id":"93139","messageId":"alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-15T20:23:50Z","receivedAt":"2008-10-15T20:23:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Oct 2008, Linus Torvalds wrote:\n> \n>  - a merge goes south with a data conflict, and since it's all automated, \n>    you just want to throw it away.\n\nActually, with your filename, I suspect the conflict would be not a real \nfile content, but more of a \"delete\" conflicting with a modification to \nthat file. IOW, I'm guessing that the thing you hit with \narch/x86/kernel/apic.c was that some branch you pulled:\n\n - created that file\n\n - deleted arch/x86/kernel/apic_[32|64].c\n\n - the old file got marked as a rename source for the new apic.c and \n   there was a data conflict when trying to apply the changes.\n\nas a result, your working tree would have that \"apic.c\" file in it, but \nwith conflict markers, and marked as unmerged.\n\nWhen you then do \"git reset --hard\", it will just ignore unmerged entries, \nand since the original tree (and the destination tree) match, and neither \nof them contain apic.c either, git will totally ignore that file and not \neven try to remove it (since it wasn't there originally).\n\n> So you do \"git reset --force\" to do that.\n\nIt's \"--hard\", not \"--force\". Yeah, the git reset flags are insane. As is \nthe default action, for that matter. It's one of the earliest interfaces, \nand it's stupid and reflects git internal implementations rather than what \nwe ended up learning about using git later. Oh, well.\n\nBut 'git checkout -f' (which is nicer from a user interface standpoint) \nhas the exact same logic and I think shares all the implementation. I \nthink they both end up just calling \"git read-tree --reset -u\".\n\nIt's quite possible that we should remove unmerged entries. Except that's \nnot how our internal 'read_cache_unmerged()' function works. It really \njust ignores them, and throws them on the floor. We _could_ try to just \nturn them into a (since) stage-0 entry.\n\nJunio?\n\n\t\t\tLinus\n"},{"id":"93141","messageId":"20081015133047.e31537b0.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-15T20:30:47Z","receivedAt":"2008-10-15T20:30:47Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 15 Oct 2008 13:23:50 -0700 (PDT)\nLinus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Wed, 15 Oct 2008, Linus Torvalds wrote:\n> > \n> >  - a merge goes south with a data conflict, and since it's all automated, \n> >    you just want to throw it away.\n> \n> Actually, with your filename, I suspect the conflict would be not a real \n> file content, but more of a \"delete\" conflicting with a modification to \n> that file. IOW, I'm guessing that the thing you hit with \n> arch/x86/kernel/apic.c was that some branch you pulled:\n> \n>  - created that file\n> \n>  - deleted arch/x86/kernel/apic_[32|64].c\n> \n>  - the old file got marked as a rename source for the new apic.c and \n>    there was a data conflict when trying to apply the changes.\n> \n> as a result, your working tree would have that \"apic.c\" file in it, but \n> with conflict markers, and marked as unmerged.\n\nThat sounds likely.  I suspect things were especially bad today because\nI accidentally pulled four-week-old linux-next, which had over 500\nrejects in it.\n"},{"id":"93153","messageId":"7v3aixqzrn.fsf@gitster.siamese.dyndns.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-15T22:06:36Z","receivedAt":"2008-10-15T22:06:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Wed, 15 Oct 2008, Linus Torvalds wrote:\n>> \n> It's quite possible that we should remove unmerged entries. Except that's \n> not how our internal 'read_cache_unmerged()' function works. It really \n> just ignores them, and throws them on the floor. We _could_ try to just \n> turn them into a (since) stage-0 entry.\n>\n> Junio?\n\nI'd agree that dropping unmerged entries to stage-0 when we can would make\nsense.  An conflicted existing path would get an stage-0 entry in the\nindex, which is compared with the switched-to HEAD (which could be the\nsame as the current one when \"git reset --hard\" is run without a rev), we\nnotice that they are different and the index entry and the work tree path\nis overwritten by the version from the switched-to HEAD.  For a new path\nthat a failed merge tried to bring in, we notice that the switched-to HEAD\ndoes not have that path and happily remove it from the index and from the\nwork tree.  All will go a lot smoother than the current code.\n\nI am not sure what should happen when we can't drop the unmerged entry\ndown to stage-0 due to D/F conflicts, though.  IIRC, read-tree proper\nwould not touch the work tree in such a case, but merge-recursive creates\nour and their versions with funny suffixes, which will not be known to the\nindex and will be left in the working tree.\n"},{"id":"93155","messageId":"7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org","threadId":"15918","inReplyTo":"7v3aixqzrn.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-15T23:00:06Z","receivedAt":"2008-10-15T23:00:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When aborting a failed merge that has brought in a new path using \"git\nreset --hard\" or \"git read-tree --reset -u\", we used to first forget about\nthe new path (via read_cache_unmerged) and then matched the working tree\nto what is recorded in the index, thus ending up leaving the new path in\nthe work tree.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Junio C Hamano <gitster@pobox.com> writes:\n\n > Linus Torvalds <torvalds@linux-foundation.org> writes:\n >\n >> On Wed, 15 Oct 2008, Linus Torvalds wrote:\n >>> \n >> It's quite possible that we should remove unmerged entries. Except that's \n >> not how our internal 'read_cache_unmerged()' function works. It really \n >> just ignores them, and throws them on the floor. We _could_ try to just \n >> turn them into a (since) stage-0 entry.\n >>\n >> Junio?\n >\n > I am not sure what should happen when we can't drop the unmerged entry\n > down to stage-0 due to D/F conflicts, though.  IIRC, read-tree proper\n > would not touch the work tree in such a case, but merge-recursive creates\n > our and their versions with funny suffixes, which will not be known to the\n > index and will be left in the working tree.\n\n I am still unsure what we should do when we hit D/F conflicts; this one\n simply replaces but it may be safer to drop ADD_CACHE_OK_TO_REPLACE from\n the options to trigger an error in such a case.  I dunno.\n\n read-cache.c               |   32 +++++++++++++++++++-------------\n t/t1005-read-tree-reset.sh |   30 ++++++++++++++++++++++++++++++\n 2 files changed, 49 insertions(+), 13 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex c229fd4..efbab6a 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -1489,25 +1489,31 @@ int write_index(const struct index_state *istate, int newfd)\n int read_index_unmerged(struct index_state *istate)\n {\n \tint i;\n-\tstruct cache_entry **dst;\n-\tstruct cache_entry *last = NULL;\n+\tint unmerged = 0;\n \n \tread_index(istate);\n-\tdst = istate->cache;\n \tfor (i = 0; i < istate->cache_nr; i++) {\n \t\tstruct cache_entry *ce = istate->cache[i];\n-\t\tif (ce_stage(ce)) {\n-\t\t\tremove_name_hash(ce);\n-\t\t\tif (last && !strcmp(ce->name, last->name))\n-\t\t\t\tcontinue;\n-\t\t\tcache_tree_invalidate_path(istate->cache_tree, ce->name);\n-\t\t\tlast = ce;\n+\t\tstruct cache_entry *new_ce;\n+\t\tint size, len, option;\n+\n+\t\tif (!ce_stage(ce))\n \t\t\tcontinue;\n-\t\t}\n-\t\t*dst++ = ce;\n+\t\tunmerged = 1;\n+\t\tlen = strlen(ce->name);\n+\t\tsize = cache_entry_size(len);\n+\t\tnew_ce = xcalloc(1, size);\n+\t\thashcpy(new_ce->sha1, ce->sha1);\n+\t\tmemcpy(new_ce->name, ce->name, len);\n+\t\tnew_ce->ce_flags = create_ce_flags(len, 0);\n+\t\tnew_ce->ce_mode = ce->ce_mode;\n+\t\toption = ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE;\n+\t\tif (add_index_entry(istate, new_ce, option))\n+\t\t\treturn error(\"%s: cannot drop to stage #0\",\n+\t\t\t\t     ce->name);\n+\t\ti = index_name_pos(istate, new_ce->name, len);\n \t}\n-\tistate->cache_nr = dst - istate->cache;\n-\treturn !!last;\n+\treturn unmerged;\n }\n \n struct update_callback_data\ndiff --git a/t/t1005-read-tree-reset.sh b/t/t1005-read-tree-reset.sh\nindex b0d31f5..0cd519c 100755\n--- a/t/t1005-read-tree-reset.sh\n+++ b/t/t1005-read-tree-reset.sh\n@@ -27,4 +27,34 @@ test_expect_success 'reset should work' '\n   test_cmp expect actual\n '\n \n+test_expect_success 'reset should remove remnants from a failed merge' '\n+  git read-tree --reset -u HEAD &&\n+  git ls-files -s >expect &&\n+  sha1=$(git rev-parse :new) &&\n+  (\n+\techo \"100644 $sha1 1\told\"\n+\techo \"100644 $sha1 3\told\"\n+  ) | git update-index --index-info &&\n+  >old &&\n+  git ls-files -s &&\n+  git read-tree --reset -u HEAD &&\n+  git ls-files -s >actual &&\n+  ! test -f old\n+'\n+\n+test_expect_success 'Porcelain reset should remove remnants too' '\n+  git read-tree --reset -u HEAD &&\n+  git ls-files -s >expect &&\n+  sha1=$(git rev-parse :new) &&\n+  (\n+\techo \"100644 $sha1 1\told\"\n+\techo \"100644 $sha1 3\told\"\n+  ) | git update-index --index-info &&\n+  >old &&\n+  git ls-files -s &&\n+  git reset --hard &&\n+  git ls-files -s >actual &&\n+  ! test -f old\n+'\n+\n test_done\n-- \n1.6.0.2.717.gc6f0a\n"},{"id":"93157","messageId":"alpine.LFD.2.00.0810151615550.3288@nehalem.linux-foundation.org","threadId":"15918","inReplyTo":"7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-15T23:16:17Z","receivedAt":"2008-10-15T23:16:17Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Oct 2008, Junio C Hamano wrote:\n>\n> When aborting a failed merge that has brought in a new path using \"git\n> reset --hard\" or \"git read-tree --reset -u\", we used to first forget about\n> the new path (via read_cache_unmerged) and then matched the working tree\n> to what is recorded in the index, thus ending up leaving the new path in\n> the work tree.\n\nLooks good to me. And from my tests, I think \"git checkout -f\" didn't have \nthis problem at all, because it ends up using not got read-tree, but doing \nits own \"reset_tree()\" that uses unpack_trees().\n\nI do wonder if \"git reset\" should perhaps be written in those terms, \ninstead of just being a wrapper around git read-tree. But the patch looks \nfine.\n\n\t\tLinus\n"},{"id":"93167","messageId":"7vprm1jbq5.fsf@gitster.siamese.dyndns.org","threadId":"15918","inReplyTo":"alpine.LFD.2.00.0810151615550.3288@nehalem.linux-foundation.org","subject":"Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-16T06:27:46Z","receivedAt":"2008-10-16T06:27:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Wed, 15 Oct 2008, Junio C Hamano wrote:\n>>\n>> When aborting a failed merge that has brought in a new path using \"git\n>> reset --hard\" or \"git read-tree --reset -u\", we used to first forget about\n>> the new path (via read_cache_unmerged) and then matched the working tree\n>> to what is recorded in the index, thus ending up leaving the new path in\n>> the work tree.\n>\n> Looks good to me. And from my tests, I think \"git checkout -f\" didn't have \n> this problem at all, because it ends up using not got read-tree, but doing \n> its own \"reset_tree()\" that uses unpack_trees().\n>\n> I do wonder if \"git reset\" should perhaps be written in those terms, \n> instead of just being a wrapper around git read-tree. But the patch looks \n> fine.\n\nLet's do this for 'maint' and I'll let others think about possible\nimprovements, then ;-).\n"},{"id":"93169","messageId":"20081016072010.GA19188@elte.hu","threadId":"15918","inReplyTo":"7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-10-16T07:20:10Z","receivedAt":"2008-10-16T07:20:10Z","isPatch":true,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Junio C Hamano <gitster@pobox.com> wrote:\n\n> When aborting a failed merge that has brought in a new path using \"git \n> reset --hard\" or \"git read-tree --reset -u\", we used to first forget \n> about the new path (via read_cache_unmerged) and then matched the \n> working tree to what is recorded in the index, thus ending up leaving \n> the new path in the work tree.\n\ni've met this problem in various variants in the past few months, and i \nalways assumed that it's \"as designed\" - as Git's policy is to never \nlose information unless forced to do so. (which i find very nice in \ngeneral, and which saved modification from getting lost a couple of \ntimes in the past)\n\nthe situations where i end up with a messed up working tree [using \ngit-c427559 right now]:\n\n - doing a conflicted Octopus merge will leave the tree in some weird \n   half-merged state, with lots of untracked working tree files that not \n   even a hard reset will recover from. The routine thing i do to clean \n   up is:\n\n      git reset --hard HEAD\n      git checkout HEAD .\n      git ls-files --others | xargs rm              # DANGEROUS\n\n   doing git checkout -f alone is not enough, as there might be various \n   dangling files left around.\n\n - git auto-gc thinking that it needs to do another pass in the middle \n   of a random git operation, but i dont have 10 minutes to wait so i \n   decide to Ctrl-C it.\n\n - doing the wrong \"git checkout\" and then Ctlr-C-ing it can leave the\n   working tree in limbo as well, needing fixups. If i'm stuck between\n   two branches that rename/remove files it might need the full fixup\n   sequence above.\n\n - if a testbox has a corrupted system clock, its git repo and the \n   kernel build can get confused. This is to be expected i think - but\n   the full sequence above will recover the corrupted tree. Not much Git\n   can do about this i guess.\n\nDoes your fix mean that all i have to do in the future is a hard reset \nback to HEAD, and that dangling files are not supposed to stay around?\n\n\tIngo\n"},{"id":"93171","messageId":"4d8e3fd30810160142x36860354ka30375e3d21438ae@mail.gmail.com","threadId":"15918","inReplyTo":"20081015132309.76d3cc28.akpm@linux-foundation.org","subject":"Re: Untracked working tree files","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-10-16T08:42:13Z","receivedAt":"2008-10-16T08:42:13Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton\n<akpm@linux-foundation.org> wrote:\n> On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)\n> Linus Torvalds <torvalds@linux-foundation.org> wrote:\n>> On Wed, 15 Oct 2008, Andrew Morton wrote:\n[...]\n>> Is \"git checkout -f\" part of the scripting? Or \"git reset --hard\"?\n>\n> well, this script has been hacked on so many times I'm not sure what\n> it does any more.\n>\n> Presently the main generate-a-diff function is\n>\n\nHi Andrew,\nI was wondering whether you could share the scripts you built on top of git,\nyou might get some useful suggestions from this list and they could be\ninspiration for further improvement in GIT (it just happened with this\nthread ;-)\n\nThanks.\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"93173","messageId":"20081016023204.8927325a.akpm@linux-foundation.org","threadId":"15918","inReplyTo":"4d8e3fd30810160142x36860354ka30375e3d21438ae@mail.gmail.com","subject":"Re: Untracked working tree files","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-10-16T09:32:04Z","receivedAt":"2008-10-16T09:32:04Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Thu, 16 Oct 2008 10:42:13 +0200 \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> wrote:\n\n> On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton\n> <akpm@linux-foundation.org> wrote:\n> > On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)\n> > Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> >> On Wed, 15 Oct 2008, Andrew Morton wrote:\n> [...]\n> >> Is \"git checkout -f\" part of the scripting? Or \"git reset --hard\"?\n> >\n> > well, this script has been hacked on so many times I'm not sure what\n> > it does any more.\n> >\n> > Presently the main generate-a-diff function is\n> >\n> \n> Hi Andrew,\n> I was wondering whether you could share the scripts you built on top of git,\n> you might get some useful suggestions from this list and they could be\n> inspiration for further improvement in GIT (it just happened with this\n> thread ;-)\n\noh gee, you don't want to look.  It should all be in\nhttp://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz\n\nBut really it's just the one script, pull-git-patches, below.  That\nthing's been hacked around so much that I daren't breathe on it.\n\nFortunately as long as Stephen Rothwell is producing linux-next I don't\nhave much need for it any more.\n\n\n\n\n#!/bin/sh\n\nGIT_TREE=/usr/src/git26\nPULL=/usr/src/pull\n\ngit_header()\n{\n\ttree=\"$1\"\n\techo GIT $(cat .git/refs/heads/$tree) $(cat .git/branches/$tree)\n\techo\n}\n\n# maybe use git clean -dqfx\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit checkout -f \"$upstream\"\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\tgit merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\tgit diff --patch-with-stat ORIG_HEAD\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\ndo_one()\n{\n\ttree=$1\n\tupstream=$2\n\tif [ ! -e $PULL/$tree.patch ]\n\tthen\n\t\techo \"*** doing $tree, based on $upstream\"\n\t\tgit branch -D $tree\n\t\tdoit $tree $upstream\n\telse\n\t\techo skipping $tree\n\tfi\n}\n\nmkdir -p $PULL\n\nif [ $1\"x\" = \"-x\" ]\nthen\n\texit\nfi\n\ncd $GIT_TREE\ngit checkout -f master\n\ncd /usr/src\n\nif [ $# == 0 ]\nthen\n\ttrees=/usr/src/git-trees\nelse\n\ttrees=\"$1\"\nfi\n\nif [ $# == 2 ]\nthen\n\tdo_one $1 $2\nelse\n\twhile read x\n\tdo\n\t\tif echo $x | grep '^#.*' > /dev/null\n\t\tthen\n\t\t\ttrue\n\t\telse\n\t\t\tdo_one $x\n\t\tfi\n\tdone < $trees\nfi\n"},{"id":"93204","messageId":"7v8wsok32m.fsf@gitster.siamese.dyndns.org","threadId":"15918","inReplyTo":"20081016072010.GA19188@elte.hu","subject":"Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-16T14:49:21Z","receivedAt":"2008-10-16T14:49:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Molnar <mingo@elte.hu> writes:\n\n> Does your fix mean that all i have to do in the future is a hard reset \n> back to HEAD, and that dangling files are not supposed to stay around?\n\nAs long as the index *somehow* knows about these new files, they are\nremoved.\n\nThe situation is:\n\n (0) you start from a HEAD that does not have path xyzzy;\n (1) you attempt to merge a rev that has path xyzzy;\n (2) the merge conflicts, leaving higher staged index entries for the\n     path.\n (3) you decide not to conclude the merge by saying \"reset --hard\".\n\nThe old logic for \"reset\" was to remove paths that exist in the index at\nstage #0 (i.e. cleanly merged) and not in HEAD.  The patch changes the\nrule to remove paths that exist in the index at any stage (i.e. including\nthe ones that have conflicted and not resolved yet) and not in HEAD.\n"}]}