Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). No need for detached heads with Brian's local maintenance-branch. If you're teaching and just need folks merging the remote's HEAD, you can avoid namespaces and remotes entirely: git fetch git://example.net/main-repo.git git merge --ff-only FETCH_HEAD although I doubt “the remote's HEAD” will be easier to explain than the namespaced, remote-tracking branches it replaces. It's certainly not worth the hassle of un-training FETCH_HEAD-merges later on ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). No need for detached heads with Brian's local maintenance-branch. Yes. OTOH, no need to bother keeping a local maintenance-branch up to date if you use a detached HEAD. If you're teaching and just need folks merging the remote's HEAD, you can avoid namespaces and remotes entirely: git fetch git://example.net/main-repo.git git merge --ff-only FETCH_HEAD although I doubt “the remote's HEAD” will be easier to explain than the namespaced, remote-tracking branches it replaces. It's certainly not worth the hassle of un-training FETCH_HEAD-merges later on ;). Agreed. I wouldn't advocate teaching people about FETCH_HEAD as if it were something they should use regularly. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote: The only problem would be when it's not desirable, however, that's a problem of the user's ignorance, and the failure of the project's policity to communicate clearly to him that he should be running `git merge --no-ff`. There's absolutely nothing we can do to help him. I think “user ignorange” is the *only* problem with git pull. Once you understand the ff flags, you can set them however you like, and pull will do what you tell it to. The only thing we could do is not allow fast-forward merges either, in which case `git pull` becomes a no-op that can't possibly do anything ever. My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. The space in 'git pull' makes a shell-side: $ alias 'git pull'='echo try fetch/merge!' solution unfeasible, and clobbering /usr/libexec/git-core/git-pull seems a bit extreme. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote: On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have to rely on the reflog if they accidentally commit and then checkout something else (ignoring Git's warning). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Fast-forward $current_branch by $count commits to $repository $refpec? and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On 14-05-01 02:30 PM, W. Trevor King wrote: I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have to rely on the reflog if they accidentally commit and then checkout something else (ignoring Git's warning). All sound practices that I think are perfectly fine. I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). This risk was pretty real before the reflog came about (I'm under the impression -- and too lazy to check -- that git pull predates the reflog; please forgive me if I'm mis-perceiving the timeline). But these days there's hardly any risk to using a detached HEAD. Plus nowadays I think it's commonly accepted that using topic branches is a git best practice. The notion of doing work on a generically-named branch like maint seems archaic. So what benefit does git pull provide? In your particular case, you're using git pull to help you track your reviews of the upstream branch. To me this seems more like you taking advantage of a git pull side-effect than using the command as it is intended to be used. Certainly there are other ways that git can track this for you. A simple, aliasable, git tag -f LastReviewPoint upstream/branch seems just as effective to me (but then, I'm not you). M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote: The only problem would be when it's not desirable, however, that's a problem of the user's ignorance, and the failure of the project's policity to communicate clearly to him that he should be running `git merge --no-ff`. There's absolutely nothing we can do to help him. I think “user ignorange” is the *only* problem with git pull. That, and the fact that 'git pull' does something wrong by default. The only thing we could do is not allow fast-forward merges either, in which case `git pull` becomes a no-op that can't possibly do anything ever. My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. The space in 'git pull' makes a shell-side: $ alias 'git pull'='echo try fetch/merge!' solution unfeasible, and clobbering /usr/libexec/git-core/git-pull seems a bit extreme. What is wrong with 'git pull' doing a merge when it can be fast-forward? -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? But your wording made me realize that my proposed option 'merge-ff-only' is not appropriate, because in theroy the user can think about it as 'rebase-ff-only'; in other words, a 'fast-forward' is not really a merge, and not really a rebase. and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
Marc Branchaud wrote: So what benefit does git pull provide? The same that 'hg update' provies: a way for the user fetch/pull the latest changes and check them out into the working directory. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote: On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. I actually need my local copy to be up-to-date. Part of my workflow, which I omitted for the sake of brevity, is running scripts that rely on my local branch's name, format, and contents. My use case is that I'm one of several code reviewers, and I update my branch, merge in another developer's changes, review them, and then push them if they're good. I need to pull from the main repo immediately before merging, to minimize the chances that someone else will have pushed before me, which would result in me having to redo the merge (because the push has to be fast-forward). I just used this to illustrate the fact that there isn't actually one completely correct case with pull. I have aliases for pull (and merge) --ff-only and --no-ff, and I never actually use plain git pull unless I really don't care whether or not it's a fast-forward. So I'm okay with the status quo because I have distinct choices for merge, no merge, and don't care. I don't really have a strong opinion, though, as long as those three options remain. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [git] Re: Pull is Evil
brian m. carlson wrote: I just used this to illustrate the fact that there isn't actually one completely correct case with pull. Nobody is arguing otherwise. The argument is that `git pull` by default can be made more sensible. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. I think matching rm, mv, cp, etc. is good, but I'd be ok with --prompt. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? Because the want explicit merges when they bring in topic branches? and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. So I should submit an orthogonal patch with -i/--interative/--prompt? Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. I think matching rm, mv, cp, etc. is good, but I'd be ok with --prompt. Those are actually interactive. `git mergetool --prompt` is an exactly of a configration where it's interactivity is constrainted to a single input. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? Because the want explicit merges when they bring in topic branches? If that was the case the user wouls have run `git merge --no-ff`. Only expereinced users would answer 'no'. and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. So I should submit an orthogonal patch with -i/--interative/--prompt? I'm not entirely sure what would be the ideal behavior. For example, I'm thinking that by default when the a fast-forward is possible, just do it, when it's not, ask if the user wants to do a merge or a rebase, if the user just press 'enter' a merge is attempted. In addition a summary of the commits ahead behind would be helpful. If the user wants to cancel the operation, he can just do CTRL+C. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
