threads / patch / 33861

patchfetch: add new fetch.default configuration

Subject: [PATCH] fetch: add new fetch.default configuration

## tl;dr

9 messages between May 18, 2013 and Jun 1, 2013. Diffs are folded; open one to read it.

replies: 8people: 3as markdown or json

Felipe Contreras· May 18, 2013, 02:18 UTC · lore

When the user has an upstream branch configured to track a remote tracking branch:

  % git checkout --set-upstream-to github/master

Doing a 'git fetch' without any arguments would try to fetch 'github', because it's configured as current branch's remote (branch.<current>.remote).

However, if we do something slightly different:
  % git checkout --set-upstream-to master

Doing a 'git fetch' without any arguments would try to fetch the remote '.', for the same reason.

But, unlike the in the first instance, the second command would not update any remote tracking branch, in fact, it would not update any branch at all. The only effect is that it would update FETCH_HEAD.

FETCH_HEAD is a special symbol that is used to store the result of a fetch. It can be used by other commands of git, specially 'git merge'.

It is however, barely mentioned in the documentation, and can be considered a plumbing concept at best, that few Git users would benefit from using, and indeed, quite likely very few use it, or are even aware of it.

So when the user is presented with a message like this:
  % git fetch
  From .
   * branch            master     -> FETCH_HEAD

The vast majority of them would have absolutely no idea what's going on. Many of them would probably just shrug, and manually specify the remote the want to fetch from, which is 'origin' in many cases.

If the user has say, twenty branches, ten with a local upstream (branch.<name>.remote = '.'), and ten without an upstream. The user might get used to typing 'git fetch' and expect Git to fetch from 'origin' which would happen 50% of the time, but the other 50%, the user would be forced to specify the remote.

This inconsistency would be simply one more to join the list of incomprehensible quirks the user has to put up when using Git, so quite likely (s)he simply gets used to it, only to complain later in forums or social media, outside of the dwelling distance of the typical Git developer.

But we can do better.

We can add a new 'fetch.default' configuration variable (one more to join the many necessary to force Git to behave in sane manner), so the user can specify what (s)he wants to be performed when the remote is not specified in the 'git fetch' command.

This configuration would probably be welcome by 99% of the user population, who have no clue what FETCH_HEAD is, and do set local upstream branches, only to find out weird inconsistent behavior depending on which branch the happen to be sitting at.

We add documentation and testing as expected, and also introduce other changes necessary to make the configuration enter into effect when it's needed.

The default (FETCH_DEFAULT_UNSPECIFIED), allows the current behavior to be unmodified, so remote_get(NULL) is called, and the current rules to determine the default branch remain.

The new option "simple" allows Git to always fetch from "origin", which is what most users would expect, and it's 100% consistent.

Alternatively, the user can manually specify the current behavior with "current" (alluding to the current branch), so that the behavior changes depending on which branch the user happens to be sitting at. This would allow the user to retain this behavior, if (s)he so wishes, in case Git developers regain their sense and set a default that most users would appreciate ("simple").

