[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stupid git!
From: |
Eli Zaretskii |
Subject: |
Re: Stupid git! |
Date: |
Mon, 14 Sep 2015 16:38:47 +0300 |
> From: David Kastrup <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Mon, 14 Sep 2015 14:47:15 +0200
>
> >> >> Pulling is not a really good thing to do if you have uncommitted work.
> >> >
> >> > I'm doing it all the time, and have yet to report a single problem.
> >> >
> >> > It's the simplest way of minimizing the probability of spurious
> >> > merges, when someone else pushes before you.
> >>
> >> Nope. The simplest way is to git fetch rather than git pull.
> >
> > How is using 2 commands instead of one, and learning an additional
> > command, simpler?
>
> The "simplest way of minimizing the probability of spurious merges" is
> not to execute commands doing possibly unintended merges.
If your recipe would have been "don't use pull", it would have been
simpler. But that's not what it says, it says "use fetch and merge
instead", which is definitely not simpler.
> If you insist on only ever using git pull, it also has an option
> --ff-only which will refuse to do anything non-trivial.
At the cost of having to learn the option. Not simpler.
> >> > If you commit then pull, and someone else pushed in between, you
> >> > will get that "merged branch master" thing.
> >>
> >> It that's not what you want, git pull -r will rebase just fine.
> >
> > We've concluded long ago that "pull --rebase" is trouble when you
> > merge from and to feature branches, so I'm trying to stay away of that
> > path.
>
> That's ridiculous. What we have concluded is that setting --rebase as a
> default was not likely a good idea because of feature branches. But it
> is quite absurd not to use the option for those cases where you indeed
> want a rebase instead of a merge commit.
It's not absurd when you take muscle memory into consideration. We
are talking here about routine operations (since you don't know in
advance whether a pull will cause conflicts or a need to merge), not
about an option to be used in specific rare circumstances.
- Re: Stupid git!, (continued)
- Re: Stupid git!, Alan Mackenzie, 2015/09/12
- Re: Stupid git!, Dmitry Gutov, 2015/09/12
- Re: Stupid git!, Alan Mackenzie, 2015/09/12
- Re: Stupid git!, Sven Axelsson, 2015/09/13
- Re: Stupid git!, Alan Mackenzie, 2015/09/14
- Re: Stupid git!, David Kastrup, 2015/09/14
- Re: Stupid git!, Eli Zaretskii, 2015/09/14
- Re: Stupid git!, David Kastrup, 2015/09/14
- Re: Stupid git!, Eli Zaretskii, 2015/09/14
- Re: Stupid git!, David Kastrup, 2015/09/14
- Re: Stupid git!,
Eli Zaretskii <=
- Re: Stupid git!, David Kastrup, 2015/09/14
- Re: Stupid git!, Stefan Monnier, 2015/09/14
- Re: Stupid git!, Eli Zaretskii, 2015/09/13
- Re: Stupid git!, Alan Mackenzie, 2015/09/14
- Re: Stupid git!, Stephen J. Turnbull, 2015/09/14
- Re: Stupid git!, Dmitry Gutov, 2015/09/13
- Re: Stupid git!, Stephen J. Turnbull, 2015/09/13
- Re: Stupid git!, Dmitry Gutov, 2015/09/14
- Re: Stupid git!, Alan Mackenzie, 2015/09/14
- Re: Stupid git!, Eli Zaretskii, 2015/09/14