From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:23
"Philip Oakley" [off-list ref] writes:
From: "Junio C Hamano" <redacted>
Sent: Monday, May 20, 2013 11:22 PM
quoted
"Philip Oakley" [off-list ref] writes:
quoted
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.
quoted
"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.
quoted
quoted
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 [off-list ref]
wrote:
quoted
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
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:24
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano [off-list ref] wrote:
"Philip Oakley" [off-list ref] writes:
quoted
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder [off-list ref]
wrote:
quoted
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.
quoted
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.
--
Felipe Contreras
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano [off-list ref]
wrote:
quoted
"Philip Oakley" [off-list ref] writes:
quoted
quoted
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder [off-list ref]
wrote:
quoted
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.
quoted
quoted
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.
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano [off-list ref]
wrote:
quoted
"Philip Oakley" [off-list ref] writes:
quoted
quoted
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder [off-list ref]
wrote:
quoted
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.
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.
quoted
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 .
* branch master -> 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
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano [off-list ref]
wrote:
quoted
"Philip Oakley" [off-list ref] writes:
quoted
quoted
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
[off-list ref]
wrote:
quoted
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.
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.
quoted
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.
quoted
quoted
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.
quoted
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 .
* branch master -> 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 majordomo@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
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