[PATCH 0/3] fetch: fix '.' fetching

[PATCH 0/3] fetch: fix '.' fetching

[Felipe Contreras]

Hi,

It's quite annoying that 'git fetch' tries to fetch '.' when the upstream
branch is a local one. This patch series fixes that, and while on it, it also
fixes 'git push'.

Felipe Contreras (3):
  fetch: add --allow-local option
  fetch: switch allow-local off by default
  remote: disable allow-local for pushes

 builtin/fetch.c         |  6 +++++-
 git-pull.sh             |  2 +-
 remote.c                | 17 ++++++++++++++---
 remote.h                |  1 +
 t/t5513-fetch-track.sh  | 14 ++++++++++++++
 t/t5528-push-default.sh |  7 +++++++
 6 files changed, 42 insertions(+), 5 deletions(-)

-- 
1.8.3.rc1.579.g184e698

[PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

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 behavior.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/fetch.c |  6 +++++-
 remote.c        | 17 ++++++++++++++---
 remote.h        |  1 +
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b6b1df..2efbd7b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -39,6 +39,7 @@ static struct strbuf default_rla = STRBUF_INIT;
 static struct transport *transport;
 static const char *submodule_prefix = "";
 static const char *recurse_submodules_default;
+static int allow_local = 1;
 
 static int option_parse_recurse_submodules(const struct option *opt,
 				   const char *arg, int unset)
@@ -90,6 +91,9 @@ static struct option builtin_fetch_options[] = {
 	{ OPTION_STRING, 0, "recurse-submodules-default",
 		   &recurse_submodules_default, NULL,
 		   N_("default mode for recursion"), PARSE_OPT_HIDDEN },
+	{ OPTION_SET_INT, 0, "allow-local", &allow_local, NULL,
+		   N_("allow fetching from local repository"),
+		   PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1 },
 	OPT_END()
 };
 
@@ -1006,7 +1010,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 		result = fetch_multiple(&list);
 	} else if (argc == 0) {
 		/* No arguments -- use default remote */
-		remote = remote_get(NULL);
+		remote = fetchremote_get(NULL, allow_local);
 		result = fetch_one(remote, argc, argv);
 	} else if (multiple) {
 		/* All arguments are assumed to be remotes or groups */
diff --git a/remote.c b/remote.c
index 68eb99b..a7e59ab 100644
--- a/remote.c
+++ b/remote.c
@@ -682,7 +682,7 @@ static int valid_remote_nick(const char *name)
 	return !strchr(name, '/'); /* no slash */
 }
 
-static struct remote *remote_get_1(const char *name, const char *pushremote_name)
+static struct remote *remote_get_1(const char *name, const char *pushremote_name, int allow_local)
 {
 	struct remote *ret;
 	int name_given = 0;
@@ -699,6 +699,11 @@ static struct remote *remote_get_1(const char *name, const char *pushremote_name
 		}
 	}
 
+	if (!allow_local && !strcmp(name, ".")) {
+		name = "origin";
+		name_given = 0;
+	}
+
 	ret = make_remote(name, 0);
 	if (valid_remote_nick(name)) {
 		if (!valid_remote(ret))
@@ -718,13 +723,19 @@ static struct remote *remote_get_1(const char *name, const char *pushremote_name
 struct remote *remote_get(const char *name)
 {
 	read_config();
-	return remote_get_1(name, NULL);
+	return remote_get_1(name, NULL, 1);
 }
 
 struct remote *pushremote_get(const char *name)
 {
 	read_config();
-	return remote_get_1(name, pushremote_name);
+	return remote_get_1(name, pushremote_name, 1);
+}
+
+struct remote *fetchremote_get(const char *name, int allow_local)
+{
+	read_config();
+	return remote_get_1(name, NULL, allow_local);
 }
 
 int remote_is_configured(const char *name)
diff --git a/remote.h b/remote.h
index cf56724..f0d6cf3 100644
--- a/remote.h
+++ b/remote.h
@@ -52,6 +52,7 @@ struct remote {
 
 struct remote *remote_get(const char *name);
 struct remote *pushremote_get(const char *name);
+struct remote *fetchremote_get(const char *name, int allow_local);
 int remote_is_configured(const char *name);
 
 typedef int each_remote_fn(struct remote *remote, void *priv);
-- 
1.8.3.rc1.579.g184e698

Re: [PATCH 1/3] fetch: add --allow-local option

[Ramkumar Ramachandra]

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.<name>.remote set to '.' in the first place, if you meant
origin?  'git fetch .' currently just updates FETCH_HEAD; while I'm
not sure how that is useful, I still don't understand _why_ you want
to change that behavior.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 3:25 AM, Ramkumar Ramachandra
<artagnon@gmail.com> 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.<name>.remote set to '.' in the first place, if you meant
> origin?  'git fetch .' currently just updates FETCH_HEAD; while I'm
> not sure how that is useful, I still don't understand _why_ you want
> to change that behavior.

% git checkout -t -b devel master

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Ramkumar Ramachandra]

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?)

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 4:27 AM, Ramkumar Ramachandra
<artagnon@gmail.com> 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 rebase on top of
'master', not 'origin/master' (or whatever the upstream of 'master'
is).

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Ramkumar Ramachandra]

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} (wouldn't you like
to be able to configure this?).  Seems a bit yuck overall; I wonder if
there's some other way to achieve what you want.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra
<artagnon@gmail.com> 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, but want to modify
> fetch to act on the hard-coded "origin", not @{u} (wouldn't you like
> to be able to configure this?).

No. What's the point of 'git fetch .'? What does 'git fetch' does when
there's no configured upstream branch? Why doesn't 'git fetch' default
to 'git fetch .' in those cases?

Answer: because 'git fetch .' doesn't make any sense. So if
'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.

> Seems a bit yuck overall; I wonder if
> there's some other way to achieve what you want.

Yeah, add 'branch.A.base' that would be used only by 'git rebase',
which I already suggested before, but I changed my mind.

Fixing 'git fetch' makes much more sense.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Ramkumar Ramachandra]

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 replacing it with the hard-coded "origin".  What happens when I
git branch -t -b devel hot-branch where branch.hot-branch.remote = ram
and not origin?

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra
<artagnon@gmail.com> 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
> against changing its behavior), but my question pertains to why you
> are replacing it with the hard-coded "origin".

'origin' is already hard-coded.

% git clone git://git.kernel.org/pub/scm/git/git.git

What would be the name of the remote? 'origin'.

% git checkout --no-track -b test
% git fetch

What is the remote that is used? 'origin'.

> What happens when I
> git branch -t -b devel hot-branch where branch.hot-branch.remote = ram
> and not origin?