If the user wants, for whatever strange reason swimming in his/her head, (s) can still fetch from a local ('.') remote (even stating that as an English sentence doesn't make any sense).

  % git fetch .
  From .
   * branch            master     -> FETCH_HEAD
And to any number of weird hacks with FETCH_HEAD.

The average user lucky enough to find the 'fetch.default' configuration, however, would never have to enter the word of "local remote" strangeness, and would remain comfortably in the place where locals are locals, and remotes are remotes, and 'git fetch' is always consistent, and always does something useful.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/config.txt    |  9 +++++++++
 Documentation/git-fetch.txt |  4 ++++
 builtin/fetch.c             | 10 +++++++++-
 cache.h                     |  7 +++++++
 config.c                    | 21 +++++++++++++++++++++
 environment.c               |  1 +
 t/t5513-fetch-track.sh      | 43 +++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 94 insertions(+), 1 deletion(-)
Show changes to 7 files +94 −1

Documentation/config.txt, Documentation/git-fetch.txt, builtin/fetch.c, cache.h, config.c, environment.c, t/t5513-fetch-track.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53fc5..0c48490 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1860,6 +1860,15 @@ branches are not yet ready to be pushed out. If you are working with
 other people to push into the same shared repository, you would want
 to use one of these.
 
+fetch.default::
+	Defines the action `git fetch` should take if no remote is specified
+	on the command line. Possible values are:
++
+--
+* `current` - fetch from the upstream of the current branch.
+* `simple` - always fetch from `origin`.
+--
+
 rebase.stat::
 	Whether to show a diffstat of what changed upstream since the last
 	rebase. False by default.
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index e08a028..5c4afdc 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -37,6 +37,10 @@ or from several repositories at once if <group> is given and
 there is a remotes.<group> entry in the configuration file.
 (See linkgit:git-config[1]).
 
+When no remote is specified, by the default the `origin` remote will be used,
+unless there's an upstream branch configured for the current branch. This can
+be configured with `fetch.default`.
+
 OPTIONS
 -------
 include::fetch-options.txt[]
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b6b1df..8e1a79d 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -973,6 +973,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 	for (i = 1; i < argc; i++)
 		strbuf_addf(&default_rla, " %s", argv[i]);
 
+	git_config(git_default_config, NULL);
 	argc = parse_options(argc, argv, prefix,
 			     builtin_fetch_options, builtin_fetch_usage, 0);
 
@@ -1006,7 +1007,14 @@ 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);
+		switch (fetch_default) {
+		case FETCH_DEFAULT_SIMPLE:
+			remote = remote_get("origin");
+			break;
+		default:
+			remote = remote_get(NULL);
+			break;
+		}
 		result = fetch_one(remote, argc, argv);
 	} else if (multiple) {
 		/* All arguments are assumed to be remotes or groups */
diff --git a/cache.h b/cache.h
index 7ce9061..bb646bb 100644
--- a/cache.h
+++ b/cache.h
@@ -603,9 +603,16 @@ enum push_default_type {
 	PUSH_DEFAULT_UNSPECIFIED
 };
 
+enum fetch_default_type {
+	FETCH_DEFAULT_UNSPECIFIED = 0,
+	FETCH_DEFAULT_SIMPLE,
+	FETCH_DEFAULT_CURRENT
+};
+
 extern enum branch_track git_branch_track;
 extern enum rebase_setup_type autorebase;
 extern enum push_default_type push_default;
+extern enum fetch_default_type fetch_default;
 
 enum object_creation_mode {
 	OBJECT_CREATION_USES_HARDLINKS = 0,
diff --git a/config.c b/config.c
index 830ee14..1ce8543 100644
--- a/config.c
+++ b/config.c
@@ -849,6 +849,24 @@ static int git_default_push_config(const char *var, const char *value)
 	return 0;
 }
 
+static int git_default_fetch_config(const char *var, const char *value)
+{
+	if (strcmp(var, "fetch.default"))
+		return 0;
+
+	if (!value)
+		return config_error_nonbool(var);
+	else if (!strcmp(value, "simple"))
+		fetch_default = FETCH_DEFAULT_SIMPLE;
+	else if (!strcmp(value, "current"))
+		fetch_default = FETCH_DEFAULT_CURRENT;
+	else {
+		error("Malformed value for %s: %s", var, value);
+		return error("Must be simple, or current.");
+	}
+	return 0;
+}
+
 static int git_default_mailmap_config(const char *var, const char *value)
 {
 	if (!strcmp(var, "mailmap.file"))
@@ -877,6 +895,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
 	if (!prefixcmp(var, "push."))
 		return git_default_push_config(var, value);
 
+	if (!prefixcmp(var, "fetch."))
+		return git_default_fetch_config(var, value);
+
 	if (!prefixcmp(var, "mailmap."))
 		return git_default_mailmap_config(var, value);
 
diff --git a/environment.c b/environment.c
index e2e75c1..f24873b 100644
--- a/environment.c
+++ b/environment.c
@@ -51,6 +51,7 @@ unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
 enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
+enum fetch_default_type fetch_default = FETCH_DEFAULT_UNSPECIFIED;
 #ifndef OBJECT_CREATION_MODE
 #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
 #endif
diff --git a/t/t5513-fetch-track.sh b/t/t5513-fetch-track.sh
index 65d1e05..dcd4a8b 100755
--- a/t/t5513-fetch-track.sh
+++ b/t/t5513-fetch-track.sh
@@ -27,4 +27,47 @@ test_expect_success fetch '
 	)
 '
 
+cat >expected <<EOF
+236e830928a4295f5473416501dd777933bb778e		branch 'master' of .
+EOF
+
+test_expect_success 'fetch default' '
+	test_when_finished "rm -rf another" &&
+
+	(
+		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 &&
+		test_cmp ../expected .git/FETCH_HEAD
+	)
+'
+cat >expected <<EOF
+9d34b142e42f6b3dbab46dd4b9bc515e0ab16101	not-for-merge	branch 'b-0' of ..
+9d34b142e42f6b3dbab46dd4b9bc515e0ab16101	not-for-merge	branch 'b/one' of ..
+9d34b142e42f6b3dbab46dd4b9bc515e0ab16101	not-for-merge	branch 'b1' of ..
+9d34b142e42f6b3dbab46dd4b9bc515e0ab16101	not-for-merge	branch 'master' of ..
+EOF
+
+test_expect_success 'fetch default simple' '
+	test_when_finished "rm -rf another" &&
+
+	(
+		test_create_repo another &&
+		cd another &&
+		git config fetch.default simple &&
+		git remote add origin .. &&
+		echo test > file &&
+		git add . &&
+		git commit -m test &&
+		git checkout -t -b local-tracking master &&
+		git fetch &&
+		test_cmp ../expected .git/FETCH_HEAD
+	)
+'
+
 test_done
-- 
1.8.3.rc2.542.g24820ba
Ramkumar Ramachandra· May 18, 2013, 18:43 UTC · re: Felipe Contreras · lore

Re: [PATCH] fetch: add new fetch.default configuration

Felipe Contreras <felipe.contreras@gmail.com> wrote:
>   % git checkout --set-upstream-to master

What is the problem you're trying to solve: why do you want an upstream set to master? Is it only because of rebase? We should probably get rebase.defaultUpstream = @{u}|origin|...

Felipe Contreras· May 18, 2013, 22:20 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] fetch: add new fetch.default configuration

