All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Santi Béjar" <sbejar@gmail.com>
To: "Junio C Hamano" <junkio@cox.net>
Cc: "Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic
Date: Tue, 20 Feb 2007 12:21:56 +0100	[thread overview]
Message-ID: <8aa486160702200321l35e309eeqe5799dc56be5dac6@mail.gmail.com> (raw)
In-Reply-To: <7vfy91684y.fsf@assigned-by-dhcp.cox.net>

On 2/20/07, Junio C Hamano <junkio@cox.net> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> >> > There are two cases where the behaviour is changed:
> >> >
> >> > 1) branch.*.merge no longer must exactly match the remote part
> >> >    of the branch fetched. Both are expanded in full (as refs/heads/...)
> >> >    and matched afterwards.
> > ...
> >>  I see this as a regression.
> >> If you are setting configuration, wouldn't you rather see the
> >> behaviour consistent even when remote adds new refs?
>
> Maybe I misread your description, but I took it to mean that you
> are allowing:
>
>         branch.master.merge = a
>
> to mean what we traditionally spelled
>
>         branch.master.merge = refs/heads/a
>
> and guessed (I haven't looked for where it happens in the code)
> the way you do that conversion is by tail-matching the ref; if
> the other end creates "refs/heads/b/a", suddenly remote branch
> b/a starts matching that pattern wouldn't it?

No. branch.master.merge = a is equivalent to refs/heads/a and only
matches with the remote branch refs/heads/a. It continues to exactly
match the two branches, but with the full patch (refs/...). So now it
is possible to have:

[remote "origin"]
url = ...
fetch = refs/heads/*:refs/heads/origin/*

[branch "master"]
remote = origin
merge = master

or the other way:

[remote "origin"]
url = ...
fetch = master:refs/heads/origin

[branch "master"]
remote = origin
merge = refs/heads/master

>
> Earlier we fixed the ambiguous use of branch.*.merge in
> 756373da; I think the same reasoning should apply here.
>
> Configuration is something you set once because you want to
> forget about it afterwards (iow, not having to type every time),
> and I think making sure it names things unambiguously outweighs
> one-time convenience of being able to write the configuration in
> a looser fashion.

It is unambiguous.

But if it is problematic I'll try to keep the current behaviour.

Santi

  reply	other threads:[~2007-02-20 11:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16  8:06 [PATCH/RFC 0/3] Split fetch and merge logic Santi Béjar
2007-02-16  8:09 ` [PATCH/RFC 2/3] git-fetch: " Santi Béjar
2007-02-19 20:44   ` Junio C Hamano
2007-02-19 22:13     ` Santi Béjar
2007-02-19 23:27       ` Junio C Hamano
2007-02-20 11:21         ` Santi Béjar [this message]
2007-02-16  8:10 ` [PATCH/RFC 3/3] t/t5515: fixes for the separate " Santi Béjar
2007-02-16  8:22 ` [PATCH/RFC 0/3] Split " Junio C Hamano
2007-02-16  8:40   ` Santi Béjar
2007-02-16 20:10     ` Junio C Hamano
2007-02-16 20:30       ` Santi Béjar
2007-02-16 21:14         ` Junio C Hamano
2007-02-19  9:47           ` Santi Béjar
     [not found] ` <87zm7eo78x.fsf@gmail.com>
2007-02-16  8:23   ` [PATCH/RFC 1/3] t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch Santi Béjar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8aa486160702200321l35e309eeqe5799dc56be5dac6@mail.gmail.com \
    --to=sbejar@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.