Re: [PATCH] fetch: add new fetch.default configuration
On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras felipe.contre...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra
artag...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra artag...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
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).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
Felipe Contreras felipe.contre...@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|...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
On Sat, May 18, 2013 at 1:43 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras felipe.contre...@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/cleanups85b0869 [master] build: do not install
git-remote-testpy
fc/comp/files4edc621 [master] completion: remove
__git_index_file_list_filter()
fc/comp/ls-remote0d2d2d7 [master] completion: avoid
ls-remote in certain scenarios
fc/comp/parseeb1c813 [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/master5d63a6e [master] travis: update test command
fc/related/v5fad98e7 [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-next062400f [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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch: add new fetch.default configuration
On Fri, May 17, 2013 at 10:18 PM, Felipe Contreras
felipe.contre...@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 .
* branchmaster - 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 .
* branchmaster - 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.contre...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fetch: add new fetch.default configuration
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 .
* branchmaster - 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 .
* branchmaster - 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.contre...@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