On Sat, May 18, 2013 at 1:43 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 5 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>>   % git checkout --set-upstream-to master
>
> What is the problem you're trying to solve: why do you want an
> upstream set to master?

I have explained that multiple times already. I want all my branches to have an upstream:

% git config --global branch.autosetupmerge always % git checkout -b topic master # stuff % git rebase -i

> Is it only because of rebase?  We should
> probably get rebase.defaultUpstream = @{u}|origin|...
No. I want to set upstream by myself.
This is what I have now:
  fc/branch/fast               27cff17 [master] branch: add show-tracking option
  fc/build/cleanups            85b0869 [master] build: do not install
git-remote-testpy
  fc/comp/files                4edc621 [master] completion: remove
__git_index_file_list_filter()
  fc/comp/ls-remote            0d2d2d7 [master] completion: avoid
ls-remote in certain scenarios
  fc/comp/parse                eb1c813 [master] completion: Use
parse-options raw output for simple long options
  fc/comp/zsh-cleanup          4ad3e4f [master] completion: zsh:
improve bash script loading
  fc/fast-export/cleanup       1714a14 [master] fast-export: refactor
get_tags_and_duplicates()
  fc/fast-export/fast-v2       69b24ba [master] fast-{import,export}:
use get_sha1_hex() directly
  fc/fetch/default             1939536 [master] fetch: add new
fetch.default configuration
  fc/head/v4                   be582cf [master] Add new @ shortcut for HEAD
  fc/ident-fix                 74baf50 [master] ident: don't allow
