git.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).