The same thing that happens when you git branch --no-track -b devel hot-branch.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> 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 not want to say 'git fetch origin'" problem.

You do "git checkout -t -b mywork master" because you want to later
be able to conveniently rebase mywork on top of your local master
(i.e. make @{u} notation work for you) [*1*].

What "git checkout -t -b $branch $up" does is to declare that branch
builds on top of $up, which often is some remote tracking branch.
And "git pull [--rebase]" on that $branch is to

    (1) make sure $up is available and up to date; and

    (2) integrate with $up.  The first step is "git fetch" and it
        has to go to the repository $up comes from.

If $up is in your local repository (the original "fork mywork from
master in my repository"), the first step ought to be a no-op, and
"git fetch" from the current repository may seem wasteful, but I
think we already have an optimization to make this no-op not to
transfer anything network-wise.  There is no justification for it to
go to 'origin' or any other random remote that is different from the
reopsitory $up comes from.

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 you need to rebuild both your "master"
and "mywork" branches on top of.  If 'master' were forked from a
remote that is not 'origin', then making "git fetch" ignore '.' and
instead go to 'origin' would not solve anything.  For an updated
behaviour to be useful in that workflow, it needs to follow the
inter-branch relationship ("mywork is a fork of master which is a
fork of frotz branch from a remote xyzzy") to see the first remote
repository and fetch from there, instead of blindly fetching from
the 'origin'.

Having said all that, I am not all that sure that it is a good idea
to introduce such an exception for "git fetch" to ignore '.',
regardless of where it goes instead, either the 'origin' or the
first remote repository it finds by recursively finding its
upstreams, to break the consistency at the UI level.  It is dubious
if the benefit of convenience to fetch from remote 'xyzzy' that is
an eventual remote of 'mywork' without having to say so outweighs
the cost of additional UI inconsistency, making things harder to
explain to both new and old people.


[Footnote]

*1* Another side effect this has is that in a triangular workflow,
    the place you push to may not be the place the branch you
    integrate with (i.e. 'master') lives (i.e. '.', your local
    repository), and the name you want to push it as may not be the
    same as the branch you integrate with (i.e. 'master'), either.

    Ram's branch.mywork.pushremote can solve the former (i.e. where
    it goes), but not the latter (i.e. to which branch it is pushed),
    and that is a valid issue that may need to be addressed.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano <gitster@pobox.com> 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 you need to rebuild both your "master"
> and "mywork" branches on top of.  If 'master' were forked from a
> remote that is not 'origin', then making "git fetch" ignore '.' and
> instead go to 'origin' would not solve anything.  For an updated
> behaviour to be useful in that workflow, it needs to follow the
> inter-branch relationship ("mywork is a fork of master which is a
> fork of frotz branch from a remote xyzzy") to see the first remote
> repository and fetch from there, instead of blindly fetching from
> the 'origin'.

No, the reason I want 'git fetch' to fetch 'origin' is because it has
always done so. It only stopped doing so when I configured 'upstream'
branches. I'm not even sure I want 'git fetch' to fetch from the
remote of my current branch if it has an upstream branch.

> Having said all that, I am not all that sure that it is a good idea
> to introduce such an exception for "git fetch" to ignore '.',
> regardless of where it goes instead, either the 'origin' or the
> first remote repository it finds by recursively finding its
> upstreams, to break the consistency at the UI level.  It is dubious
> if the benefit of convenience to fetch from remote 'xyzzy' that is
> an eventual remote of 'mywork' without having to say so outweighs
> the cost of additional UI inconsistency, making things harder to
> explain to both new and old people.

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
% git fetch

# scratch head

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> 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
> % git fetch
>
> # scratch head

# reads manual, perhaps?

Why do you declare without justification that "git fetch ." does not
make sense?  If you come from "git pull" is "git fetch" + "git merge",
and if your current branch is integrating with your local branch, it
is natural that "git fetch" that does not say where to fetch from
fetches from your local repository (object-transfer wise, it is a
no-op) and update FETCH_HEAD.  You can say "it is not necessary, as
we can directly go to @{u}", but that is different from "it does not
make any sense".

I think the real cause of the problem is that some people advocate
the use of "git fetch" that does not say "from where" and "get
what".  When the user understand what it does and what it does it
for, not having to type is a convenience, but as a recipe to be
blindly followed, it leaves the new people in the dark.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 11:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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
>> % git fetch
>>
>> # scratch head
>
> # reads manual, perhaps?

You expect too much from users. But...

% man git push
/default

Nothing.

> Why do you declare without justification that "git fetch ." does not
> make sense?

What does 'git fetch .' do?

> 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.defaulttoupstream=true'.

> it
> is natural that "git fetch" that does not say where to fetch from
> fetches from your local repository (object-transfer wise, it is a
> no-op) and update FETCH_HEAD.  You can say "it is not necessary, as
> we can directly go to @{u}", but that is different from "it does not
> make any sense".

It literally does not make any sense. From the point of view of the
typical user it does nothing.

> I think the real cause of the problem is that some people advocate
> the use of "git fetch" that does not say "from where" and "get
> what".  When the user understand what it does and what it does it
> for, not having to type is a convenience, but as a recipe to be
> blindly followed, it leaves the new people in the dark.

That's totally irrelevant. Whether the user knows all the details or
not doesn't matter. Typing less is good, and it's important that
commands without arguments do something sane, and 'git fetch' doesn't.
The user should not be forced to type the remote when it's not
necessary, and wasting the 'git fetch' command to do absolutely
nothing is not smart.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> 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.defaulttoupstream=true'.

I am confused.  What does that have anything to do with this topic?
It only affects what a lazy "git merge" (without any other parameter
on the command line) does, doesn't it?

In the above "git fetch" + "git merge", I did not mean "git merge"
is literally what the command line of the command invoked
internally.  "git pull" of course chooses what is to be merged.

But that does not change the fact that before merging (or rebasing,
if you are running "git pull --rebase"), "git fetch" is done in
order to make sure the history you are merging with (or rebasing on
top of) is available locally and FETCH_HEAD is prepared so that "git
pull" can decide what to merge with (or rebase on).  

The merge.defaultToUpstream configuration does not change that, does
it?

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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.defaulttoupstream=true'.
>
> I am confused.  What does that have anything to do with this topic?
> It only affects what a lazy "git merge" (without any other parameter
> on the command line) does, doesn't it?

And that's what we are talking about here; commands without any other
parameter in the command like.

So "git pull $nothing" is *not* "git fetch $nothing" + "git merge $nothing".

> In the above "git fetch" + "git merge", I did not mean "git merge"
> is literally what the command line of the command invoked
> internally.  "git pull" of course chooses what is to be merged.
>
> But that does not change the fact that before merging (or rebasing,
> if you are running "git pull --rebase"), "git fetch" is done in
> order to make sure the history you are merging with (or rebasing on
> top of) is available locally and FETCH_HEAD is prepared so that "git
> pull" can decide what to merge with (or rebase on).

We are not talking about 'git pull .', we are talking about 'git fetch
.', and it doesn't make any sense.

> The merge.defaultToUpstream configuration does not change that, does
> it?

It changes the equation 'git pull' = 'git fetch' + 'git merge'.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> 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.defaulttoupstream=true'.
>>
>> I am confused.  What does that have anything to do with this topic?
>> It only affects what a lazy "git merge" (without any other parameter
>> on the command line) does, doesn't it?
>
> And that's what we are talking about here; commands without any other
> parameter in the command like.
>
> So "git pull $nothing" is *not* "git fetch $nothing" + "git merge $nothing".

Of course not.  But what does it change the equation?

Let's rephrase the above, then.

	"git pull" with 0 or more arguments is to first

        - make sure that necessary history is available in your
          repository

        - prepare FETCH_HEAD to record what is to be merged

        which is done by running "git fetch" with appropriate
        arguments against the repository of your upstream, and then
        to

        - merge the upstream history

        which is done by running "git merge" with appropriate
        arguments (which in turn is formulated by reading FETCH_HEAD
        that is left by the previous "git fetch" step).

So if your "upstream" happens to live in a local repository, it is
very natural to run "git fetch" against repository "." (with
appropriate arguments, like 'refs/heads/master' if you were on your
mywork branch that was forked from your 'master' branch).  Running
"git fetch ." is hardly "does not make any sense whatever" from that
point of view.  It is just a natural consequence that our local
repository is merely one of the repositories we could fetch/pull
from.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Thu, May 16, 2013 at 6:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> 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.defaulttoupstream=true'.
>>>
>>> I am confused.  What does that have anything to do with this topic?
>>> It only affects what a lazy "git merge" (without any other parameter
>>> on the command line) does, doesn't it?
>>
>> And that's what we are talking about here; commands without any other
>> parameter in the command like.
>>
>> So "git pull $nothing" is *not* "git fetch $nothing" + "git merge $nothing".
>
> Of course not.  But what does it change the equation?
>
> Let's rephrase the above, then.
>
>         "git pull" with 0 or more arguments is to first
>
>         - make sure that necessary history is available in your
>           repository
>
>         - prepare FETCH_HEAD to record what is to be merged
>
>         which is done by running "git fetch" with appropriate
>         arguments against the repository of your upstream, and then
>         to
>
>         - merge the upstream history
>
>         which is done by running "git merge" with appropriate
>         arguments (which in turn is formulated by reading FETCH_HEAD
>         that is left by the previous "git fetch" step).
>
> So if your "upstream" happens to live in a local repository, it is
> very natural to run "git fetch" against repository "." (with
> appropriate arguments, like 'refs/heads/master' if you were on your
> mywork branch that was forked from your 'master' branch).  Running
> "git fetch ." is hardly "does not make any sense whatever" from that
> point of view.  It is just a natural consequence that our local
> repository is merely one of the repositories we could fetch/pull
> from.

This is irrelevant, it's an implementation detail of 'git pull'. *THE
USER* is not running 'git fetch .' (s)he is running 'git push .'. ONCE
AGAIN; I'm not talking about 'git pull .' I am talking about 'git
fetch .' (a *USER*-run 'git fetch .'), and a *USER*-run 'git fetch .'
does *not* make any sense whatsoever.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> 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_HEAD

and then they can "git merge FETCH_HEAD" to conclude it, or run a
"git pull" for real.  We teach the more explicit form to end users
in our tutorial, but it shows the explicit form only because we want
to illustrate what goes on. Over time we added support to "git fetch"
(and "git pull") to make it possible for users to type less when the
remote and branch involved are obvious, but we carefully avoided
breaking this expectation.

So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as

	[branch "mywork"]
        	remote = .
                merge = refs/heads/master

we still need to have FETCH_HEAD updated to point at what we would
be merging if she did a "git pull".  It may be OK to additionally
fetch objects from 'origin' and update the remote tracking branches
associated with 'origin', but anything from 'origin' should not
contaminate what results in FETCH_HEAD---it should record whatever
we record when we did fetch refs/heads/master from '.'.

As I said in the very beginning, it was a mistake for me to suggest
adding a special case behaviour for '.' remote in the first place.
It breaks a long-standing expectation and workflow built around it.

So sorry for wasting our time, and consider this as a misguided
excursion.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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_HEAD
>
> and then they can "git merge FETCH_HEAD" to conclude it, or run a
> "git pull" for real.  We teach the more explicit form to end users
> in our tutorial,

That "tutorial" is mostly irrelevant; it has not been properly updated
in years, and it doesn't do it's job properly.

Nowadays most people use the Pro Git book, which doesn't mention
FETCH_HEAD even once. And why would it? It's not a useful concept for
typical users.

> So when "the user" is running "git fetch" on "mywork" branch that
> happens to be forked from a local "master", i.e. her configuration
> is set as
>
>         [branch "mywork"]
>                 remote = .
>                 merge = refs/heads/master
>
> we still need to have FETCH_HEAD updated to point at what we would
> be merging if she did a "git pull".

No, we don't need that. That is only needed by 'git pull', and in
fact, it should be possible to reimplement 'git pull' so that it skips
FETCH_HEAD when the remote is local.

These are mere implementation details.

> As I said in the very beginning, it was a mistake for me to suggest
> adding a special case behaviour for '.' remote in the first place.
> It breaks a long-standing expectation and workflow built around it.

The fact that it's "long-standing" doesn't mean it's sane.

> So sorry for wasting our time, and consider this as a misguided
> excursion.

It doesn't matter, the problem that 'git fetch' does something totally
and completely uses is still there.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> 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_HEAD
>>
>> and then they can "git merge FETCH_HEAD" to conclude it, or run a
>> "git pull" for real.  We teach the more explicit form to end users
>> in our tutorial,
>
> That "tutorial" is mostly irrelevant; it has not been properly updated
> in years, and it doesn't do it's job properly.
>
> Nowadays most people use the Pro Git book, which doesn't mention
> FETCH_HEAD even once. And why would it?

Because the book was written by those who did not know about its
use, and I do not necessarily think it is their fault.  Our own
documentation can use updates.

Patches to the tutorial to explain (you can refer to postings by
people who discuss on public "users help other users" site like
stackoverflow) the equivalence of the "git pull" == "git fetch"
followed by "git merge FETCH_HEAD" better than it currently does is
welcome.  IIUC, ProGit is maintained in public and you can send
patches to it, too.

Users of stackoverflow seem to know about and how to use FETCH_HEAD:

    http://stackoverflow.com/questions/9237348/what-does-fetch-head-in-git-mean
    http://stackoverflow.com/questions/11478558/fetch-head-not-updating-after-git-fetch

and they expect exactly what I described in the earlier message.  If
you ask your search engine about "FETCH_HEAD", you would find other
real-world use of it as well (one of them I found was about somebody
requesting to teach TortoiseGit to offer FETCH_HEAD as a candate to
be merged, IIRC).

Incidentally, this discussion on our own list

    http://thread.gmane.org/gmane.comp.version-control.git/42788/focus=42798

shows that I was originally not very keen to defend "fetch, then
inspect with log FETCH_HEAD, and then finally merge" workflow to
keep working myself [*1*], which is somewhat funny.

So, no, it is not my whim, but people do depend on "git fetch" that
updates FETCH_HEAD to what is to be merged with "git pull".

>> So when "the user" is running "git fetch" on "mywork" branch that
>> happens to be forked from a local "master",...
>> we still need to have FETCH_HEAD updated to point at what we would
>> be merging if she did a "git pull".
>
> No, we don't need that. That is only needed by 'git pull', and in
> fact, it should be possible to reimplement 'git pull' so that it skips
> FETCH_HEAD when the remote is local.
>
> These are mere implementation details.

You seem to be incapable to understand what backward compatibility
is.  It is not about "keep only what I use myself, I think others
should use, and/or I understand, working, and destroy everything
else".

Also your "special-case local repository and fetch from 'origin'"
breaks down once your users need to work on a project with subsystem
maintainers.

Imagine one clones from me (i.e. git.git is her upstream), and forks
her fh-octopus branch out of her master branch ("git clone" arranges
the latter to be a fork of origin/master taken from me).  She helps
git-svn and has Eric's repository as her "git-svn" remote (because
my tree lags behind Eric's tree with respect to git-svn).  Her local
git-svn branch is a fork of Eric's master, and she has her svn-ext
branch that is a fork of it [*2*].

    git clone git://git.kernel.org/pub/scm/git/git.git git
    cd git

    git checkout -t -b fh-octopus master
    git remote add git-svn git://git.bogomips.org/git-svn.git/
    git checkout -t -b git-svn git-svn/master
    git checkout -t -b svn-ext git-svn

She has four local branches, master, fh-octopus, git-svn, and
svn-ext.  Is this a too-contrived example?  I do not think so.

On any of these branches, she can say

    git pull [--rebase]

without having to be constantly aware of what branch (either remote
or local) the work on her current branch builds on.  Like some
people in the thread $gmane/42788 discussion, she may prefer to do
the same integration with "first fetch, inspect and then integrate"
workflow, relying on the equivalence "git pull" == "git fetch" +
"git merge/rebase":

    git fetch
    git log ..FETCH_HEAD
    git merge FETCH_HEAD

But when she does this:

    git checkout fh-octopus
    git fetch

the "git fetch" does not fetch from me (i.e. her 'origin').

Would she be unhappy?

I agree that it could be argued so.

After all, she is working on a topic that is eventually based on my
'master' and the only reason she forked from her 'master' is because
she may have other changes of her own on her 'master' that are not
necessarily related to her fh-octopus topic.  She wants her "git log
@{u}.."  not to show those unrelated changes on her 'master', but
wants to rebase against her 'master'.

Because her @{u} does not refer to 'origin/master' taken from me (it
refers to her local 'master'), however, even if we change "git
fetch" to fetch from 'origin', what "git log ..@{u}" shows does not
change, so the only "improvement" is that it does not trigger "I
said 'git fetch' but it did not fetch anything?  Did I make some
mistake?" confusion.

Is that lack of confusion a big enough improvement, or is it easy
enough for her to realize that what she wanted to inspect was what
I've been doing in the meantime and run "git fetch origin"?

I know you would say it is an improvement; I am on the fence in the
sense that no confusion is better than confusion, but that is a
qualified "on the fence".  I do not mind it fixed as long as the
confusion avoidance does not regress other aspects of the operation
we have kept working for people.

But more importantly, what should happen when she is working on her
svn-ext branch?

    git checkout svn-ext
    git fetch

This does not fetch from me (i.e. her 'origin'), either.  If this
fetched from me, would she be happier?

It could be argued that it might be better if it fetched from Eric;
after all she is working on svn-ext that eventually reaches Eric's
tree.  But fetching from me while she is working on svn-ext does not
make any sense at all in her set-up, does it?

As I already said, I am OK with an enhancement that does (an
equivalent of) the following:

 - Teach "git fetch --no-fetch-head <any args>" an option that
   causes it to do everything "git fetch <any args>" would do,
   except that in that mode, it does not touch FETCH_HEAD at all
   (the "--append" option that changes the behaviour of "git fetch"
   to only change what happens to FETCH_HEAD can be thought of a
   precedent).

 - Only when 'git fetch' (with no parameters, i.e. relies on
   configured defaults) is to fetch from '.':

   - First internally fork and run "git fetch --no-fetch-head
     <remote>" from the <remote> found by the following loop:

    - Set a variable B to the name of the current branch 
    - while branch.B.remote is the local repository:
      - assign the branch the branch B forked from,
        i.e. branch.B.merge, to variable B
    - branch.B.remote is the first remote repository in the fork
      ancestry chain.  That is the <remote> we are looking for.

   - Then do the usual 'git fetch' against the local repository,
     leaving what is to be merged in FETCH_HEAD as usual.

 - (optional) make the second "special case" opt-in, as people who
   have known Git may be upset when their "git pull" that they know
   would go to local repository touches network.  I do not think it
   is a huge deal, though, and that is why I marked it as optional.

I think that would alleviate the puzzlement some people may feel
when they run 'git fetch' on a branch that integrates with their
local branch, and sees no objects are transferred.  It would do so
without breaking anything.

Anything that breaks the "pull=fetch+merge" equivalence is not
acceptable and no loud repeating from you will change that, with or
without patches.

We owe at least that much to the people who asked us to keep it
working over time and those who responded to them by working on
maintaining it over time.


[Footnotes]

*1* Back then, FETCH_HEAD did not have the commit to be merged
    necessarily on the first line, so it was not very easy to work
    with it.  But that was fixed by 96890f4c428e (write first
    for-merge ref to FETCH_HEAD first, 2011-12-26), has been with us
    since v1.7.9, and the fix was not made by me, but Joey Hess.


*2* The invariant "git pull <fetch params>" == "git fetch <the same
    fetch params>" + "git merge FETCH_HEAD" (for any <fetch params>,
    including empty) has been true forever, and over time we made
    sure it hold true when we introduced new features because people
    depended on it, with commmits like these:

     - 85295a52e683 (git-merge: Put FETCH_HEAD data in merge commit
       message, 2007-03-22)

     - 96890f4c428e (write first for-merge ref to FETCH_HEAD first,
       2011-12-26)

    A remaining known bug is when the pull is to create an octopus,
    because "git merge FETCH_HEAD" currently can resolve FETCH_HEAD
    as only one commit.  The fh-octopus topic would extend the itch
    these two fixes started to scratch by teaching "git merge" to
    expand FETCH_HEAD into all commits that are not marked as
    not-for-merge to finish scratching that itch.

    svn-ext may teach git-svn to express a svn external as a git
    submodule.

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> 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_HEAD
> >>
> >> and then they can "git merge FETCH_HEAD" to conclude it, or run a
> >> "git pull" for real.  We teach the more explicit form to end users
> >> in our tutorial,
> >
> > That "tutorial" is mostly irrelevant; it has not been properly updated
> > in years, and it doesn't do it's job properly.
> >
> > Nowadays most people use the Pro Git book, which doesn't mention
> > FETCH_HEAD even once. And why would it?
> 
> Because the book was written by those who did not know about its
> use, and I do not necessarily think it is their fault.

That's an _assumption_, and I don't think it's correct; the authors might very
well know about FETCH_HEAD, but made a conscious decision to avoid explaining
such low-level concepts to people trying to learn Git; they are irrelevant to
them. I'm sure they skipped pack formats, remote-helper interfaces, and a lot
of other implementation details users don't need to know about.

FETCH_HEAD is simply another implementation detail users don't need to
know, so it doesn't belong in Pro Git, a book designed for people trying
to learn Git.

> Our own documentation can use updates.

Yeah, sure. I've tried to fix the tutorial, it's not an experience I would
wish to anybody, especially not people unfamiliar with Git, who are the
people better suited to understand what is confusing about Git.

IOW, the documentation is destined to oblivion, because the only people
that could point out the inconsistencies and irrelevancies, are
precisely the people that don't contribute to Git. And the people who do
contribute to Git, and have enough empathy to put themselves in the
shoes of users, are shun for 'rocking the boat'.

Yes, the documentation *can* use updates, but won't.

> IIUC, ProGit is maintained in public and you can send patches to it,
> too.

Yes, and I will send patches, but about issues that *matter*. Why would
I send a patch to add text about a feature *nobody* needs to know?

> Users of stackoverflow seem to know about and how to use FETCH_HEAD:
> 
>     http://stackoverflow.com/questions/9237348/what-does-fetch-head-in-git-mean
>     http://stackoverflow.com/questions/11478558/fetch-head-not-updating-after-git-fetch

This is a cheeky use of rhetoric, it implies that *all* users of
stackoverflow know about this, and it's not true.

Counting the amount of votes, the best we can say is at most 20 people
'know' about this. A more specific description of the situation would be
that at most 20 people _knew_ about this, at the time they read it; they
might have forgotten already. But more importantly, only 14 people voted
for this question, and only 7 people starred it.

The top question 'How do I edit an incorrect commit message in Git?'
about Git has 2871 votes and 822 stars, which is more than 200 times.
Can we say that stackoverflows "know" how to amend a commit? Well, if
they knew why it continues to receive votes?

So if one question has 2871 votes, and the other one has 14 votes, does
it mean they 'know' one question, and not the other one? At which point
do the users stop 'knowing' the answer to the question? If a question is
posted, does it mean that automatically stackoverflow users 'know' about
it?

No, we don't known what stackoverflow users seem to "know", we can only
know what *some* of them consider a good question, and a good answer.
That's all.

> and they expect exactly what I described in the earlier message.

Wrong. From those links only one person expected this to happen, and he
received zero votes, which can be translated to; nobody cares.

> If you ask your search engine about "FETCH_HEAD", you would find other
> real-world use of it as well (one of them I found was about somebody
> requesting to teach TortoiseGit to offer FETCH_HEAD as a candate to be
> merged, IIRC).

I'm sure there are people out there that would find uses for FETCH_HEAD,
you can probably count them with the fingers in your hand, even if half
of them were missing.

This patch would do *nothing* to harm those suers, because they can
still do 'git fetch .', or even 'git fetch --allow-local'. The two
persons in the world that do expect 'git fetch' without arguments to
update FETCH_HEAD, will have to specify another single character
argument. Big whooping do.

The rest of the results in Google show basically only bugs, and patches.

Even if all those results were about interesting things people do with
FETCH_HEAD, that has absolutely nothing to do with the issue at hand,
which is 'git fetch' without arguments.

This is just a red herring.

> Incidentally, this discussion on our own list
> 
>     http://thread.gmane.org/gmane.comp.version-control.git/42788/focus=42798

This explicitly says 'git fetch <URL>', it has nothing to do with 'git
fetch' without arguments.

Moreover, it explicitly says:

> I often like to fetch some code from others, review and then merge.

'git fetch .' does not help one iota to this use-case.

> shows that I was originally not very keen to defend "fetch, then
> inspect with log FETCH_HEAD, and then finally merge" workflow to
> keep working myself [*1*], which is somewhat funny.
> 
> So, no, it is not my whim, but people do depend on "git fetch" that
> updates FETCH_HEAD to what is to be merged with "git pull".

They depend on that when they merge a *REMOTE*; a remote remote, not a
local remote ('.').

There's *absolutely* no reason why anybody would ever rely on 'git fetch
.' followed by 'git merge FETCH_HEAD'.

> >> So when "the user" is running "git fetch" on "mywork" branch that
> >> happens to be forked from a local "master",...
> >> we still need to have FETCH_HEAD updated to point at what we would
> >> be merging if she did a "git pull".
> >
> > No, we don't need that. That is only needed by 'git pull', and in
> > fact, it should be possible to reimplement 'git pull' so that it skips
> > FETCH_HEAD when the remote is local.
> >
> > These are mere implementation details.
> 
> You seem to be incapable to understand what backward compatibility
> is.

I'll explain why that is wrong in so many levels in a separate mail.

> It is not about "keep only what I use myself, I think others
> should use, and/or I understand, working, and destroy everything
> else".

This is just bullshit. Nobody is destroying anything. The users can just
do 'git fetch .' and be done with it, but of course they won't, because
that doesn't do anything useful.

> Also your "special-case local repository and fetch from 'origin'"
> breaks down once your users need to work on a project with subsystem
> maintainers.

If 'git fetch' -> 'git fetch origin' is broken, then we are already
broken, because that's what happens by default.

> Imagine one clones from me (i.e. git.git is her upstream), and forks
> her fh-octopus branch out of her master branch ("git clone" arranges
> the latter to be a fork of origin/master taken from me).  She helps
> git-svn and has Eric's repository as her "git-svn" remote (because
> my tree lags behind Eric's tree with respect to git-svn).  Her local
> git-svn branch is a fork of Eric's master, and she has her svn-ext
> branch that is a fork of it [*2*].
> 
>     git clone git://git.kernel.org/pub/scm/git/git.git git
>     cd git
> 
>     git checkout -t -b fh-octopus master
>     git remote add git-svn git://git.bogomips.org/git-svn.git/
>     git checkout -t -b git-svn git-svn/master
>     git checkout -t -b svn-ext git-svn
> 
> She has four local branches, master, fh-octopus, git-svn, and
> svn-ext.  Is this a too-contrived example?  I do not think so.
> 
> On any of these branches, she can say
> 
>     git pull [--rebase]
> 
> without having to be constantly aware of what branch (either remote
> or local) the work on her current branch builds on.  Like some
> people in the thread $gmane/42788 discussion, she may prefer to do
> the same integration with "first fetch, inspect and then integrate"
> workflow, relying on the equivalence "git pull" == "git fetch" +
> "git merge/rebase":
> 
>     git fetch
>     git log ..FETCH_HEAD
>     git merge FETCH_HEAD
> 
> But when she does this:
> 
>     git checkout fh-octopus
>     git fetch
> 
> the "git fetch" does not fetch from me (i.e. her 'origin').
> 
> Would she be unhappy?
> 
> I agree that it could be argued so.
> 
> After all, she is working on a topic that is eventually based on my
> 'master' and the only reason she forked from her 'master' is because
> she may have other changes of her own on her 'master' that are not
> necessarily related to her fh-octopus topic.  She wants her "git log
> @{u}.."  not to show those unrelated changes on her 'master', but
> wants to rebase against her 'master'.
> 
> Because her @{u} does not refer to 'origin/master' taken from me (it
> refers to her local 'master'), however, even if we change "git
> fetch" to fetch from 'origin', what "git log ..@{u}" shows does not
> change, so the only "improvement" is that it does not trigger "I
> said 'git fetch' but it did not fetch anything?  Did I make some
> mistake?" confusion.

That's correct, but the issue is there no matter what, the only question
is which of the two options we want:

a)

	% git checkout svn-ext
	% git fetch
	From .
	 * branch            master     -> FETCH_HEAD
	# oops
	% git fetch git-svn
	% git log ..FETCH_HEAD
	% git merge FETCH_HEAD