implicit email addresses
  fc/master                    5d63a6e [master] travis: update test command
  fc/related/v5                fad98e7 [master] contrib: related: fix
parsing of rev-list args
  fc/remote-sync               53a1457 [master] remote: add new sync command
  fc/remote/bzr-debug          bed1b93 [fc/remote/bzr-next]
remote-bzr: add debugging information
  fc/remote/bzr-next           1e52047 [next] remote-bzr: add fallback
check for a partial clone
  fc/remote/hg-extra           080301e [fc/remote/hg-next] remote-hg:
store extra hg information in notes
  fc/remote/hg-gitifyhg-compat c4eb2b9 [fc/remote/hg-notes] compat:
remote-hg: use mercurial's username
  fc/remote/hg-next            062400f [master] remote-hg: remove
files before modifications
  fc/remote/hg-notes           2c38768 [fc/remote/hg-next] remote-hg:
support for notes
  fc/remote/hg-pep             f19bd8b [fc/remote/hg-next] remote-hg:
remove unnecessary global definitions
  fc/run-command/simplify      a320010 [master] run-command: simplify
wait_or_whine
  fc/send-email/series-cc-cmd  2cbe0c3 [master] send-email: add
series-cc-cmd option
  fc/stage/part-1              24c50f8 [master] Add proper 'stage' command
  fc/stage/part-2              c7d0f70 [master] completion: update
--staged options
  fc/stage/part-3              4eaea2f [fc/stage/part-2] completion:
update 'git reset' new stage options
  fc/stage/try-1               a4408b9 [master] tmp
  fc/stage/try-2               b29882d [master] doc: use 'stage' for
common commands
  fc/trivial                   74e1483 [master] remote: trivial style cleanup
* fc/upstream                  1c5f4a5 [master] Add travis configuration
  fc/zsh/fix                   92152c4 [master] completion: trivial fix for zsh
  fc/zsh/sub                   aa1b1cf [master] completion: zsh: custom commands
  master                       de3a5c6 [origin/master] Git 1.8.3-rc3
  next                         75252d8 [origin/next] Sync with 1.8.3-rc3
  old/remote/hg-next-check     d184c81 [master] remote-hg: remove
files before modifications
  stable                       4a9a4f0 [origin/master] Git 1.8.2.2
  tmp                          0294f83 [origin/next] Merge branch
'fc/master' into tmp
  tmp2                         4170e70 [work] Merge branch 'work' into tmp2
  work                         4e7f4b3 [master] tmp
I can do:

% git checkout fc/remote/hg-next % git rebase -i # rebase to master % git checkout fc/remote/hg-notes % git rebase -i # rebase to fc/remote/hg-next % git checkout fc/remote/hg-gitifyhg-compat % git rebase -i # rebase to fc/remote/hg-notes

I don't have to think about it. The relationship between branches makes everything just work.

-- 
Felipe Contreras
Ramkumar Ramachandra· May 19, 2013, 11:51 UTC · re: Felipe Contreras · lore

Re: [PATCH] fetch: add new fetch.default configuration

Felipe Contreras wrote:
Show 6 quoted lines
> % git checkout fc/remote/hg-next
> % git rebase -i # rebase to master
> % git checkout fc/remote/hg-notes
> % git rebase -i # rebase to fc/remote/hg-next
> % git checkout fc/remote/hg-gitifyhg-compat
> % git rebase -i # rebase to fc/remote/hg-notes

So it is rebase, but rebase.defaultUpstream = origin won't suffice. You want to specify a custom base. What I don't understand is why you're abusing @{u}, and crippling remote (by hard-interpreting it as "origin") to achieve this. For the record, I didn't think your branch.<name>.base was a bad idea at all (re-visiting now).

Felipe Contreras· May 19, 2013, 12:15 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] fetch: add new fetch.default configuration

On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 11 quoted lines
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>> % git checkout fc/remote/hg-notes
>> % git rebase -i # rebase to fc/remote/hg-next
>> % git checkout fc/remote/hg-gitifyhg-compat
>> % git rebase -i # rebase to fc/remote/hg-notes
>
> So it is rebase, but rebase.defaultUpstream = origin won't suffice.
> You want to specify a custom base.  What I don't understand is why
> you're abusing @{u},
There's no abuse; 'upstream' is meant *exactly* for this: rebase, and pull.

