Re: Pull is Evil

Andreas Krey writes: > On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote: > ... >> What the gibbins? I don't even use git pull. > > I do, but I watch for the fast-forward message > and undo as appropriate. > >> I use git fetch, and then, depending on my needs, I rebase or merge. > > I woul

Re: Pull is Evil

On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote: ... > What the gibbins? I don't even use git pull. I do, but I watch for the fast-forward message and undo as appropriate. > I use git fetch, and then, depending on my needs, I rebase or merge. I wouldn't mind that, but I have a century o

RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)

W. Trevor King wrote: > I've renamed this sub-thread (which started around $gmane/247835) to > avoid potential confusion/dilution. Thanks. > > > The goal is to train them to do: > > > > > > > % git config --global pull.mode none > > > > % git fetch > > > > % git merge --no-ff > > Sticking

pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)

On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: > > > W. Trevor King wrote: > > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > > > > It would matter almost exac

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > > > It would matter almost exactly zero. > > > > > > Some folks have explicit merge policies, and deciding

Re: Pull is Evil

On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > > It would matter almost exactly zero. > > > > Some folks have explicit merge policies, and deciding how much > > that matters is prob

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > It would matter almost exactly zero. > > Some folks have explicit merge policies, and deciding how much that > matters is probably best left up to the projects themselves and not > decided in Git code. L

Re: Pull is Evil

Junio C Hamano writes: > Marc Branchaud writes: > >> I may be mistaken, but I think "git pull" evolved to try to address the >> detached-HEAD risk (at least in part). > > You are totally mistaken. > > "git pull" was part of the things to make git usable by Linus before > 1.0 release, and matches

Re: Pull is Evil

On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > W. Trevor King wrote [1]: > > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: > > > W. Trevor King wrote: > > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > > > > W. Trevor King wrote: >

Re: Pull is Evil

Marc Branchaud writes: > I may be mistaken, but I think "git pull" evolved to try to address the > detached-HEAD risk (at least in part). You are totally mistaken. "git pull" was part of the things to make git usable by Linus before 1.0 release, and matches the integrator workflow perfectly wel

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > > > W. Trevor King wrote: > > > > > My proposed --prompt behavior is for folks who think “I often run > > >

Re: Pull is Evil

"W. Trevor King" writes: > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: >> W. Trevor King wrote: >> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: >> > > W. Trevor King wrote: >> > > > My proposed --prompt behavior is for folks who think “I often run >> >

Re: Pull is Evil

On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > > W. Trevor King wrote: > > > > My proposed --prompt behavior is for folks who think “I often run > > > > this command without thinking

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > My proposed --prompt behavior is for folks who think “I often run > > > this command without thinking it through all the way. I'm also > > > not used to reading Git's output an

Re: Pull is Evil

On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > My proposed --prompt behavior is for folks who think “I often run > > this command without thinking it through all the way. I'm also > > not used to reading Git's output and using 'reset --hard' with the

Re: Pull is Evil

Andreas Krey writes: > On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: > ... >> I didn't mean "replace 'pull' with 'update' everywhere". I meant >> "Introduce 'update' that lets integrate your history into that from >> the remote, which is to integrate in a direction opposite from how

Re: Pull is Evil

Andreas Krey wrote: > My personal beef with 'git pull' is still that sometimes (namely in > the 'git pull && git push' sequence) it should reverse the order of > the parents in the merge commit, so that *my* commits look like an > integrated topic branch, instead of the former mainline. I haven't

Re: Pull is Evil

On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: ... > I didn't mean "replace 'pull' with 'update' everywhere". I meant > "Introduce 'update' that lets integrate your history into that from > the remote, which is to integrate in a direction opposite from how > 'pull' does". That still

Re: Pull is Evil

On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote: ... > > 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 > "mai

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: > > If that was the case the user wouls have run `git merge > > --no-ff`. Only expereinced users would answer 'no'. > > Folks who are setting any ff options don't need any of these training > wheels. Indeed.

Re: Pull is Evil