b)

	% git checkout svn-ext
	% git fetch
	From git://git.kernel.org/pub/scm/git/git
	   680ed3e..de3a5c6  master     -> origin/master
	# oops
	% git fetch svn-ext
	% git log ..FETCH_HEAD
	% git merge FETCH_HEAD

For me a) is totally confusing, maybe this particular user is familiar
with FETCH_HEAD, but for the vast majority of other users it's totally
confusing. b) is also wrong, but at least it's doing something useful
and familiar; fetching from a remote remote.

Why do you ignore b)? Why do you automatically assume a) is best?

You are jumping to conclusions here.

> As I already said, I am OK with an enhancement that does (an
> equivalent of) the following:
> 
>  - Teach "git fetch --no-fetch-head <any args>" an option that
>    causes it to do everything "git fetch <any args>" would do,
>    except that in that mode, it does not touch FETCH_HEAD at all
>    (the "--append" option that changes the behaviour of "git fetch"
>    to only change what happens to FETCH_HEAD can be thought of a
>    precedent).
> 
>  - Only when 'git fetch' (with no parameters, i.e. relies on
>    configured defaults) is to fetch from '.':
> 
>    - First internally fork and run "git fetch --no-fetch-head
>      <remote>" from the <remote> found by the following loop:
> 
>     - Set a variable B to the name of the current branch 
>     - while branch.B.remote is the local repository:
>       - assign the branch the branch B forked from,
>         i.e. branch.B.merge, to variable B
>     - branch.B.remote is the first remote repository in the fork
>       ancestry chain.  That is the <remote> we are looking for.

