All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fetch: add new fetch.default configuration
@ 2013-05-18  2:18 Felipe Contreras
  2013-05-18 18:43 ` Ramkumar Ramachandra
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Felipe Contreras @ 2013-05-18  2:18 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Ramkumar Ramachandra, Johannes Schindelin,
	Björn Gustavsson, Felipe Contreras

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

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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-18  2:18 [PATCH] fetch: add new fetch.default configuration Felipe Contreras
@ 2013-05-18 18:43 ` Ramkumar Ramachandra
  2013-05-18 22:20   ` Felipe Contreras
  2013-05-19  2:42 ` Eric Sunshine
  2013-06-01 14:04 ` Felipe Contreras
  2 siblings, 1 reply; 9+ messages in thread
From: Ramkumar Ramachandra @ 2013-05-18 18:43 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-18 18:43 ` Ramkumar Ramachandra
@ 2013-05-18 22:20   ` Felipe Contreras
  2013-05-19 11:51     ` Ramkumar Ramachandra
  0 siblings, 1 reply; 9+ messages in thread
From: Felipe Contreras @ 2013-05-18 22:20 UTC (permalink / raw)
  To: Ramkumar Ramachandra
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

On Sat, May 18, 2013 at 1:43 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-18  2:18 [PATCH] fetch: add new fetch.default configuration Felipe Contreras
  2013-05-18 18:43 ` Ramkumar Ramachandra
@ 2013-05-19  2:42 ` Eric Sunshine
  2013-06-01 14:04 ` Felipe Contreras
  2 siblings, 0 replies; 9+ messages in thread
From: Eric Sunshine @ 2013-05-19  2:42 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Git List, Junio C Hamano, Ramkumar Ramachandra,
	Johannes Schindelin, Björn Gustavsson

On Fri, May 17, 2013 at 10:18 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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/

> 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/

> 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/

> 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/

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-18 22:20   ` Felipe Contreras
@ 2013-05-19 11:51     ` Ramkumar Ramachandra
  2013-05-19 12:15       ` Felipe Contreras
  0 siblings, 1 reply; 9+ messages in thread
From: Ramkumar Ramachandra @ 2013-05-19 11:51 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

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}, 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).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-19 11:51     ` Ramkumar Ramachandra
@ 2013-05-19 12:15       ` Felipe Contreras
  2013-05-19 12:26         ` Ramkumar Ramachandra
  0 siblings, 1 reply; 9+ messages in thread
From: Felipe Contreras @ 2013-05-19 12:15 UTC (permalink / raw)
  To: Ramkumar Ramachandra
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-19 12:15       ` Felipe Contreras
@ 2013-05-19 12:26         ` Ramkumar Ramachandra
  2013-05-19 12:37           ` Felipe Contreras
  0 siblings, 1 reply; 9+ messages in thread
From: Ramkumar Ramachandra @ 2013-05-19 12:26 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-19 12:26         ` Ramkumar Ramachandra
@ 2013-05-19 12:37           ` Felipe Contreras
  0 siblings, 0 replies; 9+ messages in thread
From: Felipe Contreras @ 2013-05-19 12:37 UTC (permalink / raw)
  To: Ramkumar Ramachandra
  Cc: git, Junio C Hamano, Johannes Schindelin, Björn Gustavsson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fetch: add new fetch.default configuration
  2013-05-18  2:18 [PATCH] fetch: add new fetch.default configuration Felipe Contreras
  2013-05-18 18:43 ` Ramkumar Ramachandra
  2013-05-19  2:42 ` Eric Sunshine
@ 2013-06-01 14:04 ` Felipe Contreras
  2 siblings, 0 replies; 9+ messages in thread
From: Felipe Contreras @ 2013-06-01 14:04 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Ramkumar Ramachandra, Johannes Schindelin,
	Björn Gustavsson, Felipe Contreras

On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-06-01 14:04 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-18  2:18 [PATCH] fetch: add new fetch.default configuration Felipe Contreras
2013-05-18 18:43 ` Ramkumar Ramachandra
2013-05-18 22:20   ` Felipe Contreras
2013-05-19 11:51     ` Ramkumar Ramachandra
2013-05-19 12:15       ` Felipe Contreras
2013-05-19 12:26         ` Ramkumar Ramachandra
2013-05-19 12:37           ` Felipe Contreras
2013-05-19  2:42 ` Eric Sunshine
2013-06-01 14:04 ` Felipe Contreras

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.