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 git-pull
I'll create a patch.
On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote:
> Jim Garrison writes:
>
> >> -Original Message-
> >> From: Junio C Hamano
> >> Sent: Wednesday, May 07, 2014 1:16 PM
> >> Subject: Re: Beginner question o
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 inco
Jim Garrison 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 reposito
> -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
Jim Garrison 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
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
Jim Garrison 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 th
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 wro
Junio C Hamano wrote:
>But recording the merge to have parents 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'-
Jeff King 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 turns
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
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 s
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
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
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 (thou
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 oth
James Denholm writes:
> On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
> 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 whose summary?
https://www.youtube.co
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
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 people in
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 s
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 wher
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 you
James Denholm 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 where y
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 | g
Felipe Contreras 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. A few old
core p
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.
I
On Sat, 3 May 2014, David Kastrup wrote:
Felipe Contreras writes:
David Kastrup wrote:
Richard Hansen 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 muc
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 determine
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
From: "Jonathan Nieder"
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 circles.
I agr
Philip Oakley wrote:
> From: "Felipe Contreras"
> > 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 minority, it follow
From: "Felipe Contreras"
Sent: Saturday, May 03, 2014 12:23 AM
Philip Oakley wrote:
From: "Felipe Contreras"
> 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 d
On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano 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:
>
> Tutorials of
Felipe Contreras writes:
> David Kastrup wrote:
>> Richard Hansen 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
>> > abou
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 (o
David Kastrup wrote:
> Richard Hansen 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.
>
> S
Richard Hansen 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 turning clockw
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 br
Jeff King 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
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 o
Philip Oakley wrote:
> From: "Felipe Contreras"
> > 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 nothing,
When doing so
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 illustrati
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 r
From: "Felipe Contreras"
Sent: Friday, May 02, 2014 8:05 PM
Philip Oakley wrote:
From: "David Kastrup"
> Marc Branchaud 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 b
From: "Marc Branchaud"
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
found many
d
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
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
> >
Junio C Hamano wrote:
> Felipe Contreras 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
David Lang 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 been
Felipe Contreras 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' and updating the tuto
On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil
Marc Branchaud writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print
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 i
Philip Oakley wrote:
> From: "David Kastrup"
> > Marc Branchaud 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"
Marc Branchaud 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 to make it wor
From: "David Kastrup"
Marc Branchaud 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
Marc Branchaud 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, and I _think_ tha
(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 pul
57 matches
Mail list logo
