Jeff King writes:
> On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:
>
>> > The updated rule would be more complex. If a remote nickname is
>> > used, and a refspec given from the command line is without colon, a
>> > new special rule overrides the current behaviour and tries to m
On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:
> > The updated rule would be more complex. If a remote nickname is
> > used, and a refspec given from the command line is without colon, a
> > new special rule overrides the current behaviour and tries to match
> > with a configured
On Wed, Aug 15, 2012 at 08:59:02AM +0200, Thomas Rast wrote:
> I have never had a need for a fetch that doesn't update the remote
> namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal
> evidence in support of "the current state is confusing": this thread, or
> the fact that Jan'
Junio C Hamano writes:
> Updating Documentation/pull-fetch-param.txt would be a bear, though.
> The documentation is stale in that it was written in the days back
> when .git/remotes/ was the primary way to configure remotes, and was
> not adjusted to use the termilology used in the [remote "wher
"Holger Hellmuth (IKS)" writes:
> Am 15.08.2012 19:30, schrieb Junio C Hamano:
>> The current rule is very
>> simple and understandable. You either say from the command line
>> exactly what should happen (refspec without colon is the same as the
>> refspec with colon at the end, meaning "do not
Am 15.08.2012 19:30, schrieb Junio C Hamano:
The current rule is very
simple and understandable. You either say from the command line
exactly what should happen (refspec without colon is the same as the
refspec with colon at the end, meaning "do not track"; if you want
to track, you write what t
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> In some sense this is a really bad case of wrong UI design, because we
>>> (this happens on #git a lot) have to teach users not to use the command
>>> so they won't trip over this problem. It would be better to fix th
Junio C Hamano writes:
> Thomas Rast writes:
>
>> In some sense this is a really bad case of wrong UI design, because we
>> (this happens on #git a lot) have to teach users not to use the command
>> so they won't trip over this problem. It would be better to fix the
>> real issue instead. IIRC
Hilco Wijbenga writes:
>> I meant something else than Junio hinted at. Saying
>>
>> git fetch origin master
>> # or by extension
>> git pull origin master
>>
>> does not update the origin/* namespace, not even origin/master. All
>> fetching happens only into FETCH_HEAD. This leads to con
On 14 August 2012 13:12, Thomas Rast wrote:
> Hilco Wijbenga writes:
>
>> On 14 August 2012 10:19, Junio C Hamano wrote:
>>> Hilco Wijbenga writes:
>>>
On 14 August 2012 01:27, Thomas Rast wrote:
> [git pull with two args] it's ok if you use it with an URL instead
> of a remote ni
Thomas Rast writes:
> In some sense this is a really bad case of wrong UI design, because we
> (this happens on #git a lot) have to teach users not to use the command
> so they won't trip over this problem. It would be better to fix the
> real issue instead. IIRC it was even on the 1.8.0 wishli
Hilco Wijbenga writes:
> On 14 August 2012 10:19, Junio C Hamano wrote:
>> Hilco Wijbenga writes:
>>
>>> On 14 August 2012 01:27, Thomas Rast wrote:
[git pull with two args] it's ok if you use it with an URL instead
of a remote nickname
>>>
>>> Why would that be okay? What is the dif
Hilco Wijbenga writes:
> I suppose I'm not entirely clear on how this two step process is
> "safer". Doing "git fetch" would seem to be harmless, right? So the
> problem is with "git merge" but master should always be "behind"
> origin/master so that "git merge" should just FF to origin/master
>
On 14 August 2012 10:19, Junio C Hamano wrote:
> Hilco Wijbenga writes:
>
>> On 14 August 2012 01:27, Thomas Rast wrote:
>>> Hilco Wijbenga writes:
>>>
>>>> # On branch master
>>>> # Your branch and 'origin/master' ha
Hilco Wijbenga writes:
> On 14 August 2012 01:27, Thomas Rast wrote:
>> Hilco Wijbenga writes:
>>
>>> # On branch master
>>> # Your branch and 'origin/master' have diverged,
>>> # and have 250 and 19 different commit(s) each, respectively.
On 14 August 2012 09:02, PJ Weisberg wrote:
> On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga
> wrote:
>> Hi all,
>>
>> A colleague of mine (after a relatively long absence) noticed the
>> following when running "git status":
>>
>> # On bra
On 14 August 2012 01:27, Thomas Rast wrote:
> Hilco Wijbenga writes:
>
>> # On branch master
>> # Your branch and 'origin/master' have diverged,
>> # and have 250 and 19 different commit(s) each, respectively.
>> #
>> nothing to commit (working direc
On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga
wrote:
> Hi all,
>
> A colleague of mine (after a relatively long absence) noticed the
> following when running "git status":
>
> # On branch master
> # Your branch and 'origin/master' have diverged,
> #
Hilco Wijbenga writes:
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 250 and 19 different commit(s) each, respectively.
> #
> nothing to commit (working directory clean)
>
> He asked me what to do and I told him to do what ha
Hi all,
A colleague of mine (after a relatively long absence) noticed the
following when running "git status":
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 250 and 19 different commit(s) each, respectively.
#
nothing to commit (working direct
20 matches
Mail list logo
