Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Felipe Contreras felipe.contre...@gmail.com writes:
She told Git that her local svn-branch was the basis for svn-next. She
DIT NOT TELL Git to fetch from there. She told Git to fetch from any
location Git thought best to fetch from, either a) or b) would fetch
from the wrong location, but a) would be wronger, you just don't want
to admit it.
(a) is more wrong is just your opinion, and you are simply wrong.
She is working on svn-ext based on her local git-svn the latter of
which has some changes of her own on top of Eric's tree.
When working on _any_ branch that bases its work on something else,
you have @{u} available, but that @{u} will not stay up-to-date if
you forked from work that is done outside your repository. That is
what an unqualified git fetch is designed to help when run on a
branch that bases its work on something else. If you happen to know
that yoru current branch is forked from git-svn that is a local
branch, then running git fetch becomes unnecessary for the purpose
of updating @{u} (it already and always is up to date), so doing no
object transfer and no ref update is absolutely the right thing to
do. That is what remote = . gives you.
In addition, that does not break the pull = fetch + merge
equivalence you seem to be ignoring.
If she wants to check what Eric has been doing, she can do git
fetch git-svn, giving the remote name she calls Eric's tree with.
At that point, she is not saying I want to check what is happening
to the upstream of my _current_ branch (and the fetched result is
not something she can immediately use while on her current branch).
On the other hand, an unqualified git fetch that slurps from my
tree, which is your (b), is just plain wrong. My tree is not even
related to what she is working on.
Of course, when she is interested in what have been happening in my
tree, she can say git fetch 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Felipe Contreras felipe.contre...@gmail.com Sent: Wednesday, May 22, 2013 12:03 AM On Tue, May 21, 2013 at 5:33 PM, Philip Oakley philipoak...@iee.org wrote: From: Felipe Contreras felipe.contre...@gmail.com Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano gits...@pobox.com wrote: Philip Oakley philipoak...@iee.org writes: On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master It all falls out naturally from the Git is distributed and no repository is special principle. I think that word trick merely refers to those who do not realize that the local repository is not all that special and merely is _a_ repository just like anybody else's may not realize they can do this, nothing more. Nobody cares. The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 How is that more useful than 'git branch -f master $sha1'? The 'trick' checks for a fast forward, while the branch update is forced. It depends on what checks are desired. My original patch was to simply document Git's dot repository capability that does not appear to be that well known. Let's not keep it as an Easter Egg. Not sure if that was the caring you were commenting on. My point is that nobody uses '.' as a remote. Yes, you can find the occasional esoteric person in the Git mailing list that might find some weird command useful, but that's the fringe user-base. You say it's mistaken, but you are not the arbiter of truth; the fact that you say it's so doesn't make it so. It's just rhetoric. You haven't shown that it's indeed mistaken. An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a planned action which later turns out to not be the action that would now have, in retrospect, been chosen. The intent was good, but is later classed (within the taxonomy) as a 'mistake'. (It is not related to 'blame'). Yeah, that's what a mistake is, in my mind. If I understand the extended thread correctly, the approach moved on and alternatives were found, so in that sense the intent was good. No, the approach didn't move on, there are no better alternatives, the intent is irrelevant, the approach is good, there is no mistake. Junio simply ignored the fact that he was proven wrong. I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3343 / Virus Database: 3162/6344 - Release Date: 05/21/13 -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Wed, May 22, 2013 at 11:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
She told Git that her local svn-branch was the basis for svn-next. She
DIT NOT TELL Git to fetch from there. She told Git to fetch from any
location Git thought best to fetch from, either a) or b) would fetch
from the wrong location, but a) would be wronger, you just don't want
to admit it.
(a) is more wrong is just your opinion, and you are simply wrong.
My opinion based on very solid grounds; the whole purpose of 'git
fetch; is to FETCH from a REMOTE. a) is not doing that at all.
In addition, the vast majority of users don't have a clue as to what the hell
From .
* branchmaster - FETCH_HEAD
means.
a) is wronger. Period.
You say it's not, but give no explanation at all. This is no way to argue.
She is working on svn-ext based on her local git-svn the latter of
which has some changes of her own on top of Eric's tree.
When working on _any_ branch that bases its work on something else,
you have @{u} available, but that @{u} will not stay up-to-date if
you forked from work that is done outside your repository. That is
what an unqualified git fetch is designed to help when run on a
branch that bases its work on something else.
The fact that it's designed that way doesn't mean it's a good design,
and it doesn't mean the user expects that.
If you happen to know
that yoru current branch is forked from git-svn that is a local
branch,
That's a very big *IF*.
then running git fetch becomes unnecessary for the purpose
of updating @{u} (it already and always is up to date), so doing no
object transfer and no ref update is absolutely the right thing to
do. That is what remote = . gives you.
Jumping to conclusions based on assumptions again.
Sally doesn't know what the designers intended, Sally doesn't remember
what is the upstream of the current branch, of it has any upstream at
all. Sally does 'git fetch' instinctively, and expects Git to do the
right thing, but it doesn't, it does an utterly irrelevant and useless
action; non-fetching from a local-remote.
In addition, that does not break the pull = fetch + merge
equivalence you seem to be ignoring.
Do you want me to count to you the many times I've proved to you that
pull is NOT fetch + merge?
YOU are the one ignoring the fact that it's not: it's only that way in
very specific circumstances, certaily ver far from being a universal
truth.
If she wants to check what Eric has been doing, she can do git
fetch git-svn, giving the remote name she calls Eric's tree with.
At that point, she is not saying I want to check what is happening
to the upstream of my _current_ branch (and the fetched result is
not something she can immediately use while on her current branch).
Irrelevant.
On the other hand, an unqualified git fetch that slurps from my
tree, which is your (b), is just plain wrong.
But that's *EXACTLY* what we do when there's no upstream branch, is it not?
My tree is not even
related to what she is working on.
Unless you are prepared to say fetching from any other tree that @{u}
is wrong, and 'git fetch' should forbit it, this is irrelevant.
The user can fetch from wherever they want.
Of course, when she is interested in what have been happening in my
tree, she can say git fetch origin.
Irrelevant. We are not changing that behavior.
--
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Wed, May 22, 2013 at 5:09 PM, Philip Oakley philipoak...@iee.org wrote: From: Felipe Contreras felipe.contre...@gmail.com Sent: Wednesday, May 22, 2013 12:03 AM The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 How is that more useful than 'git branch -f master $sha1'? The 'trick' checks for a fast forward, while the branch update is forced. It depends on what checks are desired. If that was truly useful, surely we could add an option for 'git branch' to do just that. My original patch was to simply document Git's dot repository capability that does not appear to be that well known. Let's not keep it as an Easter Egg. I know, all I said is that I think nobody cares about that implementation detail. Instead of explaining to the user why Git has so many quirks, we should get rid of them and make it work more in line with users' expectations. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
Interesting. Any thoughts on which way it should be
documented/deprecated?
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch mywork]
remote = .
merge = refs/heads/master
works _as if_ you have
Thank you of the confirmation.
[remote .]
url = .
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
Yes.
And remote.$name.url = . for any name, e.g.
[remote here]
url = .
is a special case of local repository that is named with a relative
filesystem path.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
Oh I don't know. I don't think 'sanity' comes into it any more than
'common sense' is common. It's easy to fall into the inverse
Kruger-Dunning mode where those in the know don't realise how much they
know, and how 'stupid' those that don't can be (that'd be me;-).
All this 'what's a dot-repo and where can I use it' came about because
of an answer that give it's use as a 'trick'.
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
Another trick is to use git push:
git push . $production_sha1:refs/heads/master
and
Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local
option, 16 May 2013
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
Interesting. Any thoughts on which way it should be
documented/deprecated?
If leave it as-is is not an option, I personally would prefer
mentioning this happens to work, but do not rely on it in the
passing. I do not see any immediate need to break things for people
discovered that this happens to work and who decided that they have
no need for a remote tracking branch for the particular remote this
branch happens to integrate with. By making that choice, they may
be forgoing the use of @{u}, but they won't be inconvenienced as
git fetch will leave what they need @{u} for in FETCH_HEAD, i.e.
instead of doing
git fetch
git log [-p] ..@{u}
git merge @{u} ;# or git rebase @{u}
as a verify in the middle replacement for git pull [--rebase],
they can do
git fetch
git log [-p] ..FETCH_HEAD
git merge FETCH_HEAD ;# or git rebase FETCH_HEAD
just fine.
The do not rely on it is primarily because there are more familiar
ways invented later (namely, use a named remote instead of writing a
real URL, with remote tracking branches). I do not think we would
want to deliberately sabotage the people who currently use such a
setting, but I do not see a strong reason to recommend it to people
who are new to Git, either, *unless* they need to fetch from many
different places and do not want to have remote tracking branches
because the only time they care about the state of their remotes is
immediately after they fetched.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
Oh I don't know. I don't think 'sanity' comes into it any more than
common sense' is common. It's easy to fall into the inverse
Kruger-Dunning mode where those in the know don't realise how much
they know, and how 'stupid' those that don't can be (that'd be me;-).
How would you even express such a remote named . in the first
place? git remote add would not let you say:
$ git remote add . git://some.where.xz/some/repo.git
fatal: '.' is not a valid remote name
and even if you add configuration variables by hand, it would not
look like this:
[remote .]
fetch = +refs/heads/*:refs/remotes/./*
You would want some real token between refs/remotes/ and the
trailing /* instead, so...
All this 'what's a dot-repo and where can I use it' came about because
of an answer that give it's use as a 'trick'.
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
Another trick is to use git push:
git push . $production_sha1:refs/heads/master
It all falls out naturally from the Git is distributed and no
repository is special principle. I think that word trick merely
refers to those who do not realize that the local repository is not
all that special and merely is _a_ repository just like anybody
else's may not realize they can do this, nothing more.
Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local
option, 16 May 2013
That patch came from a mistaken suggestion from me that was
retracted with
http://article.gmane.org/gmane.comp.version-control.git/224729
--
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Felipe Contreras felipe.contre...@gmail.com Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano gits...@pobox.com wrote: Philip Oakley philipoak...@iee.org writes: On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master It all falls out naturally from the Git is distributed and no repository is special principle. I think that word trick merely refers to those who do not realize that the local repository is not all that special and merely is _a_ repository just like anybody else's may not realize they can do this, nothing more. Nobody cares. The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 Not sure if that was the caring you were commenting on. My patch was to make it better known and that it (the dot repository) isn't a 'trick'. I'll refresh them after v1.8.3. Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local option, 16 May 2013 That patch came from a mistaken suggestion from me that was retracted with You say it's mistaken, but you are not the arbiter of truth; the fact that you say it's so doesn't make it so. It's just rhetoric. You haven't shown that it's indeed mistaken. An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a planned action which later turns out to not be the action that would now have, in retrospect, been chosen. The intent was good, but is later classed (within the taxonomy) as a 'mistake'. (It is not related to 'blame'). If I understand the extended thread correctly, the approach moved on and alternatives were found, so in that sense the intent was good. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Tue, May 21, 2013 at 5:33 PM, Philip Oakley philipoak...@iee.org wrote: From: Felipe Contreras felipe.contre...@gmail.com Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano gits...@pobox.com wrote: Philip Oakley philipoak...@iee.org writes: On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master It all falls out naturally from the Git is distributed and no repository is special principle. I think that word trick merely refers to those who do not realize that the local repository is not all that special and merely is _a_ repository just like anybody else's may not realize they can do this, nothing more. Nobody cares. The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 How is that more useful than 'git branch -f master $sha1'? Not sure if that was the caring you were commenting on. My point is that nobody uses '.' as a remote. Yes, you can find the occasional esoteric person in the Git mailing list that might find some weird command useful, but that's the fringe user-base. You say it's mistaken, but you are not the arbiter of truth; the fact that you say it's so doesn't make it so. It's just rhetoric. You haven't shown that it's indeed mistaken. An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a planned action which later turns out to not be the action that would now have, in retrospect, been chosen. The intent was good, but is later classed (within the taxonomy) as a 'mistake'. (It is not related to 'blame'). Yeah, that's what a mistake is, in my mind. If I understand the extended thread correctly, the approach moved on and alternatives were found, so in that sense the intent was good. No, the approach didn't move on, there are no better alternatives, the intent is irrelevant, the approach is good, there is no mistake. Junio simply ignored the fact that he was proven wrong. I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Felipe Contreras felipe.contre...@gmail.com writes:
I still haven't received a response: which makes more sense?
a)
% git checkout svn-ext
% git fetch
From .
* branchmaster - FETCH_HEAD
# oops
% git fetch git-svn
% git log ..FETCH_HEAD
% git merge FETCH_HEAD
b)
% git checkout svn-ext
% git fetch
From git://git.kernel.org/pub/scm/git/git
680ed3e..de3a5c6 master - origin/master
# oops
% git fetch svn-ext
% git log ..FETCH_HEAD
% git merge FETCH_HEAD
I think with the scenario you are following, a) would prepare the
FETCH_HEAD with her local git-svn branch which is her svn-ext topic
is based on, but you illustrated it to fetch 'master', which I think
is a minor typo.
Modulo that typo, the step before the #oops makes perfect sense. It
fetched where she told Git her work on svn-ext is based on.
But the step after that does not make much sense in that flow.
git fetch git-svn to get from Eric might make sense but running
log with FETCH_HEAD while she is on her svn-ext does not make any
sense, let alone merging with it. Her svn-ext is based on her local
git-svn branch for a reason---her branches are cascaded this way:
Eric -- her local git-svn -- her local svn-ext
Hecking out her git-svn to update/rebase it on top of Eric's latest
and then update her svn-ext that is based on her git-svn may make
sense. But fetching from Eric and merging it into her svn-ext
directly does not.
And what happens before #oops in b) is an utter nonsense. Her
svn-ext is not even related to my tree. I think the step after that
is a typo of git fetch git-svn to fetch from Eric, but again,
because svn-ext is fork from her local git-svn (which is ahead of
Eric's tree with her own changes, but the changes are not related
to her svn-ext work), these fetch from Eric, integrate svn-ext directly
with it makes no sense.
So, the short answer is neither, but a) can be fixed (not in code
but in the typescript) to make more sense, perhaps like this:
% git checkout svn-ext
% git fetch
% git log ..FETCH_HEAD
% git rebase FETCH_HEAD
# The last three can be git pull --rebase.
# ok, did Eric do something in the meantime?
% git checkout git-svn
% git fetch
From git://git.bogomips.org/git-svn.git/
* branch master - git-svn/master
% git rebase FETCH_HEAD
# now let's rebuild the svn-ext on top
% git checkout svn-ext
% git pull --rebase
The last step can be git rebase git-svn, and the step to update
git-svn from Eric after checking it out can be git pull --rebase,
but the whole point of having @{u}, even for branches that fork from
a local branch, is so that the user does not have to remember what
forks from what, so I did not force her to say git rebase git-svn
in that step.
--
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD I think with the scenario you are following, a) would prepare the FETCH_HEAD with her local git-svn branch which is her svn-ext topic is based on, but you illustrated it to fetch 'master', which I think is a minor typo. Modulo that typo, the step before the #oops makes perfect sense. It fetched where she told Git her work on svn-ext is based on. But the step after that does not make much sense in that flow. You don't get to decide what Sally (I'm naming her) does, all you get to decide is what Git does. Sally wants to fetch from the true upstream: svn-ext, but in the process does by mistake a 'git fetch' *without arguments* (WHICH IS WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer: a) or b). Heh, that was my example. In any case, my pick is still a). She *TOLD* Git that her local git-svn branch is what forms the base of her local svn-ext work. I won't even read the remainder. You are not even worth wasting time on discussing this. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Tue, May 21, 2013 at 7:50 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD I think with the scenario you are following, a) would prepare the FETCH_HEAD with her local git-svn branch which is her svn-ext topic is based on, but you illustrated it to fetch 'master', which I think is a minor typo. Modulo that typo, the step before the #oops makes perfect sense. It fetched where she told Git her work on svn-ext is based on. But the step after that does not make much sense in that flow. You don't get to decide what Sally (I'm naming her) does, all you get to decide is what Git does. Sally wants to fetch from the true upstream: svn-ext, but in the process does by mistake a 'git fetch' *without arguments* (WHICH IS WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer: a) or b). Heh, that was my example. In any case, my pick is still a). She *TOLD* Git that her local git-svn branch is what forms the base of her local svn-ext work. She told Git that her local svn-branch was the basis for svn-next. She DIT NOT TELL Git to fetch from there. She told Git to fetch from any location Git thought best to fetch from, either a) or b) would fetch from the wrong location, but a) would be wronger, you just don't want to admit it. You are, once again, *assuming* that if a user sets up an upstream, he wants to fetch from there. All you answers are based on assumptions. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Jonathan Nieder jrnie...@gmail.com writes: --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_ see `hello.c` in your working tree with the former, but with the latter you will. +Just as, by convention, the filesystem '.' refers to the current directory, +using a '.' (period) as a repository name in Git (a dot-repository) refers +to your local repository. Good idea, but I fear that no one would find it there. Also I think it would be better without , by convention,. If you say '.' == current directory is a convention, you have to start saying that by convention, hello.c refers to the file in the current directory of that name, which may be technically correct but make the phrase by convention meaningless. A dot . is *the* name for the current directory, just like hello.c is the name for that file. Just like '.' refers to the current directory in the filesystem, '.' refers to the current repository. would be sufficient. Would it make sense to put this in Documentation/urls.txt (aka the GIT URLS section of git-fetch(1) and git-clone(1)), where other URL schemes are documented? Yes, the '.' described above is a special case of giving a repository URL as a relative-path on the filesystem. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch mywork]
remote = .
merge = refs/heads/master
works _as if_ you have
[remote .]
url = .
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
And remote.$name.url = . for any name, e.g.
[remote here]
url = .
is a special case of local repository that is named with a relative
filesystem path.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
--
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Hi, Philip Oakley wrote: The Git cli will generally accept dot '.' (period) as equivalent to the current repository when appropriate. Tell the reader of this 'do what I mean' (dwim)mery action. [...] --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_ see `hello.c` in your working tree with the former, but with the latter you will. +Just as, by convention, the filesystem '.' refers to the current directory, +using a '.' (period) as a repository name in Git (a dot-repository) refers +to your local repository. Good idea, but I fear that no one would find it there. Would it make sense to put this in Documentation/urls.txt (aka the GIT URLS section of git-fetch(1) and git-clone(1)), where other URL schemes are documented? Thanks, Jonathan -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Jonathan Nieder jrnie...@gmail.com Sent: Sunday, May 19, 2013 6:39 PM Hi, Philip Oakley wrote: The Git cli will generally accept dot '.' (period) as equivalent to the current repository when appropriate. Tell the reader of this 'do what I mean' (dwim)mery action. [...] --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_ see `hello.c` in your working tree with the former, but with the latter you will. +Just as, by convention, the filesystem '.' refers to the current directory, +using a '.' (period) as a repository name in Git (a dot-repository) refers +to your local repository. Good idea, but I fear that no one would find it there. Would it make sense to put this in Documentation/urls.txt (aka the GIT URLS section of git-fetch(1) and git-clone(1)), where other URL schemes are documented? Thanks, Jonathan Sounds an interesting idea. I'll have a look. 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