Why do we need to fork? All we need is go through the 'branch.X.*'
configurations until we find a non-local remote.

>    - Then do the usual 'git fetch' against the local repository,
>      leaving what is to be merged in FETCH_HEAD as usual.
> 
>  - (optional) make the second "special case" opt-in, as people who
>    have known Git may be upset when their "git pull" that they know
>    would go to local repository touches network.  I do not think it
>    is a huge deal, though, and that is why I marked it as optional.
> 
> I think that would alleviate the puzzlement some people may feel
> when they run 'git fetch' on a branch that integrates with their
> local branch, and sees no objects are transferred.  It would do so
> without breaking anything.
> 
> Anything that breaks the "pull=fetch+merge" equivalence is not
> acceptable and no loud repeating from you will change that, with or
> without patches.

You are jumping ahead; you go from "Jane uses FETCH_HEAD", to "Jane
expects 'git fetch' to do 'git fetch .'", which is demonstrably false.

You merely explained why some user might want to use FETCH_HEAD in some
situations, which is totally orthogonal to the issue at hand.

The issue at hand is that 'git fetch' -> 'git fetch .' is useless.

You are using verbose rhetoric to deflect the issue at hand, and go to
great lengths to explain something that is totally irrelevant, and at no
point in time do you touch the issue of a) vs. b).

