{"thread":{"id":"6189","subject":"Pushing into a repository with working directory?","startedAt":"2007-01-02T04:51:08Z","lastAt":"2007-01-09T13:51:36Z","messageCount":11,"participants":["Shawn O. Pearce","Andy Whitcroft","Junio C Hamano","Andreas Ericsson","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30652","messageId":"20070102045108.GC27690@spearce.org","threadId":"6189","inReplyTo":null,"subject":"Pushing into a repository with working directory?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-02T04:51:08Z","receivedAt":"2007-01-02T04:51:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"So tonight on #git I think I answered for the 10th time why the\nworking directory doesn't update after a push to its associated\nrepository.\n\nWe all know its somewhat dangerous to push into the current branch\nof a working directory, especially if that working directory contains\nuncommitted changes, as HEAD no longer matches the index.\n\nBut we all also know its incredibly useful to be able to push into\na repository with a working directory, so we certainly don't want\nto disallow it entirely.\n\nWhat about refusing a push to the current branch (branch listed in\n$GIT_DIR/HEAD) and the repository appears to have a working directory\n(is_bare_git_dir is false)?\n\n-- \nShawn.\n"},{"id":"30862","messageId":"459E1182.201@shadowen.org","threadId":"6189","inReplyTo":"20070102045108.GC27690@spearce.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2007-01-05T08:51:14Z","receivedAt":"2007-01-05T08:51:14Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> So tonight on #git I think I answered for the 10th time why the\n> working directory doesn't update after a push to its associated\n> repository.\n> \n> We all know its somewhat dangerous to push into the current branch\n> of a working directory, especially if that working directory contains\n> uncommitted changes, as HEAD no longer matches the index.\n> \n> But we all also know its incredibly useful to be able to push into\n> a repository with a working directory, so we certainly don't want\n> to disallow it entirely.\n> \n> What about refusing a push to the current branch (branch listed in\n> $GIT_DIR/HEAD) and the repository appears to have a working directory\n> (is_bare_git_dir is false)?\n\nSpecial casing the 'current' branch makes any sort of automated push\nsetup unreliable. Indeed the special case preventing a fetch into the\ncurrent branch is pretty annoying for the same reason. I would almost\nprefer to relax that than add the same for push.\n\n-apw\n"},{"id":"30863","messageId":"7vwt41j1le.fsf@assigned-by-dhcp.cox.net","threadId":"6189","inReplyTo":"459E1182.201@shadowen.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T08:54:05Z","receivedAt":"2007-01-05T08:54:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n> Special casing the 'current' branch makes any sort of automated push\n> setup unreliable. Indeed the special case preventing a fetch into the\n> current branch is pretty annoying for the same reason. I would almost\n> prefer to relax that than add the same for push.\n\nHow would you relax the fetch case? Fetching into the current\nbranch, unless the repository is bare, is always a fishy\noperation.\n"},{"id":"30866","messageId":"459E1B23.4060400@shadowen.org","threadId":"6189","inReplyTo":"7vwt41j1le.fsf@assigned-by-dhcp.cox.net","subject":"Re: Pushing into a repository with working directory?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2007-01-05T09:32:19Z","receivedAt":"2007-01-05T09:32:19Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andy Whitcroft writes:\n> \n>> Special casing the 'current' branch makes any sort of automated push\n>> setup unreliable. Indeed the special case preventing a fetch into the\n>> current branch is pretty annoying for the same reason. I would almost\n>> prefer to relax that than add the same for push.\n> \n> How would you relax the fetch case? Fetching into the current\n> branch, unless the repository is bare, is always a fishy\n> operation.\n\nIs it fishy if the working directory and index match HEAD? If not, then\nwe could detect that and allow update in that case?\n\nAlso, if we had dangling head support we could \"leave\" HEAD pointing to\nthe starting commit, and emit a nice fat warning.\n\n-apw\n"},{"id":"30870","messageId":"7virfliyzl.fsf@assigned-by-dhcp.cox.net","threadId":"6189","inReplyTo":"459E1B23.4060400@shadowen.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T09:50:22Z","receivedAt":"2007-01-05T09:50:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n> Is it fishy if the working directory and index match HEAD? If not, then\n> we could detect that and allow update in that case?\n\nThat actually is what 'git-pull' does when you misconfigure and\nuse your current branch as the tracking branch (which is the\nonly reason 'git-fetch' has the --update-head-ok option that\nshould never be used by the end user).\n\nWe really should disallow this.\n"},{"id":"30897","messageId":"20070105193646.GC8753@spearce.org","threadId":"6189","inReplyTo":"7vwt41j1le.fsf@assigned-by-dhcp.cox.net","subject":"Re: Pushing into a repository with working directory?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-05T19:36:46Z","receivedAt":"2007-01-05T19:36:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Andy Whitcroft writes:\n> \n> > Special casing the 'current' branch makes any sort of automated push\n> > setup unreliable. Indeed the special case preventing a fetch into the\n> > current branch is pretty annoying for the same reason. I would almost\n> > prefer to relax that than add the same for push.\n> \n> How would you relax the fetch case? Fetching into the current\n> branch, unless the repository is bare, is always a fishy\n> operation.\n\nAnd so is pushing into the current branch, so long as the current\nbranch has a working directory attached to it.\n\nMost new users to Git expect to be able to push into the current\nbranch of a repository and `just have it work`. Only they don't\nreally seem to have an idea of _how_ that operation should behave,\nwhich means they really don't want it to work at all. I certainly\ndon't want an operation to succeed if I can't reason about what\nits success means!\n\nRight now pushing into the current branch makes the index become\nway out of sync from HEAD. This causes git-runstatus to display a\nlarge number of differences, basically undoing any of the changes\nintroduced by HEAD@{1}..HEAD. The user is left with a dirty\nworking tree that they can commit - and committing it will just\nrevert the prior commits. The user will later cuss at Git for\nlosing their changes. Not pretty.\n\n-- \nShawn.\n"},{"id":"31141","messageId":"45A24CE6.5060201@shadowen.org","threadId":"6189","inReplyTo":"20070105193646.GC8753@spearce.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2007-01-08T13:53:42Z","receivedAt":"2007-01-08T13:53:42Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Junio C Hamano wrote:\n>> Andy Whitcroft writes:\n>>\n>>> Special casing the 'current' branch makes any sort of automated push\n>>> setup unreliable. Indeed the special case preventing a fetch into the\n>>> current branch is pretty annoying for the same reason. I would almost\n>>> prefer to relax that than add the same for push.\n>> How would you relax the fetch case? Fetching into the current\n>> branch, unless the repository is bare, is always a fishy\n>> operation.\n> \n> And so is pushing into the current branch, so long as the current\n> branch has a working directory attached to it.\n> \n> Most new users to Git expect to be able to push into the current\n> branch of a repository and `just have it work`. Only they don't\n> really seem to have an idea of _how_ that operation should behave,\n> which means they really don't want it to work at all. I certainly\n> don't want an operation to succeed if I can't reason about what\n> its success means!\n> \n> Right now pushing into the current branch makes the index become\n> way out of sync from HEAD. This causes git-runstatus to display a\n> large number of differences, basically undoing any of the changes\n> introduced by HEAD@{1}..HEAD. The user is left with a dirty\n> working tree that they can commit - and committing it will just\n> revert the prior commits. The user will later cuss at Git for\n> losing their changes. Not pretty.\n\nOk, both seem to be bad. Can I re-ask if this would be solved by having\nthe 'dangling head' support we talked about. Such that pulling into or\npushing into the current head could break the link and make the current\nhead a dangling head? In my mind thats very similar to creating a\ntemporary branch for the user before updating the head they were on, but\nwithout having to actually make one.\n\n-apw\n"},{"id":"31173","messageId":"7vd55pt3ts.fsf@assigned-by-dhcp.cox.net","threadId":"6189","inReplyTo":"45A24CE6.5060201@shadowen.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-09T00:57:03Z","receivedAt":"2007-01-09T00:57:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n>> Right now pushing into the current branch makes the index become\n>> way out of sync from HEAD. This causes git-runstatus to display a\n>> large number of differences, basically undoing any of the changes\n>> introduced by HEAD@{1}..HEAD. The user is left with a dirty\n>> working tree that they can commit - and committing it will just\n>> revert the prior commits. The user will later cuss at Git for\n>> losing their changes. Not pretty.\n>\n> Ok, both seem to be bad. Can I re-ask if this would be solved by having\n> the 'dangling head' support we talked about. Such that pulling into or\n> pushing into the current head could break the link and make the current\n> head a dangling head?\n\nPush does not do any working tree operation, so you _could_\ndetach the HEAD to point at the commit that used to be at the\ntip of the branch and advance the tip of the branch as the push\ninstructs. The user could start a new branch out of the\ndetached HEAD (which is behind the tip of the original branch),\nmake necessary commits and then merge that branch locally to the\nbranch the push advanced if s/he wants to.\n\nHowever, I am not sure if that is easy to understand for the\nusers. It would be sane to deny pushing into the current branch\nfor a non-bare repositories by default, and if we do allow it\n(perhaps with 'git-push --force'), then detach the HEAD as you\nsuggest. On the other hand, pushing into the current branch of\na bare repository should just work; the HEAD pointer in a bare\nrepository is not about the commit the index and the working\ntree are based on, but which branch is the primary branch of the\nrepository.\n\nI haven't thought things through, but I think the fetch side\ncould be handled in a similar way.\n"},{"id":"31185","messageId":"20070109033213.GC1904@spearce.org","threadId":"6189","inReplyTo":"7vd55pt3ts.fsf@assigned-by-dhcp.cox.net","subject":"Re: Pushing into a repository with working directory?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-09T03:32:13Z","receivedAt":"2007-01-09T03:32:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> However, I am not sure if that is easy to understand for the\n> users. It would be sane to deny pushing into the current branch\n> for a non-bare repositories by default, and if we do allow it\n> (perhaps with 'git-push --force'), then detach the HEAD as you\n> suggest. On the other hand, pushing into the current branch of\n> a bare repository should just work; the HEAD pointer in a bare\n> repository is not about the commit the index and the working\n> tree are based on, but which branch is the primary branch of the\n> repository.\n\nBut from the working directory management tools' perspective HEAD\n*is* about the current index and the current working directory.\nIf HEAD doesn't match the index and working directory closely\nenough then the user is going to do something stupid, like commit\na negative delta by accident.\n\nPushing into the current branch of a repository with a working\ndirectory probably shouldn't be allowed by default as users probably\ndon't want to do that. But if --force is used then detaching the\nHEAD is probably the best idea. The user could easily recover by\ndoing `git checkout origbranch` (though they may need `git checkout\n-m origbranch` if their working directory was dirty).\n\n-- \nShawn.\n"},{"id":"31215","messageId":"45A35D30.3070305@op5.se","threadId":"6189","inReplyTo":"20070109033213.GC1904@spearce.org","subject":"Re: Pushing into a repository with working directory?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-09T09:15:28Z","receivedAt":"2007-01-09T09:15:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Junio C Hamano wrote:\n>> However, I am not sure if that is easy to understand for the\n>> users. It would be sane to deny pushing into the current branch\n>> for a non-bare repositories by default, and if we do allow it\n>> (perhaps with 'git-push --force'), then detach the HEAD as you\n>> suggest. On the other hand, pushing into the current branch of\n>> a bare repository should just work; the HEAD pointer in a bare\n>> repository is not about the commit the index and the working\n>> tree are based on, but which branch is the primary branch of the\n>> repository.\n> \n> But from the working directory management tools' perspective HEAD\n> *is* about the current index and the current working directory.\n> If HEAD doesn't match the index and working directory closely\n> enough then the user is going to do something stupid, like commit\n> a negative delta by accident.\n> \n> Pushing into the current branch of a repository with a working\n> directory probably shouldn't be allowed by default as users probably\n> don't want to do that.\n\n\nI do this all the time. I develop on my laptop and send changes to a \ntestserver where I check out the revision I just pushed to the working \ndirectory attached to it. Doing it the other way around is cumbersome, \nas I've got ssh-authentication installed on the server but don't wish to \nhave that on my laptop. I could ofcourse do this with the alternates \nmechanism and pull things from the alternate repo to the one I really \nuse, but that seems like I have to work around a limitation in git that \nisn't really there (or at least shouldn't be there for any logical or \ntechnical reason).\n\n> But if --force is used then detaching the\n> HEAD is probably the best idea. The user could easily recover by\n> doing `git checkout origbranch` (though they may need `git checkout\n> -m origbranch` if their working directory was dirty).\n> \n\nSince we can determine if there's a working directory or not, why not \njust allow the fast-forward case if the working directory is clean and \nupdate the working directory for the user? This can't lose any data and \nwould also make it very easy to, fe, keep a website in git and just push \nit straight to the webserver when there's been modifications in the \nusers repo. --force should behave the same way, possibly with an extra \ncheck to see if the working directory is clean before checking it out.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"31239","messageId":"Pine.LNX.4.63.0701091449320.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6189","inReplyTo":"45A35D30.3070305@op5.se","subject":"Re: Pushing into a repository with working directory?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-09T13:51:36Z","receivedAt":"2007-01-09T13:51:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Jan 2007, Andreas Ericsson wrote:\n\n> Shawn O. Pearce wrote:\n> > \n> > Pushing into the current branch of a repository with a working \n> > directory probably shouldn't be allowed by default as users probably \n> > don't want to do that.\n> \n> \n> I do this all the time. I develop on my laptop and send changes to a \n> testserver where I check out the revision I just pushed to the working \n> directory attached to it.\n\nThis is still possible. I also do it all the time. Only I do not update \nthe _current_ branch, but a throwaway one.\n\n> Since we can determine if there's a working directory or not, why not \n> just allow the fast-forward case if the working directory is clean and \n> update the working directory for the user?\n\nBecause maybe that user could be working on them right now?\n\nThe behaviour is safe as is.\n\nCiao,\nDscho\n"}]}