From: Nicolas Vilz 'niv' <hidden> Date: 2016-06-15 22:42:20
hi everyone,
as i mentioned, i do experimental work with git and svn... and i
experienced some problems with git when pulling much data from svn.
Actually that happens after i commit a revision with many and big files.
After that i cannot do a git-svn fetch anymore because git-svn
complains...
fatal: Ref refs/heads/svn-git-HEAD is at
504721bf4b2702d3e56cef69950f42a43568e846 but expected
504721bf4b2702d3e56cef69950f42a43568e846
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
now i am still on rev 2 on this branch but i updated it to rev 5 on the
svn-side...
any hints?
Sincerly
Nicolas
From: Eric Wong <hidden> Date: 2016-06-15 22:42:20
Nicolas Vilz 'niv' [off-list ref] wrote:
hi everyone,
as i mentioned, i do experimental work with git and svn... and i
experienced some problems with git when pulling much data from svn.
Actually that happens after i commit a revision with many and big files.
After that i cannot do a git-svn fetch anymore because git-svn
complains...
fatal: Ref refs/heads/svn-git-HEAD is at
504721bf4b2702d3e56cef69950f42a43568e846 but expected
504721bf4b2702d3e56cef69950f42a43568e846
Those messages are from git-update-ref. What were some of the messages
from git-svn leading up to that point?
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
You should never, ever modify the git-svn-HEAD branch yourself.
Interface branches should never be modified. It's the golden rule of
interfacing between different SCM interfaces. Sorry, I've been doing
things like this this for a while now I guess I didn't make it
abundantly clear in the documentation.
now i am still on rev 2 on this branch but i updated it to rev 5 on the
svn-side...
any hints?
Save your current work in git-svn-HEAD to a private branch
git branch -b private git-svn-HEAD
then reset git-svn-HEAD to the last revision where it was managed by
git-svn fetch:
git-checkout git-svn-HEAD
git-log (look for the last commit with 'git-svn-id:' in it)
git-reset --hard <last commit with 'git-svn-id:' in it>
Now go to your private branch:
git checkout private
And continue working on your private branch as usual.
--
Eric Wong
From: Jan Harkes <jaharkes@cs.cmu.edu> Date: 2016-06-15 22:42:20
On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
quoted
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
You should never, ever modify the git-svn-HEAD branch yourself.
Interface branches should never be modified. It's the golden rule of
interfacing between different SCM interfaces. Sorry, I've been doing
things like this this for a while now I guess I didn't make it
abundantly clear in the documentation.
If it is not supposed to be changed by the user, maybe it could be
stored as a tag.
Or maybe another type of reference can be introduced. refs/remote/, for
branches we are tracking, but which should not be modified locally.
Jan
From: Eric Wong <hidden> Date: 2016-06-15 22:42:20
As a rule, interface branches to different SCMs should never be modified
directly by the user. They are used exclusively for talking to the
foreign SCM.
Signed-off-by: Eric Wong <redacted>
---
contrib/git-svn/git-svn.txt | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
4676a850ad5a9e4a88fa5dfba1ac231a58bffda1
@@ -43,6 +43,11 @@ fetch:: Fetch unfetched revisions from the SVN_URL we are tracking. refs/heads/git-svn-HEAD will be updated to the latest revision.+ Note: You should never attempt to modify the git-svn-HEAD branch+ outside of git-svn. Instead, create a branch from git-svn-HEAD+ and work on that branch. Use the 'commit' command (see below)+ to write git commits back to git-svn-HEAD.+ commit:: Commit specified commit or tree objects to SVN. This relies on your imported fetch data being up-to-date. This makes
@@ -179,7 +184,9 @@ SVN repositories via one git repository. environment variable to a name other other than "git-svn" (the default) and git-svn will ignore the contents of the $GIT_DIR/git-svn directory and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that-invocation.+invocation. The interface branch will be $GIT_SVN_ID-HEAD, instead of+git-svn-HEAD. Any $GIT_SVN_ID-HEAD branch should never be modified+by the user outside of git-svn commands. ADDITIONAL FETCH ARGUMENTS --------------------------
From: Eric Wong <hidden> Date: 2016-06-15 22:42:20
Jan Harkes [off-list ref] wrote:
On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
quoted
quoted
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
You should never, ever modify the git-svn-HEAD branch yourself.
Interface branches should never be modified. It's the golden rule of
interfacing between different SCM interfaces. Sorry, I've been doing
things like this this for a while now I guess I didn't make it
abundantly clear in the documentation.
If it is not supposed to be changed by the user, maybe it could be
stored as a tag.
Or maybe another type of reference can be introduced. refs/remote/, for
branches we are tracking, but which should not be modified locally.
Either of those could work for me. Changing git-svn-HEAD to become a
tag would probably be easier (not having to update other tools, such as
git-fetch), but refs/remote may make more sense.
--
Eric Wong
From: Nicolas Vilz 'niv' <hidden> Date: 2016-06-15 22:42:20
Nicolas Vilz 'niv' [off-list ref] wrote:
quoted
hi everyone,
as i mentioned, i do experimental work with git and svn... and i
experienced some problems with git when pulling much data from svn.
Actually that happens after i commit a revision with many and big files.
After that i cannot do a git-svn fetch anymore because git-svn
complains...
fatal: Ref refs/heads/svn-git-HEAD is at
504721bf4b2702d3e56cef69950f42a43568e846 but expected
504721bf4b2702d3e56cef69950f42a43568e846
Those messages are from git-update-ref. What were some of the messages
from git-svn leading up to that point?
quoted
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
You should never, ever modify the git-svn-HEAD branch yourself.
Interface branches should never be modified. It's the golden rule of
interfacing between different SCM interfaces. Sorry, I've been doing
things like this this for a while now I guess I didn't make it
abundantly clear in the documentation.
ok, i experienced that on little modifications on the git-svn-HEAD branch
either... so its really about modifying and not about the huge data
ammount...
quoted
now i am still on rev 2 on this branch but i updated it to rev 5 on the
svn-side...
any hints?
Save your current work in git-svn-HEAD to a private branch
git branch -b private git-svn-HEAD
then reset git-svn-HEAD to the last revision where it was managed by
git-svn fetch:
git-checkout git-svn-HEAD
git-log (look for the last commit with 'git-svn-id:' in it)
git-reset --hard <last commit with 'git-svn-id:' in it>
Now go to your private branch:
git checkout private
And continue working on your private branch as usual.
I will keep that in mind for the future. Fortunatelly i am still testing
and i saved the git repository before experimenting with git-svn.
Have you any suggestions howto migrate a git-repository to svn and then
work with git-svn on both of it? I tried cg-merge -j to merge my git
branch with the private git svn branch, i am allowed to modify safely.
that does work actually... now i can start getting this automated.
perhaps i will write a patch with that automated script, when it is
finished, just to contribute git.
Sincerly
Nicolas
From: Eric Wong <hidden> Date: 2016-06-15 22:42:20
Nicolas Vilz 'niv' [off-list ref] wrote:
ok, i experienced that on little modifications on the git-svn-HEAD branch
either... so its really about modifying and not about the huge data
ammount...
Huge data should not have anything to do with it. Well, besides
increasing the chance of somebody committing a conflicting commit while
you're in the middle of your commit. But hey, that's the nature of
centralized SCMs.
quoted
quoted
now i am still on rev 2 on this branch but i updated it to rev 5 on the
svn-side...
any hints?
Save your current work in git-svn-HEAD to a private branch
git branch -b private git-svn-HEAD
then reset git-svn-HEAD to the last revision where it was managed by
git-svn fetch:
git-checkout git-svn-HEAD
git-log (look for the last commit with 'git-svn-id:' in it)
git-reset --hard <last commit with 'git-svn-id:' in it>
Now go to your private branch:
git checkout private
And continue working on your private branch as usual.
I will keep that in mind for the future. Fortunatelly i am still testing
and i saved the git repository before experimenting with git-svn.
:)
Have you any suggestions howto migrate a git-repository to svn and then
work with git-svn on both of it? I tried cg-merge -j to merge my git
branch with the private git svn branch, i am allowed to modify safely.
that does work actually... now i can start getting this automated.
perhaps i will write a patch with that automated script, when it is
finished, just to contribute git.
Cool. I don't know much about cg-*, but I think I did more or less the
same thing (joining branches, but did the join on git-svn-HEAD instead
of a git-only branch) using <revision>=<commit> arguments[1] to git-svn
fetch.
[1] - See the 'Additional Fetch Arguments' section of the manpage for
more info on this. I'll freely admit that the UI for this was an
accident, but it works fairly well for me.
--
Eric Wong
From: Nicolas Vilz 'niv' <hidden> Date: 2016-06-15 22:42:20
Eric Wong wrote:
[1] - See the 'Additional Fetch Arguments' section of the manpage for
more info on this. I'll freely admit that the UI for this was an
accident, but it works fairly well for me.
btw, i think you have a typo in your man-page:
---
# Commit only the git commits you want to SVN::
git-svn commit <tree-ish> [<tree-ish_2> ...]
# Commit all the git commits from my-branch that don't exist in SVN::
git commit git-svn-HEAD..my-branch
---
i think the second one is intended to be "git-svn commit
git-svn-HEAD..my-branch", because you want to sync the SVN tree again, not
another git-tree i think...
Nicolas
@@ -159,7 +159,7 @@ Tracking and contributing to an Subversi # Commit only the git commits you want to SVN:: git-svn commit <tree-ish> [<tree-ish_2> ...] # Commit all the git commits from my-branch that don't exist in SVN::- git commit git-svn-HEAD..my-branch+ git-svn commit git-svn-HEAD..my-branch # Something is committed to SVN, pull the latest into your branch:: git-svn fetch && git pull . git-svn-HEAD # Append svn:ignore settings to the default git exclude file:
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:20
On 2/28/06, Eric Wong [off-list ref] wrote:
quoted
If it is not supposed to be changed by the user, maybe it could be
stored as a tag.
Or maybe another type of reference can be introduced. refs/remote/, for
branches we are tracking, but which should not be modified locally.
Either of those could work for me. Changing git-svn-HEAD to become a
tag would probably be easier (not having to update other tools, such as
git-fetch), but refs/remote may make more sense.
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
Something else is needed -- a convention to mark a head as 'readonly'
so that git-commit/cg-commit refuse to commit to it. cg-commit already
does that for any head matching the name of a branch.
cheers,
martin
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
Well, I wouldn't say that tags are expected to stand still. Some kinds of
tags are expected to move: a "this is the last tested version" tag would
be expected to move with testing.
That said, the movement is _different_ from a branch. A branch is expected
to move _with_ development, while a tag is expected to either stay the
same, or move _after_ development.
However, in many ways git really doesn't care much. The "refs/heads"
directory is the only one that is really special, in that "git checkout"
refuses to check out a moving branch in anything but that subdirectory.
The "tags" subdirectory is slightly special to some helpers (like "git
pull"), which have flags to pull everythying in that subdirectory.
But other than those two pretty trivial issues, any ref under "refs/"
should work perfectly fine. I would argue that a specialized tracking tool
might well be better off without using either "refs/heads" _or_
"refs/tags", since those have accepted meaning outside of tracking.
Using a "refs/remotes" subdirectory makes tons of sense for something like
this. Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
Linus
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:20
On 2/28/06, Linus Torvalds [off-list ref] wrote:
On Tue, 28 Feb 2006, Martin Langhoff wrote:
quoted
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
Well, I wouldn't say that tags are expected to stand still. Some kinds of
tags are expected to move: a "this is the last tested version" tag would
be expected to move with testing.
Alrighty... in my git projects where things like these matter, my
"latest tested" and "current in production" refs are actually in
refs/heads.
That said, the movement is _different_ from a branch. A branch is expected
to move _with_ development, while a tag is expected to either stay the
same, or move _after_ development.
Grumble. I'd say a head is expected to reliably move _forward_...
"with" development, yes, but definitely forward. In my book a tag
wouldn't move, but if I take your word for it, then a tag can perhaps
change arbitrarily?
I'm not sure how much support we have in porcelains for "tracking" a
tag if it starts changing. Right now I think we'd find all sorts of
problems, we'd need to think carefully what moving tags means for
porcelains.
Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
I think the moving-forward (therefore is trackable) vs stays reliably
in place distinction *is* useful. "Moves randomly" may also be useful,
but it should get a different treatment, because it's not "trackable".
Not that git and porcelains can't deal with all this stuff. But if
there is a clear convention then porcelains can be smart and refuse to
commit to the wrong place... it'd be a bit of a UI enhancement
perhaps?
martin
From: Eric Wong <hidden> Date: 2016-06-15 22:42:20
Linus Torvalds [off-list ref] wrote:
On Tue, 28 Feb 2006, Martin Langhoff wrote:
quoted
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
<snipped>
Using a "refs/remotes" subdirectory makes tons of sense for something like
this. Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'
prefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get
specified from the command-line quite often:
git checkout -b mine git-svn-HEAD
git-log git-svn-HEAD..head
git-svn commit git-svn-HEAD..mine
git-log mine..git-svn-HEAD
Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?
--
Eric Wong
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:20
Eric Wong wrote:
Linus Torvalds [off-list ref] wrote:
quoted
On Tue, 28 Feb 2006, Martin Langhoff wrote:
quoted
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
<snipped>
Using a "refs/remotes" subdirectory makes tons of sense for something like
this. Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'
prefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get
specified from the command-line quite often:
git checkout -b mine git-svn-HEAD
git-log git-svn-HEAD..head
git-svn commit git-svn-HEAD..mine
git-log mine..git-svn-HEAD
Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?
It already does. The search order is this, for a ref named 'foo':
$GIT_DIR/foo
$GIT_DIR/refs/foo
$GIT_DIR/refs/tags/foo
$GIT_DIR/refs/heads/foo
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?
It already does. The search order is this, for a ref named 'foo':
$GIT_DIR/foo
$GIT_DIR/refs/foo
$GIT_DIR/refs/tags/foo
$GIT_DIR/refs/heads/foo
Yes, but I think Eric wanted to avoid having to write the prefix part,
which git won't let you do right now.
If you have a ref in .git/refs/svn-tracker/git-svn-HEAD, you would have to
write out all of "svn-tracker/git-svn-HEAD", because unlike a "real
branch", get_sha1() won't look into the "svn-tracker" without it being
explicitly mentioned.
Now, some tools will actually do "for_each_ref()" and check the ref-name
against each of them (so if you pass in "foo", it will check them afainst
_any_ ref-subdirectory that contains "foo"). But get_sha1() won't.
We could fix get_sha1(), but part of the logic was that other
subdirectories are special, and as such they _should_ be mentioned, so
that a file in such a special directory isn't ever confused with a real
branch.
But if you were to use for example .git/refs/git-svn/tracking as the
svn-tracking reference head, and then you'd be perfectly able to use
git log git-svn/tracking..
to see what you've done since the last svn import?
(or use HEAD, if you prefer that over "tracking")
Linus
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:20
Linus Torvalds wrote:
On Wed, 1 Mar 2006, Andreas Ericsson wrote:
quoted
Eric Wong wrote:
quoted
Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?
It already does. The search order is this, for a ref named 'foo':
$GIT_DIR/foo
$GIT_DIR/refs/foo
$GIT_DIR/refs/tags/foo
$GIT_DIR/refs/heads/foo
Yes, but I think Eric wanted to avoid having to write the prefix part,
which git won't let you do right now.
If you have a ref in .git/refs/svn-tracker/git-svn-HEAD, you would have to
write out all of "svn-tracker/git-svn-HEAD", because unlike a "real
branch", get_sha1() won't look into the "svn-tracker" without it being
explicitly mentioned.
Now, some tools will actually do "for_each_ref()" and check the ref-name
against each of them (so if you pass in "foo", it will check them afainst
_any_ ref-subdirectory that contains "foo"). But get_sha1() won't.
Didn't know that. The day is not a complete waste then.
We could fix get_sha1(), but part of the logic was that other
subdirectories are special, and as such they _should_ be mentioned, so
that a file in such a special directory isn't ever confused with a real
branch.
But if you were to use for example .git/refs/git-svn/tracking as the
svn-tracking reference head, and then you'd be perfectly able to use
git log git-svn/tracking..
to see what you've done since the last svn import?
Personally I'm all for namespace separation. I'm assuming the script has
the tracker-branch hardcoded anyway, so I don't really understand why it
would be necessary to keep other refs in a separate directory and, if it
*is* necessary, why that subdirectory can't be .git/refs/heads/svn.
Eric mentioned earlier that the tracking-branch can't be committed to
(ever), so the user convenience for searching other directories should
be nearly non-existant.
Perhaps I'm missing something obvious. Perhaps I'm just stupid. Perhaps
the pub just opened and I don't feel like reading it twice to make sure
I understood. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Personally I'm all for namespace separation. I'm assuming the script has the
tracker-branch hardcoded anyway, so I don't really understand why it would be
necessary to keep other refs in a separate directory and, if it *is*
necessary, why that subdirectory can't be .git/refs/heads/svn.
Eric mentioned earlier that the tracking-branch can't be committed to (ever),
so the user convenience for searching other directories should be nearly
non-existant.
The thing about it being .git/refs/heads/svn/xyzzy is that then you can do
git checkout svn/xyzzy
and start modifying it. Which is exactly against the point: the thing is
_not_ a branch and you must _not_ commit to it.
It's much more like a tag: it's a pointer to the last point of an
svn-import.
So I think it should either _be_ a tag (although Dscho worries about some
broken porcelain being confused by tags changing) or it should be in a
namespace all it's own. Not under .git/refs/heads/ at any point, because
it is _not_ a head of development.
Linus
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:42:20
On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:
The thing about it being .git/refs/heads/svn/xyzzy is that then you can do
git checkout svn/xyzzy
and start modifying it. Which is exactly against the point: the thing is
_not_ a branch and you must _not_ commit to it.
It's much more like a tag: it's a pointer to the last point of an
svn-import.
Isn't it the same with tracked branches of a remote git repo?
With this reasoning, all heads that git-clone clones aside from the
special "master" should not be under .git/refs/heads, but better
under .git/refs/remotes/<remoteRepoName>/ ?
<remoteRepoName> is "origin" in the case of git-clone, so .git/remotes/origin
would contain
URL: http://host/repo.git
Pull: master:remotes/origin/master
Then there would not be the need for the confusing special branch "origin"
after cloning, as namespaces are separate.
Josef
On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:
quoted
The thing about it being .git/refs/heads/svn/xyzzy is that then you can do
git checkout svn/xyzzy
and start modifying it. Which is exactly against the point: the thing is
_not_ a branch and you must _not_ commit to it.
It's much more like a tag: it's a pointer to the last point of an
svn-import.
Isn't it the same with tracked branches of a remote git repo?
With this reasoning, all heads that git-clone clones aside from the
special "master" should not be under .git/refs/heads, but better
under .git/refs/remotes/<remoteRepoName>/ ?
<remoteRepoName> is "origin" in the case of git-clone, so .git/remotes/origin
would contain
URL: http://host/repo.git
Pull: master:remotes/origin/master
Then there would not be the need for the confusing special branch "origin"
after cloning, as namespaces are separate.
This is a really good idea. It certainly would prevent polluting the
heads namespace. And its a lot easier to explain to someone than the
mapping in the Pull line usually is.
--
Shawn.
On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:
quoted
The thing about it being .git/refs/heads/svn/xyzzy is that then you can do
git checkout svn/xyzzy
and start modifying it. Which is exactly against the point: the thing is
_not_ a branch and you must _not_ commit to it.
It's much more like a tag: it's a pointer to the last point of an
svn-import.
Isn't it the same with tracked branches of a remote git repo?
With this reasoning, all heads that git-clone clones aside from the
special "master" should not be under .git/refs/heads, but better
under .git/refs/remotes/<remoteRepoName>/ ?
Yes, I think that would make tons of sense.
<remoteRepoName> is "origin" in the case of git-clone, so .git/remotes/origin
would contain
URL: http://host/repo.git
Pull: master:remotes/origin/master
Then there would not be the need for the confusing special branch "origin"
after cloning, as namespaces are separate.
I think that would make things a lot more flexible, and yes, it sounds
like a good idea.
HOWEVER.
I think it's not only very common, but quite useful, to do what we do now,
ie
git log origin..
to see "what is in origin but not in HEAD".
So there's a big usability issue: I don't think it's good to have to say
git log remotes/origin/master..
to do the same.
So from a usability standpoint, we'd have to teach "get_sha1()" about
parsing .git/remotes/* files if it cannot find a branch or a tag with that
name (which it wouldn't be able to, since even if it were to walk the
directories udner .git/refs/ recursively, it would be named "master"
there).
But if somebody does the get_sha1() magic, and Junio agrees, then I think
it would be a great thing to do.
Linus
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:42:20
On Wednesday 01 March 2006 18:40, Linus Torvalds wrote:
But if somebody does the get_sha1() magic, and Junio agrees, then I think
it would be a great thing to do.
Yes.
git log origin/master..
is really not that bad. And if somebody complains about typing, git-clone
could get an option "--remote-name=o" to allow for
git log o/master..
Josef
On Wednesday 01 March 2006 18:40, Linus Torvalds wrote:
quoted
But if somebody does the get_sha1() magic, and Junio agrees, then I think
it would be a great thing to do.
Yes.
git log origin/master..
is really not that bad
It really is.
Think like a user. If I pull from "origin", then the name of that thing is
"origin", not "origin/master" or "o/master". A user doesn't care what the
remote branch name is - the whole _point_ of the .git/remotes/xyzzy file
is to give a short description that includes the names of the branches you
pull from.
The good news is that "get_sha1()" shouldn't be that hard to extend on.
Just add a case at the end that says "do we have a .git/remotes/%s file,
and if so, parse it".
Linus
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:42:20
On Wednesday 01 March 2006 19:25, Linus Torvalds wrote:
quoted
git log origin/master..
is really not that bad
It really is.
Think like a user. If I pull from "origin", then the name of that thing is
"origin", not "origin/master" or "o/master". A user doesn't care what the
remote branch name is - the whole _point_ of the .git/remotes/xyzzy file
is to give a short description that includes the names of the branches you
pull from.
So the get_sha1() magic should map "origin" to "remote/origin/master" (or instead
hardcoded master the remote branch from the first "Pull:" line) ?
The ambiguity here would be that shortcut names of remote repositories should not be
used as tag or head names...
I think a big plus of this would be that gitk can show branches tracking remote ones
with another color.
The good news is that "get_sha1()" shouldn't be thse at hard to extend on.
Just add a case at the end that says "do we have a .git/remotes/%s file,
and if so, parse it".
To be able to say "git log origin.." you need the above magic, too.
Josef
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:20
Hi,
On Wed, 1 Mar 2006, Linus Torvalds wrote:
On Wed, 1 Mar 2006, Andreas Ericsson wrote:
quoted
Personally I'm all for namespace separation. I'm assuming the script
has the tracker-branch hardcoded anyway, so I don't really understand
why it would be necessary to keep other refs in a separate directory
and, if it *is* necessary, why that subdirectory can't be
.git/refs/heads/svn.
Eric mentioned earlier that the tracking-branch can't be committed to
(ever), so the user convenience for searching other directories should
be nearly non-existant.
The thing about it being .git/refs/heads/svn/xyzzy is that then you can
do
git checkout svn/xyzzy
_not_ a branch and you must _not_ commit to it.
It's much more like a tag: it's a pointer to the last point of an
svn-import.
So I think it should either _be_ a tag (although Dscho worries about some
broken porcelain being confused by tags changing) or it should be in a
namespace all it's own. Not under .git/refs/heads/ at any point, because
it is _not_ a head of development.
I almost missed that you reference me in the email (often, I just delete
the email if the Subject is of no interest to me).
I did not worry about broken porcelain. I saw broken porcelain. But that
is more a broken concept than broken porcelain: in a distributed
environment, there is no way to have a reliable tag. Think about it:
whenever you have two different versions of a tag, you cannot know which
one is the correct one.
But my worries do not matter at all for local tags.
Conceptually, however, the last point of a svnimport should *never* be a
tag, but *always* a head.
Ciao,
Dscho
So the get_sha1() magic should map "origin" to "remote/origin/master" (or instead
hardcoded master the remote branch from the first "Pull:" line) ?
Right.
The ambiguity here would be that shortcut names of remote repositories should not be
used as tag or head names...
Well, it's not so much an ambiguity, since we'd always try tags and heads
first. So it's just a fallback, the same way the short SHA1 hash is a
fallback.
I think a big plus of this would be that gitk can show branches tracking remote ones
with another color.
Yes. And with a meaningful name.
To be able to say "git log origin.." you need the above magic, too.
It would all come automagically from just extending get_sha1().
(Actually, technically you'd put it at the end of "get_sha1_basic()")
Linus
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:21
Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter
where Andreas Ericsson [off-list ref] said that...
It already does. The search order is this, for a ref named 'foo':
$GIT_DIR/foo
$GIT_DIR/refs/foo
$GIT_DIR/refs/tags/foo
$GIT_DIR/refs/heads/foo
Actually, I've hit this recently when supporting an unhappy user on
#git, and I didn't manage to find anything in the archives (but perhaps
I missed it). Is there a particular reason why tags are checked first
than branches?
Why not:
(i) I _think_ that it would be less of a surprise if a branch would be
checked first.
(ii) E.g. Cogito output (cg-status -g) is very confusing when you have a
naming clash - cg-object-id foo will show tag commit ID, but cg-status -g
will say that the "foo" branch has a different commit ID (and it is
_right_).
(iii) Many operations will stop making sense (cg-merge foo, and even
cg-fetch foo will be confused), while in case of the opposite way I can't
think of any command still not making sense.
(iv) A security hole when you auto-fetch tags from remote repositories
- you could then be misled to merge something totally different when the
attacker will introduce a naming clash to your refs hierarchy.
Actually, I'm almost inclined to suggest making Git fail violently in
case of an ambiguous name.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.