> We owe at least that much to the people who asked us to keep it
> working over time and those who responded to them by working on
> maintaining it over time.

Geezus! This patch doesn't break anything for them. Period.

Show me *one* real use-case this patch breaks. Go on.

-- 
Felipe Contreras

About overzealous compatibility

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:

> >> So when "the user" is running "git fetch" on "mywork" branch that
> >> happens to be forked from a local "master",...
> >> we still need to have FETCH_HEAD updated to point at what we would
> >> be merging if she did a "git pull".
> >
> > No, we don't need that. That is only needed by 'git pull', and in
> > fact, it should be possible to reimplement 'git pull' so that it skips
> > FETCH_HEAD when the remote is local.
> >
> > These are mere implementation details.
> 
> You seem to be incapable to understand what backward compatibility
> is.

Really? Do you even remember the time when you changed out of nowhere
all the 'git-foo' commands with 'git foo' and all hell broke loose?

I remember some lonely voice of reason shouting for clear deprecation
warnings:

http://article.gmane.org/gmane.comp.version-control.git/94262

You seem to not understand what is the purpose of backwards
compatibility, so let me explain. The most important aspect of a project
is not the technical details, or the performance, but it's *usefulness*
to the users; once a user has decided to use the software, he expects it
to keep working for his use-cases in the foreseeable future. If something
changes, and the user was relying on that, the user would get annoyed,
but most likely would not stop using the software. If this happens time
and again, he might.