It's called upstream because that's where eventually all the code must go, so semantically it's *exactly* correct: 'origin/master' is the upstream of 'master' which is the upstream of 'fc/remote/hg-next', which is the upstream of 'fc/remote/hg-notes', and so on.

And if I where to merge a branch from 'master', it make sense that the default is 'origin/master', because that's the upstream.

Literally each and every way in which 'upstream' is used remains the same for local branches, except for 'git push'.

> and crippling remote (by hard-interpreting it as
> "origin") to achieve this.
More false rhetoric; "origin" is *ALREADY* the default.
Show me the output of these:

%git clone --origin foobar git://git.kernel.org/pub/scm/git/git.git /tmp/git %cd /tmp/git %git fetch -v %git checkout --no-track -b test master %git fetch -v

> For the record, I didn't think your
> branch.<name>.base was a bad idea at all (re-visiting now).

It makes sens for rebase, but what happens when you do 'git pull' and you don't have an upstream configured, only a base? Why would you want 'git pull' to fail? In which instances would you want to have a 'base', but not an 'upstream'?

Think about it.
-- 
Felipe Contreras
Ramkumar Ramachandra· May 19, 2013, 12:26 UTC · re: Felipe Contreras · lore

Re: [PATCH] fetch: add new fetch.default configuration

My itch is very simple.
Felipe Contreras wrote:
> % git checkout fc/remote/hg-next
> % git rebase -i # rebase to master
% git pull # I want: pull from origin
> % git checkout fc/remote/hg-notes
> % git rebase -i # rebase to fc/remote/hg-next
% git pull # I want: pull from ram
> % git checkout fc/remote/hg-gitifyhg-compat
> % git rebase -i # rebase to fc/remote/hg-notes
% git pull # I want: pull from felipe

With your series, rebase works and I like that. But, by specifying branch.<name>.remote as '.', I've essentially lost a way to specify a remote I want. Why can't I have both?

Felipe Contreras· May 19, 2013, 12:37 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] fetch: add new fetch.default configuration

On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 7 quoted lines
> My itch is very simple.
>
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>
> % git pull # I want: pull from origin
Then do 'git pull origin', 'fc/remote/hg-next' has *nothing* to do with origin.
>> % git checkout fc/remote/hg-notes
>> % git rebase -i # rebase to fc/remote/hg-next
>
> % git pull # I want: pull from ram
Ditto.
>> % git checkout fc/remote/hg-gitifyhg-compat
>> % git rebase -i # rebase to fc/remote/hg-notes
>
> % git pull # I want: pull from felipe
Ditto.
> With your series, rebase works and I like that.  But, by specifying
> branch.<name>.remote as '.',
I'm not doing that *GIT* is doing that.

What does this throw? % git checkout --track -b foo master % git config branch.foo.remote

> I've essentially lost a way to specify a
> remote I want.  Why can't I have both?

You haven't lost anything. The upstream is 'branch.x.remote'+'branch.x.merge', and it remains so before and after this patch. You can set 'branch.x.remote' to whatever you want.

-- 
Felipe Contreras
Eric Sunshine· May 19, 2013, 02:42 UTC · re: Felipe Contreras · lore

Re: [PATCH] fetch: add new fetch.default configuration

