Re: [PATCH 1/3] fetch: add --allow-local option
Junio C Hamano wrote: > Felipe Contreras writes: > > > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote: > >> Felipe Contreras 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.
Re: [PATCH 1/3] fetch: add --allow-local option
"Philip Oakley" writes: > From: "Junio C Hamano" > 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. -- 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 1/3] fetch: add --allow-local option
Felipe Contreras writes:
> On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
>> Felipe Contreras 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
Re: [PATCH 1/3] fetch: add --allow-local option
On Sat, May 18, 2013 at 3:53 PM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Saturday, May 18, 2013 3:23 PM
>>
>> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley
>> wrote:
>>>
>>> From: "Junio C Hamano"
>>> 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..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 from
> another branch in the local repository, you can point
> branch..merge to the desired branch, and use the special setting .
> (a period) for branch..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
--
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 1/3] fetch: add --allow-local option
From: "Felipe Contreras" Sent: Saturday, May 18, 2013 3:23 PM On Sat, May 18, 2013 at 8:12 AM, Philip Oakley wrote: From: "Junio C Hamano" 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..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 from another branch in the local repository, you can point branch..merge to the desired branch, and use the special setting . (a period) for branch..remote." It feels as if this dwimmery(?) should also be listed in the gitcli(7) documenation and under branch..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" wrote: Another trick is to use "git push": git push . $production_sha1:refs/heads/master Philip -- 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 1/3] fetch: add --allow-local option
On Sat, May 18, 2013 at 8:12 AM, Philip Oakley wrote: > From: "Junio C Hamano" > 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 -- 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 1/3] fetch: add --allow-local option
From: "Junio C Hamano" 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 -- 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 1/3] fetch: add --allow-local option
On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote: > Felipe Contreras 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 -- 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 1/3] fetch: add --allow-local option
Felipe Contreras 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. -- 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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 6:24 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: >>> Felipe Contreras 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 -- 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 1/3] fetch: add --allow-local option
Felipe Contreras writes: > On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: >> Felipe Contreras 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. -- 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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: > Felipe Contreras 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 -- 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 1/3] fetch: add --allow-local option
Felipe Contreras 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? -- 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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 11:38 AM, Junio C Hamano wrote:
> Felipe Contreras 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
--
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 1/3] fetch: add --allow-local option
Felipe Contreras 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.
--
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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano 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
--
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 1/3] fetch: add --allow-local option
Felipe Contreras 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.
--
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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra 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 -- 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 1/3] fetch: add --allow-local option
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? -- 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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra
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
--
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 1/3] fetch: add --allow-local option
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.
--
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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 4:27 AM, Ramkumar Ramachandra 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 -- 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 1/3] fetch: add --allow-local option
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?) -- 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 1/3] fetch: add --allow-local option
On Thu, May 16, 2013 at 3:25 AM, Ramkumar Ramachandra 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..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 -- 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 1/3] fetch: add --allow-local option
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..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. -- 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 1/3] fetch: add --allow-local option
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
---
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
--
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