In order to keep as many users as possible, and ensure the project keeps
growing with as strong user and developer base, the old behaviors should
remain in place as much as possible. This keeps old users happy, and
allows the project to achieve it's goal; to be useful to many people as
possible.

The safest way to never break old behaviors is to never make any change,
but this is not ideal, no software is perfect, and the software needs to
be constantly evolving, otherwise users will stop using the software as
well.

Moving forward while not breaking old behaviors is often times
difficult, but necessary, to keep the old users, and the steady growth.

Many projects make the mistake of simply disregarding old users, and
breaking things constantly; and while doing so, they keep loosing users,
and never grow as much as they could. *Nobody* is suggesting Git should
do that.

It's inevitable that there would come a point in time where there would
be a conflict of interests, and in order to move forward it's necessary
to break old behaviors. When such situation arises, it's important to
exhaust any other options that might allow both the old and new
behaviors (like a configuration option), or different implementations. But
it might be, that there are no alternatives, and either the project
doesn't move forward, or compatibility is retained.

When analyzing such cases, it's important to understand the impact it
has, and how many users it affects; if it's a small change to the user
work-flow, but it affects too many users, it might be best to don't go
forward with the change, or only do so after a major version release,
with good communication to minimize the damage. And if it's a big
change, but it affects a small user base, it still might make sense to
go ahead with the change.

