Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>
> >>> This is irrelevant, it's an implementation detail of 'git pull'. *THE
> >>> USER* is not running 'git fetch .'
> >>
> >> To those who fear runni
"Philip Oakley" writes:
> From: "Junio C Hamano"
> Sent: Friday, May 17, 2013 7:30 PM
> Subject: Re: [PATCH 1/3] fetch: add --allow-local option
>
> [...]
>
>> So when "the user" is running "git fetch" on "mywork" branch
Felipe Contreras writes:
> On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> This is irrelevant, it's an implementation detail of 'git pull'. *THE
>>> USER* is not running 'git fetch .'
>>
>> To those who fear running "git pull", the following has worked
On Sat, May 18, 2013 at 3:53 PM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Saturday, May 18, 2013 3:23 PM
>>
>> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley
>> wrote:
>>>
>>> From: "Junio C Hamano"
>>> Sen
From: "Felipe Contreras"
Sent: Saturday, May 18, 2013 3:23 PM
On Sat, May 18, 2013 at 8:12 AM, Philip Oakley
wrote:
From: "Junio C Hamano"
Sent: Friday, May 17, 2013 7:30 PM
Subject: Re: [PATCH 1/3] fetch: add --allow-local option
[...]
So when "the user&q
On Sat, May 18, 2013 at 8:12 AM, Philip Oakley wrote:
> From: "Junio C Hamano"
> Sent: Friday, May 17, 2013 7:30 PM
> Subject: Re: [PATCH 1/3] fetch: add --allow-local option
>
> [...]
>
>
>> So when "the user" is running "git fetch" on
From: "Junio C Hamano"
Sent: Friday, May 17, 2013 7:30 PM
Subject: Re: [PATCH 1/3] fetch: add --allow-local option
[...]
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master",
On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> This is irrelevant, it's an implementation detail of 'git pull'. *THE
>> USER* is not running 'git fetch .'
>
> To those who fear running "git pull", the following has worked as a
> quick way to "preview" what
Felipe Contreras writes:
> This is irrelevant, it's an implementation detail of 'git pull'. *THE
> USER* is not running 'git fetch .'
To those who fear running "git pull", the following has worked as a
quick way to "preview" what they would be getting.
git fetch
git log ..FETCH_
On Thu, May 16, 2013 at 6:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> If you come from "git pull" is "git fetch" + "git merge",
> and if your current branch is integrating with you
Felipe Contreras writes:
> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
If you come from "git pull" is "git fetch" + "git merge",
and if your current branch is integrating with your local branch,
>>>
>>> How many times do I have to say that 'gi
On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> If you come from "git pull" is "git fetch" + "git merge",
>>> and if your current branch is integrating with your local branch,
>>
>> How many times do I have to say that 'git pull' is not 'git fetch' +
>> 'gi
Felipe Contreras writes:
>> If you come from "git pull" is "git fetch" + "git merge",
>> and if your current branch is integrating with your local branch,
>
> How many times do I have to say that 'git pull' is not 'git fetch' +
> 'git merge'?
>
> You must think everybody has 'merge.defaulttoupstr
On Thu, May 16, 2013 at 11:38 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> That doesn't change the fact that 'git fetch .' does not make any
>> sense whatsoever. The user *will* get confused when (s)he does 'git
>> fetch' and nothing happens. The problem is not solved.
>>
>> % git ch
Felipe Contreras writes:
> That doesn't change the fact that 'git fetch .' does not make any
> sense whatsoever. The user *will* get confused when (s)he does 'git
> fetch' and nothing happens. The problem is not solved.
>
> % git checkout -b fixes master
> % git fetch
> % git branch -u master
> %
On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano wrote:
> I _think_ the real reason you want a "git fetch" while on "mywork"
> to go to 'origin' is because you are building your "master" off of
> somebody else's work that comes from 'origin', and you want to check
> what has changed to see what y
Felipe Contreras writes:
> So that it becomes possible to override the behavior when the remote
> tracked is '.'; if it is, we default back to 'origin'.
I know I was the stupid one who originally suggested this, but I
think this is a wrong direction to go. I do not think it solves
your "I do no
On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Answer: because 'git fetch .' doesn't make any sense. So if
>> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.
>
> I agree that 'git fetch .' is currently not useful (and I am not
> aga
Felipe Contreras wrote:
> Answer: because 'git fetch .' doesn't make any sense. So if
> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.
I agree that 'git fetch .' is currently not useful (and I am not
against changing its behavior), but my question pertains to why you
are re
On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Why would I do that? When I do 'git rebase' I want to rebase on top of
>> 'master', not 'origin/master' (or whatever the upstream of 'master'
>> is).
>
> Ah, so you want @{u} to point to refs/heads/master, bu
Felipe Contreras wrote:
> Why would I do that? When I do 'git rebase' I want to rebase on top of
> 'master', not 'origin/master' (or whatever the upstream of 'master'
> is).
Ah, so you want @{u} to point to refs/heads/master, but want to modify
fetch to act on the hard-coded "origin", not @{u} (wo
On Thu, May 16, 2013 at 4:27 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> % git checkout -t -b devel master
>
> Interesting. Have you considered changing -t to inherit the parent
> branch's remote? (Would everyone like that?)
Why would I do that? When I do 'git rebase' I want to
Felipe Contreras wrote:
> % git checkout -t -b devel master
Interesting. Have you considered changing -t to inherit the parent
branch's remote? (Would everyone like that?)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
On Thu, May 16, 2013 at 3:25 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> So that it becomes possible to override the behavior when the remote
>> tracked is '.'; if it is, we default back to 'origin'.
>
> What is the problem you're trying to solve? Why do you have
> branch..remote
Felipe Contreras wrote:
> So that it becomes possible to override the behavior when the remote
> tracked is '.'; if it is, we default back to 'origin'.
What is the problem you're trying to solve? Why do you have
branch..remote set to '.' in the first place, if you meant
origin? 'git fetch .' cur
So that it becomes possible to override the behavior when the remote
tracked is '.'; if it is, we default back to 'origin'.
To do this, we need to add a new helper fetchremote_get() that accepts
the boolean to enable/disable this behavior.
The default is 'true' which shouldn't cause any change in
26 matches
Mail list logo