On Fri, May 17, 2013 at 10:18 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 37 quoted lines
> When the user has an upstream branch configured to track a remote
> tracking branch:
>
>   % git checkout --set-upstream-to github/master
>
> Doing a 'git fetch' without any arguments would try to fetch 'github',
> because it's configured as current branch's remote
> (branch.<current>.remote).
>
> However, if we do something slightly different:
>
>   % git checkout --set-upstream-to master
>
> Doing a 'git fetch' without any arguments would try to fetch the remote
> '.', for the same reason.
>
> But, unlike the in the first instance, the second command would not
> update any remote tracking branch, in fact, it would not update any
> branch at all. The only effect is that it would update FETCH_HEAD.
>
> FETCH_HEAD is a special symbol that is used to store the result of a
> fetch. It can be used by other commands of git, specially 'git merge'.
>
> It is however, barely mentioned in the documentation, and can be
> considered a plumbing concept at best, that few Git users would benefit
> from using, and indeed, quite likely very few use it, or are even aware
> of it.
>
> So when the user is presented with a message like this:
>
>   % git fetch
>   From .
>    * branch            master     -> FETCH_HEAD
>
> The vast majority of them would have absolutely no idea what's going on.
> Many of them would probably just shrug, and manually specify the remote
> the want to fetch from, which is 'origin' in many cases.
s/the/they/
Show 8 quoted lines
> If the user has say, twenty branches, ten with a local upstream
> (branch.<name>.remote = '.'), and ten without an upstream. The user
> might get used to typing 'git fetch' and expect Git to fetch from
> 'origin' which would happen 50% of the time, but the other 50%, the user
> would be forced to specify the remote.
>
> This inconsistency would be simply one more to join the list of
> incomprehensible quirks the user has to put up when using Git, so quite
s/up/up with/
Show 15 quoted lines
> likely (s)he simply gets used to it, only to complain later in forums or
> social media, outside of the dwelling distance of the typical Git
> developer.
>
> But we can do better.
>
> We can add a new 'fetch.default' configuration variable (one more to
> join the many necessary to force Git to behave in sane manner), so the
> user can specify what (s)he wants to be performed when the remote is not
> specified in the 'git fetch' command.
>
> This configuration would probably be welcome by 99% of the user
> population, who have no clue what FETCH_HEAD is, and do set local
> upstream branches, only to find out weird inconsistent behavior
> depending on which branch the happen to be sitting at.
s/the/they/
Show 20 quoted lines
> We add documentation and testing as expected, and also introduce other
> changes necessary to make the configuration enter into effect when it's
> needed.
>
> The default (FETCH_DEFAULT_UNSPECIFIED), allows the current behavior to
> be unmodified, so remote_get(NULL) is called, and the current rules to
> determine the default branch remain.
>
> The new option "simple" allows Git to always fetch from "origin", which
> is what most users would expect, and it's 100% consistent.
>
> Alternatively, the user can manually specify the current behavior with
> "current" (alluding to the current branch), so that the behavior changes
> depending on which branch the user happens to be sitting at. This would
> allow the user to retain this behavior, if (s)he so wishes,
> in case Git developers regain their sense and set a default that most
> users would appreciate ("simple").
>
> If the user wants, for whatever strange reason swimming in his/her head,
> (s) can still fetch from a local ('.') remote (even stating that as an
s/(s)/(s)he/
Show 15 quoted lines
> English sentence doesn't make any sense).
>
>   % git fetch .
>   From .
>    * branch            master     -> FETCH_HEAD
>
> And to any number of weird hacks with FETCH_HEAD.
>
> The average user lucky enough to find the 'fetch.default' configuration,
> however, would never have to enter the word of "local remote"
> strangeness, and would remain comfortably in the place where locals are
> locals, and remotes are remotes, and 'git fetch' is always consistent,
> and always does something useful.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Felipe Contreras· Jun 1, 2013, 14:04 UTC · re: Felipe Contreras · lore

Re: [PATCH] fetch: add new fetch.default configuration

On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 15 quoted lines
> When the user has an upstream branch configured to track a remote
> tracking branch:
>
>   % git checkout --set-upstream-to github/master
>
> Doing a 'git fetch' without any arguments would try to fetch 'github',
> because it's configured as current branch's remote
> (branch.<current>.remote).
>
> However, if we do something slightly different:
>
>   % git checkout --set-upstream-to master
>
> Doing a 'git fetch' without any arguments would try to fetch the remote
> '.', for the same reason.
What happened to this? Didn't you want big commit messages?
-- 
Felipe Contreras

← back to recent threads