Many times it won't be possible to know how many users would be affects,
and in those cases it might make sense to release, with a hand in the
breaks, so, if a lot of users complain, the change is reverted, and
nobody, or very few, complain, leave it there. The Linux project does
this; revert when somebody shouts.

In conclusion; you shouldn't blindly dogmatically avoid changes for the
sake of it; you have to understand *why* you _try_ to retain backwards
compatibility, and when it best serves the project not to do so.

If you try to be too overzealous in your backwards compatibility, you
run the risk of not moving fast enough in order to not annoy a handful
of users, or even imaginary ones who don't even exist. This is not good
for the project.

A few days ago somebody used a very appropriate name for it:
compabeaten[1]. We want to keep our users happy, but we also want to
keep our developers happy, and not being able to move forward with as
many features as one would want to is very annoying.

In the worst case scenario, we can revert a change that many users are
complaining about, we are not GNOME.

[1] http://article.gmane.org/gmane.comp.version-control.git/224510

-- 
Felipe Contreras

Re: About overzealous compatibility

[Felipe Contreras]

On Sun, May 19, 2013 at 2:56 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> >> So when "the user" is running "git fetch" on "mywork" branch that
>> >> happens to be forked from a local "master",...
>> >> we still need to have FETCH_HEAD updated to point at what we would
>> >> be merging if she did a "git pull".
>> >
>> > No, we don't need that. That is only needed by 'git pull', and in
>> > fact, it should be possible to reimplement 'git pull' so that it skips
>> > FETCH_HEAD when the remote is local.
>> >
>> > These are mere implementation details.
>>
>> You seem to be incapable to understand what backward compatibility
>> is.
>
> Really? Do you even remember the time when you changed out of nowhere
> all the 'git-foo' commands with 'git foo' and all hell broke loose?
>
> I remember some lonely voice of reason shouting for clear deprecation
> warnings:
>
> http://article.gmane.org/gmane.comp.version-control.git/94262

After re-reading this old thread, I noticed that you didn't get a
straight answer, nor was there a neat conclusion, and the good replies
might have been lost in the noise. So this is what you should have
done:

1) Fix all the tests and documentation to use the 'git foo' form, so
everything is consistent and the proper form of the commands is
explained.
2) Release v1.6.0 turning on annoying deprecation warnings telling
people to stop using 'git-foo'. This wouldn't have had the same bad
effect that v1.6.0 had, because you added at the same time a
configuration to turn the annoying message off, so users, and
administrators can choose to ignore the warning, and then they
couldn't complain when the 'git-foo' links get removed for real.
3) To be absolutely sure that people get the message that there's a
big change, name the release v2.0.

I think 3) would have been overkill; v1.7.0 would be OK, but 2) was
definitely needed, and 1) would have been great.

I think it's extremely cheap that you accuse me of not understanding
backwards compatibility, when I did for zsh's completion[1] exactly
what you should have done for v1.6.0: add an annoying deprecation
warning.

Cheers.

[1] http://article.gmane.org/gmane.comp.version-control.git/210024

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
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", i.e. her configuration
> is set as
>
> [branch "mywork"]
>        remote = .
>                merge = refs/heads/master
>

Was the '.' example illustrative rather than exact. I see no case of 
using '.' in my configs. Or am I completely missing the point? (e.g. 
that the use of '.' an example of possible future usage)?


> we still need to have FETCH_HEAD updated to point at what we would
> be merging if she did a "git pull".  It may be OK to additionally
> fetch objects from 'origin' and update the remote tracking branches
> associated with 'origin', but anything from 'origin' should not
> contaminate what results in FETCH_HEAD---it should record whatever
> we record when we did fetch refs/heads/master from '.'.
>
> As I said in the very beginning, it was a mistake for me to suggest
> adding a special case behaviour for '.' remote in the first place.
> It breaks a long-standing expectation and workflow built around it.
>
> So sorry for wasting our time, and consider this as a misguided
> excursion.
> --

Philip 

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Sat, May 18, 2013 at 8:12 AM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Junio C Hamano" <gitster@pobox.com>
> 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", i.e. her configuration
>> is set as
>>
>> [branch "mywork"]
>>        remote = .
>>                merge = refs/heads/master
>>
>
> Was the '.' example illustrative rather than exact. I see no case of using
> '.' in my configs. Or am I completely missing the point? (e.g. that the use
> of '.' an example of possible future usage)?

% git checkout -t -b feature master
# work
% git rebase -i

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Philip Oakley]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Saturday, May 18, 2013 3:23 PM
> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley <philipoakley@iee.org>
> wrote:
>> From: "Junio C Hamano" <gitster@pobox.com>
>> 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", i.e. her configuration
>>> is set as
>>>
>>> [branch "mywork"]
>>>        remote = .
>>>                merge = refs/heads/master
>>>
>>
>> Was the '.' example illustrative rather than exact. I see no case of
>> using
>> '.' in my configs. Or am I completely missing the point? (e.g. that
>> the use
>> of '.' an example of possible future usage)?
>
> % git checkout -t -b feature master
> # work
> % git rebase -i
>
> -- 
> Felipe Contreras
> --