On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: > > > W. Trevor King wrote: > > > > Fast-forward $current_branch by $count commits to $repository > > > > $refpec? > > > > > > Why would a

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

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote: > > Nobody ever complained about somebody doing a fast-forward by mistake. > > Unless they fast-forward merged a feature branch into master, but the > project prefers explicitly-merged feature branches with a

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 configu

Re: Pull is Evil

On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote: > Nobody ever complained about somebody doing a fast-forward by mistake. Unless they fast-forward merged a feature branch into master, but the project prefers explicitly-merged feature branches with a cover-letter explaination in th

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 l

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 maintenan

Re: Pull is Evil

Philip Oakley wrote: > The point that there is no easy solution to an updated default pull > action that is right for everybody, straight out of the box, I think is > now fairly obvious, a summarised by Marc. I certainly avoid pull. Yes, I avoid it too, and quite a lot of people. > My 'solution

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

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 …'). Th

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 runni

Re: Pull is Evil

Oops.. From: "Philip Oakley" From: "Marc Branchaud" Sent: Wednesday, April 30, 2014 8:45 PM [...] I don't think we'll ever be able to create a One "Git Pull" To Rule Them All. At best we'll end up with something with enough knobs that it could be configured to work in most workflows (I think

Re: Pull is Evil

