Marcin Owsiany [off-list ref] writes:
quoted hunk
diff --git a/git-svn.perl b/git-svn.perl
index 0b074c4..2379a71 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1612,9 +1612,9 @@ sub post_fetch_checkout {
}
}
- my $valid_head = verify_ref('HEAD^0');
+ return if verify_ref('HEAD^0');
command_noisy(qw(update-ref refs/heads/master), $gs->refname);
Given that your original motivation was "I do not want master, I am
using something else for my primary branch", I change that still
shows "update-ref refs/heads/master" smells like sweeping something
under the rug (i.e. repeated "oh, running this verison still fails
here, so I'll patch it up" hackery without a solid grand design).
- return if ($valid_head || !verify_ref('HEAD^0'));
+ return unless verify_ref('HEAD^0');
return if $ENV{GIT_DIR} !~ m#^(?:.*/)?\.git$#;
my $index = $ENV{GIT_INDEX_FILE} || "$ENV{GIT_DIR}/index";
--
1.7.7.3
On Tue, Jun 26, 2012 at 03:03:07PM -0700, Junio C Hamano wrote:
Marcin Owsiany [off-list ref] writes:
quoted
diff --git a/git-svn.perl b/git-svn.perl
index 0b074c4..2379a71 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1612,9 +1612,9 @@ sub post_fetch_checkout {
}
}
- my $valid_head = verify_ref('HEAD^0');
+ return if verify_ref('HEAD^0');
command_noisy(qw(update-ref refs/heads/master), $gs->refname);
Given that your original motivation was "I do not want master, I am
using something else for my primary branch", I change that still
shows "update-ref refs/heads/master" smells like sweeping something
under the rug
I'm not so sure... With this change, git-svn will only create master on
the initial "clone" and I think that's fine. It's consistent with what
"git clone" does when cloning a regular git repository.
It seems that I have slightly misinterpreted git-svn's actions in my
initial post in 2009. I thought it always updated "master" to the
most recent upstream commit. In reality it only every _creates_ it at
the most recent commit. But never fast-forwards it if it pre-exists.
This makes my idea to do the same to "my something else instead of
master" much less attractive. In fact I don't think such behaviour would
be useful.
I think with the suggested patch git-svn works as I would like it to:
- creates "master" at initial checkout - consistent with git clone
- using a different "tracking-like" branch is possible with "dcommit"
- does not re-create "master" on fetch - so the annoying part is gone
--
Marcin Owsiany [off-list ref] http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC
"Every program in development at MIT expands until it can read mail."
-- Unknown
On Tue, Jun 26, 2012 at 11:32:15PM +0100, Marcin Owsiany wrote:
On Tue, Jun 26, 2012 at 03:03:07PM -0700, Junio C Hamano wrote:
quoted
Marcin Owsiany [off-list ref] writes:
quoted
diff --git a/git-svn.perl b/git-svn.perl
index 0b074c4..2379a71 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1612,9 +1612,9 @@ sub post_fetch_checkout {
}
}
- my $valid_head = verify_ref('HEAD^0');
+ return if verify_ref('HEAD^0');
command_noisy(qw(update-ref refs/heads/master), $gs->refname);
Given that your original motivation was "I do not want master, I am
using something else for my primary branch", I change that still
shows "update-ref refs/heads/master" smells like sweeping something
under the rug
I'm not so sure... With this change, git-svn will only create master on
the initial "clone" and I think that's fine. It's consistent with what
"git clone" does when cloning a regular git repository.
It seems that I have slightly misinterpreted git-svn's actions in my
initial post in 2009. I thought it always updated "master" to the
most recent upstream commit. In reality it only every _creates_ it at
the most recent commit. But never fast-forwards it if it pre-exists.
This makes my idea to do the same to "my something else instead of
master" much less attractive. In fact I don't think such behaviour would
be useful.
I think with the suggested patch git-svn works as I would like it to:
- creates "master" at initial checkout - consistent with git clone
- using a different "tracking-like" branch is possible with "dcommit"
- does not re-create "master" on fetch - so the annoying part is gone
Any comments?
--
Marcin Owsiany [off-list ref] http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC
"Every program in development at MIT expands until it can read mail."
-- Unknown