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
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
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
49 matches
Mail list logo