From: "Marc Branchaud" Sent: Wednesday, April 30, 2014 8:45 PM [...] I don't think we'll ever be able to create a One "Git Pull" To Rule Them All. At best we'll end up with something with enough knobs that it could be configured to work in most workflows (I think we're actually pretty close to

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 h

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 ru

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 maintenan

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`. Ther

Re: Pull is Evil

On 14-05-01 03:22 PM, Felipe Contreras wrote: > Marc Branchaud wrote: >> 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 fet

Re: Pull is Evil

brian m. carlson wrote: > At work, we have a workflow where we merge topic branches as > non-fast-forward, so that we have a record of the history (including > who reviewed the code), but when we want to just update our local > branches, we always want fast-forward: > > git checkout maintenance-

Re: Pull is Evil

Marc Branchaud wrote: > 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-r

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > > brian m. carlson wrote: > >> .. > >> At work, we have a workflow where we merge topic branches as > >> non-fast-forward, so that we have a record of the history (including who > >> reviewed the code), but when we want to just update our local

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 >>>

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

Re: Pull is Evil

Felipe Contreras writes: > brian m. carlson wrote: >> .. >> At work, we have a workflow where we merge topic branches as >> non-fast-forward, so that we have a record of the history (including who >> reviewed the code), but when we want to just update our local branches, >> we always want fast-fo

Re: Pull is Evil

On 14-05-01 05:46 AM, brian m. carlson wrote: > On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: >> Marc Branchaud wrote: >>> On 14-04-30 04:14 PM, Felipe Contreras wrote: What is wrong when `git pull` merges a fast-forward? >>> >>> Nothing. Everything. It depends. >> >> It

Re: Pull is Evil

brian m. carlson wrote: > On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: > > Marc Branchaud wrote: > > > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > > > What is wrong when `git pull` merges a fast-forward? > > > > > > Nothing. Everything. It depends. > > > > It depends

Re: Pull is Evil

On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: > Marc Branchaud wrote: > > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > > What is wrong when `git pull` merges a fast-forward? > > > > Nothing. Everything. It depends. > > It depends on what? I don't see how a fast-forward

Re: Pull is Evil

Marc Branchaud wrote: > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > Marc Branchaud wrote: > >> All that said, I don't object to any attempts at improving the command > >> either. But I also don't see any kind of improvement that would lead > >> me to start using "git pull" let alone recommen

Re: Pull is Evil

On 14-04-30 04:14 PM, Felipe Contreras wrote: > Marc Branchaud wrote: >> All that said, I don't object to any attempts at improving the command >> either. But I also don't see any kind of improvement that would lead >> me to start using "git pull" let alone recommending it to new users. > > What

Re: Pull is Evil

On 14-04-30 04:01 PM, Junio C Hamano wrote: > > Maybe I was unclear. > > I didn't mean "replace 'pull' with 'update' everywhere". I meant > "Introduce 'update' that lets integrate your history into that from > the remote, which is to integrate in a direction opposite from how > 'pull' does".

Re: Pull is Evil

Marc Branchaud wrote: > All that said, I don't object to any attempts at improving the command > either. But I also don't see any kind of improvement that would lead > me to start using "git pull" let alone recommending it to new users. What is wrong when `git pull` merges a fast-forward? The pro

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > Junio C Hamano wrote: > >> Felipe Contreras writes: > >> > Matthieu Moy wrote: > >> >> Felipe Contreras writes: > >> >> ... > >> >> > Yes, this has been discussed many times in the past, and everyone > >> >> > agrees > >> >> > the default beh

Re: Pull is Evil

Marc Branchaud wrote: > All that said, I don't object to any attempts at improving the command > either. But I also don't see any kind of improvement that would lead me to > start using "git pull" let alone recommending it to new users. If "git pull" starts using --ff-only by default then I migh

Re: Pull is Evil

Marc Branchaud writes: > On 14-04-30 10:55 AM, Junio C Hamano wrote: >> Marc Branchaud writes: > ... >>> Anyway, rather than ranting on I'll just suggest that there's not enough >>> commonality between the ways people use git to make it worthwhile trying to >>> teach pull how to deal with a sign

Re: Pull is Evil

Felipe Contreras writes: > Junio C Hamano wrote: >> Felipe Contreras writes: >> > Matthieu Moy wrote: >> >> Felipe Contreras writes: >> >> ... >> >> > Yes, this has been discussed many times in the past, and everyone agrees >> >> > the default behavior is not correct. >> >> >> >> You definitel

Re: Pull is Evil

On 14-04-30 10:55 AM, Junio C Hamano wrote: > Marc Branchaud writes: > >> But I'm definitely biased because I think pull is pretty much broken: >> >> * New users are encouraged to use pull, but all too often the default >> fetch-then-merge behaviour doesn't match their expectations and they end u

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > Matthieu Moy wrote: > >> Felipe Contreras writes: > >> ... > >> > Yes, this has been discussed many times in the past, and everyone agrees > >> > the default behavior is not correct. > >> > >> You definitely have a strange notion of "everyone"

Re: Pull is Evil

Felipe Contreras writes: > Matthieu Moy wrote: >> Felipe Contreras writes: >> ... >> > Yes, this has been discussed many times in the past, and everyone agrees >> > the default behavior is not correct. >> >> You definitely have a strange notion of "everyone". > > Do I? Let's look at some of the

Re: Pull is Evil

Matthieu Moy wrote: > Felipe Contreras writes: > > > Marc Branchaud wrote: > >> But I'm definitely biased because I think pull is pretty much broken: > >> > >> * New users are encouraged to use pull, but all too often the default > >> fetch-then-merge behaviour doesn't match their expectations a

Re: Pull is Evil

Felipe Contreras writes: > Marc Branchaud wrote: >> But I'm definitely biased because I think pull is pretty much broken: >> >> * New users are encouraged to use pull, but all too often the default >> fetch-then-merge behaviour doesn't match their expectations and they end up >> starting threads

RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

Marc Branchaud wrote: > But I'm definitely biased because I think pull is pretty much broken: > > * New users are encouraged to use pull, but all too often the default > fetch-then-merge behaviour doesn't match their expectations and they end up > starting threads like this one on the mailing list

Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

Marc Branchaud writes: > But I'm definitely biased because I think pull is pretty much broken: > > * New users are encouraged to use pull, but all too often the default > fetch-then-merge behaviour doesn't match their expectations and they end up > starting threads like this one on the mailing li

Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

On 14-04-28 02:41 PM, Junio C Hamano wrote: > Marat Radchenko writes: > >> Problem #1: TortoiseGit GUI windows for common tasks have a heck >> lots of controls that a common Git user will never need. > > Do people around TortoiseGit lurk on this list? Otherwise this may > not be something we ca