After poking this hornet's nest I pretty much have stood back and not
participated in the ensuing discussions. But having unleashed the hornets I
feel I should at least say something, if only to assure people that I'm not
ignoring their plight.
There have been various proposals to modify
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed most of the
pull is (mostly) evil discussion but one facet still puzzles me: the idea
that pull will do a merge in the wrong direction sometimes.
Do I
Jim Garrison jim.garri...@nwea.org writes:
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed
most of the pull is (mostly) evil discussion but one facet still
puzzles me: the idea that pull will do a merge
On Wed, May 07, 2014 at 03:40:28PM +, Jim Garrison wrote:
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed
most of the pull is (mostly) evil discussion but one facet still
puzzles me: the idea that pull
Jim Garrison jim.garri...@nwea.org writes:
During my initial self-education I came across the maxim don't
pull, fetch+merge instead and have been doing that. I think I
followed most of the pull is (mostly) evil discussion but one
facet still puzzles me: the idea that pull will do a merge
-Original Message-
From: Junio C Hamano
Sent: Wednesday, May 07, 2014 1:16 PM
Subject: Re: Beginner question on Pull is mostly evil
No. This is most often true for people who use a single repository as a
place for everybody to meet, in the same way as SVN.
[snip lots of excellent
Jim Garrison jim.garri...@nwea.org writes:
-Original Message-
From: Junio C Hamano
Sent: Wednesday, May 07, 2014 1:16 PM
Subject: Re: Beginner question on Pull is mostly evil
No. This is most often true for people who use a single repository as a
place for everybody to meet
Hi.
I might be late to this discussion, but here either
something I don't understand or something is missed.
On Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote:
In my experience 'git pull' is mostly (only?) used for the following
three tasks:
1. update a local branch to
I'll create a patch.
On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote:
Jim Garrison jim.garri...@nwea.org writes:
-Original Message-
From: Junio C Hamano
Sent: Wednesday, May 07, 2014 1:16 PM
Subject: Re: Beginner question on Pull is mostly evil
Jeff King p...@peff.net writes:
I realize this has veered off into talking about an update command,
and not necessarily pull, but since there a lot of proposals floating
around, I wanted to make one point: if we are going to do such a switch,
let's please make it something the user explicitly
Junio C Hamano wrote:
But recording the merge to have parents Z C does not give us
the first-parent is the trunk worldview, in the presense of B.
We would prefer to end up with a history more like this:
-A O
\ \
X---Y---Z---B'--C'
On 2014-05-03 06:00, John Szakmeister wrote:
FWIW, at my company, we took another approach. We introduced a `git
ffwd` command that fetches from all remotes, and fast-forwards all
your local branches that are tracking a remote, and everyone on the
team uses it all the time. It should be said
Richard Hansen wrote:
On 2014-05-03 06:00, John Szakmeister wrote:
FWIW, at my company, we took another approach. We introduced a `git
ffwd` command that fetches from all remotes, and fast-forwards all
your local branches that are tracking a remote, and everyone on the
team uses it all
Felipe Contreras felipe.contre...@gmail.com writes:
David Lang wrote:
note that this is one person taking the I don't see any commits from
you so your opinion doesn't count attitude.
Wrong. I said it doesn't count for the project.
There are a number of commits from me that actually count.
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
didn't run `git log | grep
James Denholm nod.h...@gmail.com writes:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to make sure I understand your full
James Denholm wrote:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com
wrote:
James Denholm wrote:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track
record
of the
James Denholm nod.h...@gmail.com writes:
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
But I'm not going to bother any more with you, you are just spreading
lies and tainting the discussion.
Well, maybe we'll see what other folks think.
According to
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in
Richard Hansen wrote:
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I
On 2014-05-02 14:13, Junio C Hamano wrote:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to.
I think the fundamental difference is in the relationship between the
local and the remote
Richard Hansen rhan...@bbn.com writes:
These three usage patterns are at odds; it's hard to change the
default behavior of 'git pull' to favor one usage case without harming
another. Perhaps this is why there's so much disagreement about what
'git pull' should do.
Should a screwdriver be
David Kastrup wrote:
Richard Hansen rhan...@bbn.com writes:
These three usage patterns are at odds; it's hard to change the
default behavior of 'git pull' to favor one usage case without
harming another. Perhaps this is why there's so much disagreement
about what 'git pull' should do.
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the user wants
from 'git pull'.
In my experience 'git pull' is mostly (only?)
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Richard Hansen rhan...@bbn.com writes:
These three usage patterns are at odds; it's hard to change the
default behavior of 'git pull' to favor one usage case without
harming another. Perhaps this is why there's so
On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
Your earlier long-hand, together with the two examples that pulls
into the same maint branch Brian gave us, may give us a better
starting points to think about a saner way.
To me, the problem sounds like:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Saturday, May 03, 2014 12:23 AM
Philip Oakley wrote:
From: Felipe Contreras felipe.contre...@gmail.com
So? No defaults can please absolutely everyone, the best anybody
can
do is try to please the majority of people, and merging
Philip Oakley wrote:
From: Felipe Contreras felipe.contre...@gmail.com
When doing something is better for the vast majority of people, that's
what should be done by default, unless the results are catastrophic
for
the minority.
Since doing something is not catastrophic to the
From: Jonathan Nieder jrnie...@gmail.com
Sent: Friday, May 02, 2014 11:53 PM
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing
nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the user wants
from 'git pull'.
Richard Hansen wrote:
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the
On Sat, 3 May 2014, David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Richard Hansen rhan...@bbn.com writes:
These three usage patterns are at odds; it's hard to change the
default behavior of 'git pull' to favor one usage case without
harming
David Lang wrote:
note that this is one person taking the I don't see any commits from
you so your opinion doesn't count attitude.
Wrong. I said it doesn't count for the project. Do you honestly
believe Junio cares about what some random guy on the list thinks about
default aliases? No.
If he
(Apologies for not CCing all the folks who've participated in the Pull is
Evil thread -- I couldn't find a good branch of that thread for this message.)
OK, so maybe git pull is just Mostly Evil. People seem to have found many
different ways to make it work for them.
But in reality git pull
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run git help pull
for guidance.
Fetching is uncontentious,
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run git help pull
for
Marc Branchaud marcn...@xiplink.com writes:
(Apologies for not CCing all the folks who've participated in the Pull is
Evil thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe git pull is just Mostly Evil. People seem to have found many
different ways
Philip Oakley wrote:
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new command to make the
distinction stand out more. What if the command sequence were like
this
On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup d...@gnu.org
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing
Felipe Contreras felipe.contre...@gmail.com writes:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to. Perhaps a way to solve this issue, without
having to introduce a new 'git update'
David Lang da...@lang.hm writes:
On Fri, 2 May 2014, David Kastrup wrote:
It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.
confusion at least. It's not fatal confusion, people have
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to. Perhaps a way to solve this issue, without
having to
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new command to make the
Jeff King wrote:
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new
From: Marc Branchaud marcn...@xiplink.com
Sent: Friday, May 02, 2014 4:37 PM
(Apologies for not CCing all the folks who've participated in the
Pull is
Evil thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe git pull is just Mostly Evil. People seem to have
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Friday, May 02, 2014 8:05 PM
Philip Oakley wrote:
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to
do
*nothing*. It should just print out
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
They can do:
% git pull origin master
That shouldn't revese the bases.
Then they have to remember to do that every time, no? That seems a
little error-prone versus setting a config option.
Such users are going to run git
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
Potential next steps:
a. Documentation or test patch illustrating
Philip Oakley wrote:
From: Felipe Contreras felipe.contre...@gmail.com
So? No defaults can please absolutely everyone, the best anybody can
do is try to please the majority of people, and merging
fast-forwards only does that.
That assumes that doing something is better than doing
Jeff King wrote:
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
They can do:
% git pull origin master
That shouldn't revese the bases.
Then they have to remember to do that every time, no? That seems a
little error-prone versus setting a config option.
Yes.
Jeff King p...@peff.net writes:
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a
57 matches
Mail list logo