OK, I see it (the dot '.' in the config file) now.

I've also located the documentation hidden at the end of git-config(1)
under branch.<name>.merge, even though your worked example has it
under remote not merge.
    [branch "feature"]
     remote = .
     merge = refs/heads/master

"If you wish to setup git pull so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting .
(a period) for branch.<name>.remote."

It feels as if this dwimmery(?) should also be listed in the gitcli(7)
documenation and under branch.<name>.remote in git-config(1) above it.

The use of dot '.' occured in a reply a couple of weeks ago:

Sent: Saturday, May 04, 2013 7:51 PM
Subject: Re: Pitfalls in auto-fast-forwarding heads that are not checked 
out?
"Jonathan Nieder" <jrnieder@gmail.com> wrote:
> Another trick is to use "git push":
>         git push . $production_sha1:refs/heads/master


Philip

Re: [PATCH 1/3] fetch: add --allow-local option

[Felipe Contreras]

On Sat, May 18, 2013 at 3:53 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Felipe Contreras" <felipe.contreras@gmail.com>
> Sent: Saturday, May 18, 2013 3:23 PM
>>
>> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley <philipoakley@iee.org>
>> wrote:
>>>
>>> From: "Junio C Hamano" <gitster@pobox.com>
>>> 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", i.e. her configuration
>>>> is set as
>>>>
>>>> [branch "mywork"]
>>>>        remote = .
>>>>                merge = refs/heads/master
>>>>
>>>
>>> Was the '.' example illustrative rather than exact. I see no case of
>>> using
>>> '.' in my configs. Or am I completely missing the point? (e.g. that
>>> the use
>>> of '.' an example of possible future usage)?
>>
>>
>> % git checkout -t -b feature master
>> # work
>> % git rebase -i
>>
>> --
>> Felipe Contreras
>> --
>
>
> OK, I see it (the dot '.' in the config file) now.
>
> I've also located the documentation hidden at the end of git-config(1)
> under branch.<name>.merge, even though your worked example has it
> under remote not merge.
>    [branch "feature"]
>
>     remote = .
>     merge = refs/heads/master
>
> "If you wish to setup git pull so that it merges into <name> from
> another branch in the local repository, you can point
> branch.<name>.merge to the desired branch, and use the special setting .
> (a period) for branch.<name>.remote."

This is called the upstream branch. Go to any branch, and do this:

% git checkout feature
% git branch --set-upstream-to master

And it would set:

  remote = .
  merge = refs/heads/master

Now you can do things like:

% git log feature@{upstream}..feature

Which gets translated to:

% git log master..feature

And:

% git rebase -i

Which gets translated to:

% git rebase -i master

This is nothing new.

-- 
Felipe Contreras

Re: [PATCH 1/3] fetch: add --allow-local option

[Junio C Hamano]

"Philip Oakley" <philipoakley@iee.org> writes:

> From: "Junio C Hamano" <gitster@pobox.com>
> 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", i.e. her configuration
>> is set as
>>
>> [branch "mywork"]
>>        remote = .
>>                merge = refs/heads/master
>>
>
> Was the '.' example illustrative rather than exact. 

It is exactly spelled like so.  Just like '.' in the filesystem
refers to our current directory, a dot-repository used there refers
to our local repository.  "Git is distributed and no repository is
special" principle extends to our own local repository in that you
can use it just like you can use anybody else's repository as the
source of fetch or the destination of push.

[PATCH 2/3] fetch: switch allow-local off by default

[Felipe Contreras]

And force it on in 'git push' to retain the old behavior.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/fetch.c        |  2 +-
 git-pull.sh            |  2 +-
 t/t5513-fetch-track.sh | 14 ++++++++++++++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 2efbd7b..c65c75b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -39,7 +39,7 @@ static struct strbuf default_rla = STRBUF_INIT;
 static struct transport *transport;
 static const char *submodule_prefix = "";
 static const char *recurse_submodules_default;
-static int allow_local = 1;
+static int allow_local = 0;
 
 static int option_parse_recurse_submodules(const struct option *opt,
 				   const char *arg, int unset)
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..18c3793 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -220,7 +220,7 @@ test true = "$rebase" && {
 	done
 }
 orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
+git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok --allow-local "$@" || exit 1
 test -z "$dry_run" || exit 0
 
 curr_head=$(git rev-parse -q --verify HEAD)
diff --git a/t/t5513-fetch-track.sh b/t/t5513-fetch-track.sh
index 65d1e05..cb46747 100755
--- a/t/t5513-fetch-track.sh
+++ b/t/t5513-fetch-track.sh
@@ -27,4 +27,18 @@ test_expect_success fetch '
 	)
 '
 
+test_expect_success 'fetch no-local' '
+	(
+		test_create_repo another &&
+		cd another &&
+		git remote add origin .. &&
+		echo test > file &&
+		git add . &&
+		git commit -m test &&
+		git checkout -t -b local-tracking master &&
+		git fetch &&
+		git rev-parse --verify refs/remotes/origin/b/one
+	)
+'
+
 test_done
-- 
1.8.3.rc1.579.g184e698

[PATCH 3/3] remote: disable allow-local for pushes

[Felipe Contreras]

So that 'git push' uses 'origin', instead of '.' by default.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 remote.c                | 2 +-
 t/t5528-push-default.sh | 7 +++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/remote.c b/remote.c
index a7e59ab..c1458dc 100644
--- a/remote.c
+++ b/remote.c
@@ -729,7 +729,7 @@ struct remote *remote_get(const char *name)
 struct remote *pushremote_get(const char *name)
 {
 	read_config();
-	return remote_get_1(name, pushremote_name, 1);
+	return remote_get_1(name, pushremote_name, 0);
 }
 
 struct remote *fetchremote_get(const char *name, int allow_local)
diff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh
index 4736da8..61df2a7 100755
--- a/t/t5528-push-default.sh
+++ b/t/t5528-push-default.sh
@@ -115,4 +115,11 @@ test_expect_success 'push to existing branch, upstream configured with different
 	test_cmp expect-other-name actual-other-name
 '
 
+test_expect_success 'push to existing branch, upstream configured with same name' '
+	git remote add origin repo1 &&
+	git checkout -t -b local-tracking master &&
+	test_commit ten &&
+	test_push_success current local-tracking
+'
+
 test_done
-- 
1.8.3.rc1.579.g184e698