* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Shawn Pearce @ 2006-02-27 22:26 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselstr?m <kha@treskal.com> wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
>
> Suppose a line contained the string "0". Patch p1 changes that to "1",
> patch p2 further changes that to "2". Upstream accept the patches, and
> I later "stg pull" them. When reapplying p1 after the pull, stg
> generates a merge conflict since upstream changed the "0" to "2" and
> p1 changes the "0" to "1".
You should look at pg:
http://www.spearce.org/2006/02/pg-version-0111-released.html
It has some of the features of StGIT and it (at least partially)
solves this problem.
Assume you had a patch stack of:
PatchA : Change 0 to a 1
PatchB : Change 1 to a 2
PatchC : Change 2 to a 3
with each affecting the same line of the same file.
When pg grabs its (possibly remote) parent ("stg pull" aka pg-rebase)
we try to push down PatchA. If PatchA fails to push cleanly we'll
pop it off and try to push PatchA + PatchB. If that pushes cleanly
then we fold the content of PatchA into PatchB, effectively making
PatchA part of PatchB. If PatchA + PatchB failed to push down
cleanly then we pop both and retry pushing PatchA + PatchB + PatchC.
If that pushes down cleanly then we make PatchA and PatchB officially
part of PatchC.
This required some ``hacks'' in pg-push. Basically if we are
doing a non-fastforward push (as there are new commits we must
merge on top of) we run an external diff/patch to apply the change.
If that fails we reset the tree back to a clean state and try again.
Whenever patch rejects a hunk we examine the hunk to see if it is
already applied to the target file; if it is already applied we
skip the hunk. If all hunks applied cleanly and/or are already
applied we accept the patch (or combination of patches) as merging
cleanly. Yea, its not very pretty. But it works!
Where it falls down is if the upstream accepts all three of your
patches but then changes the line from a 3 to a 4. pg won't look
at the GIT commit history to detect that the upstream accepted your
final change (PatchC) but then overwrite it with a newer change
(3->4). I have thought about trying to implement this but the
current environment where I am using pg wouldn't benefit from it,
so it has not been high on my priority list.
--
Shawn.
^ permalink raw reply
* [PATCH 2/2] Save username -> Full Name <email@addr.es> map file
From: Karl Hasselström @ 2006-02-27 23:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <440195D4.7080905@op5.se>
When the user specifies a username -> Full Name <email@addr.es> map
file with the -A option, save a copy of that file as
$git_dir/svn-authors. When running git-svnimport with an existing GIT
directory, use $git_dir/svn-authors (if it exists) unless a file was
explicitly specified with -A.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 5 +++++
git-svnimport.perl | 25 ++++++++++++++++++++-----
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 912a808..a158813 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -82,6 +82,11 @@ When importing incrementally, you might
"username". If encountering a commit made by a user not in the
list, abort.
+ For convenience, this data is saved to $GIT_DIR/svn-authors
+ each time the -A option is provided, and read from that same
+ file each time git-svnimport is run with an existing GIT
+ repository without -A.
+
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 86837ed..639aa41 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -13,6 +13,7 @@
use strict;
use warnings;
use Getopt::Std;
+use File::Copy;
use File::Spec;
use File::Temp qw(tempfile);
use File::Path qw(mkpath);
@@ -68,10 +69,16 @@ if ($opt_M) {
push (@mergerx, qr/$opt_M/);
}
+# Absolutize filename now, since we will have chdir'ed by the time we
+# get around to opening it.
+$opt_A = File::Spec->rel2abs($opt_A) if $opt_A;
+
our %users = ();
-if ($opt_A) {
- die "Cannot open $opt_A\n" unless -f $opt_A;
- open(my $authors,$opt_A);
+our $users_file = undef;
+sub read_users($) {
+ $users_file = File::Spec->rel2abs(@_);
+ die "Cannot open $users_file\n" unless -f $users_file;
+ open(my $authors,$users_file);
while(<$authors>) {
chomp;
next unless /^(\S+?)\s*=\s*(.+?)\s*<(.+)>\s*$/;
@@ -302,6 +309,14 @@ EOM
-d $git_dir
or die "Could not create git subdir ($git_dir).\n";
+my $default_authors = "$git_dir/svn-authors";
+if ($opt_A) {
+ read_users($opt_A);
+ copy($opt_A,$default_authors) or die "Copy failed: $!";
+} else {
+ read_users($default_authors) if -f $default_authors;
+}
+
open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$$) {
@@ -498,8 +513,8 @@ sub commit {
if (not defined $author) {
$author_name = $author_email = "unknown";
- } elsif ($opt_A) {
- die "User $author is not listed in $opt_A\n"
+ } elsif (defined $users_file) {
+ die "User $author is not listed in $users_file\n"
unless exists $users{$author};
($author_name,$author_email) = @{$users{$author}};
} elsif ($author =~ /^(.*?)\s+<(.*)>$/) {
^ permalink raw reply related
* [PATCH 1/2] Let git-svnimport's author file use same syntax as git-cvsimport's
From: Karl Hasselström @ 2006-02-27 23:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <440195D4.7080905@op5.se>
git-cvsimport uses a username => Full Name <email@addr.es> mapping
file with this syntax:
kha=Karl Hasselström <kha@treskal.com>
Since there is no reason to use another format for git-svnimport, use
the same format.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 4 ++--
git-svnimport.perl | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index e0e3a5d..912a808 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -75,9 +75,9 @@ When importing incrementally, you might
-A <author_file>::
Read a file with lines on the form
- username User's Full Name <email@addres.org>
+ username = User's Full Name <email@addr.es>
- and use "User's Full Name <email@addres.org>" as the GIT
+ and use "User's Full Name <email@addr.es>" as the GIT
author and committer for Subversion commits made by
"username". If encountering a commit made by a user not in the
list, abort.
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 75ce8e0..86837ed 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -74,7 +74,7 @@ if ($opt_A) {
open(my $authors,$opt_A);
while(<$authors>) {
chomp;
- next unless /^(\S+)\s+(.+?)\s+<(\S+)>$/;
+ next unless /^(\S+?)\s*=\s*(.+?)\s*<(.+)>\s*$/;
(my $user,my $name,my $email) = ($1,$2,$3);
$users{$user} = [$name,$email];
}
^ permalink raw reply related
* Re: [PATCH 4/4] Read author names and emails from a file
From: Karl Hasselström @ 2006-02-27 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vbqwt1h9r.fsf@assigned-by-dhcp.cox.net>
On 2006-02-26 21:51:12 -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > This is a good thing, but wouldn't it be better to use the same
> > format as that of cvsimport's -A flag?
>
> If both CVS and SVN have their own native format to express things
> like this, and if the format they use are different, then that is a
> valid reason for git-{cvs,svn}import to use different file format.
>
> But if that is not the case, I tend to agree that it might be easier
> for users if we had just one format. I do not think, however, any
> single project is likely to have to deal with both CVS and SVN
> upstream, importing into the same git repository, so reusing the
> mapping file would not be an issue, but having to learn how to write
> the mapping just once is a good thing.
>
> I do not offhand recall if SVN has its own native format; if it has,
> it may be better to use that, instead of matching what git-cvsimport
> does, since I do not think of a reason why the version with an equal
> sign is preferrable over the version with a space. If the version
> with '=' were the CVS native format then that might be a reason to
> prefer it, but if I recall correctly that is not the case. so...
I don't know of any SVN native format for this, so it seems silly to
use a different format than git-cvsimport. I've also made a patch that
saves the author information, again just like git-cvsimport.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-02-27 22:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
We discussed about this in the thread announcing pg
(http://article.gmane.org/gmane.comp.version-control.git/16247). This is
not easy to fix because StGIT pushes patches one by one and it stops at
the first conflict. Pg was trying to merge two patches at once but this
is not suitable for StGIT since the latter keeps the patches as single
commits.
There is another problem - the same line might have been modified by a
third-party patch merged into the kernel (and the conflict solved by the
maintainer).
> This situation arises for every line that's modified in more than one
> patch, and for every such patch except the last one. And it's really
> annoying, since it's intuitively obvious that there aren't actually
> any conflicts, since upstream accepted my patches verbatim.
Because I found the same situation a bit annoying, I added the --reset
option to resolved. If you know your patch was merged without
modifications, just use "stg resolved --all --reset local".
An idea (untested, I don't even know whether it's feasible) would be to
check which patches were merged by reverse-applying them starting with
the last. In this situation, all the merged patches should just revert
their changes. You only need to do a git-diff between the bottom and the
top of the patch and git-apply the output (maybe without even modifying
the tree). If this operation succeeds, the patch was integrated and you
don't even need to push it. The tool could even fold two consecutive
patches and reverse-apply them. The disadvantage might be the delay when
pushing patches but we could enable this test only if an option is
passed to the pull command.
If you really want to make StGIT behave intelligently, have a look at
the patch commuting theory in Darcs. It tends to handle this kind of
conflicts easily. StGIT also does some patch commuting but using the
diff3 algorithm and asks the user to fix different conflicts.
Catalin
^ permalink raw reply
* [PATCH] git pull cannot find remote refs.
From: Stefan-W. Hahn @ 2006-02-27 21:49 UTC (permalink / raw)
To: git
[PATCH] git pull cannot find remote refs.
When getting new data from an archive with 'git pull' I sometimes got the
message
fatal: unexpected EOF
Failed to find remote refs
Already up-to-date.
Tracking it down, I found a gap between how git-ls-remote prints out the tags
and git-fetch scans them with sed. Looking at the code of git-ls-remote the
there is an tab character between the sha1 and the refname, while there is a
space and a tab character in the regular expression for th sed command.
As a result the while where all is piped in cannot read the two values.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
---
I'm not sure if the solution is the best, because info sed say '\t' is not portable,
so perhaps it will be better to correct it another way?
Comments?
git-fetch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
92905634295ea29a59c773c634197cc029839883
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..c7b38b2 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -375,7 +375,7 @@ case "$no_tags$tags" in
# using local tracking branch.
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
- sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
+ sed -ne 's|^\([0-9a-f]*\)[\t]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
test -f "$GIT_DIR/$name" && continue
--
1.2.3.gc55f
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply related
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Sam Vilain @ 2006-02-27 21:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
>
> Suppose a line contained the string "0". Patch p1 changes that to "1",
> patch p2 further changes that to "2". Upstream accept the patches, and
> I later "stg pull" them. When reapplying p1 after the pull, stg
> generates a merge conflict since upstream changed the "0" to "2" and
> p1 changes the "0" to "1".
>
> This situation arises for every line that's modified in more than one
> patch, and for every such patch except the last one. And it's really
> annoying, since it's intuitively obvious that there aren't actually
> any conflicts, since upstream accepted my patches verbatim.
>
> I suppose one way to fix it manually would be to first fetch, glance
> at the new upstream commits and try to find any accepted patches, and
> then "stg pull" the commit corresponding to the earliest patch in my
> series; repeat for every patch in the series. The queston is, how can
> we automate it?
I don't seem to suffer from this, using my "diff3 ||
ediff-merge-files-with-ancestor" script as a merge tool. The diff3, or
ediff, seem to DTRT so long as the change is cleanly applied. Otherwise
I just get a merge conflict difference and I just press A/B to pick
which one I want.
Sam.
^ permalink raw reply
* [PATCH] contrib/git-svn: correct commit example in manpage
From: Eric Wong @ 2006-02-27 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git, Junio C Hamano
In-Reply-To: <62402.84.163.87.135.1141073234.squirrel@mail.geht-ab-wie-schnitzel.de>
Thanks to Nicolas Vilz <niv@iaglans.de> for noticing this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
125c2e90f26d8980f415f8066dcc84d02d95f03a
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index b588a2a..b290739 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -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:
--
1.2.3.g4676
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 20:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060227202713.GB21684@hand.yhbt.net>
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
^ permalink raw reply
* bug?: stgit creates (unneccessary?) conflicts when pulling
From: Karl Hasselström @ 2006-02-27 20:42 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
If I make a patch series where more than one patch touches the same
line, I get a lot of merge errors when upstream has accepted them and
I try to merge them back.
Suppose a line contained the string "0". Patch p1 changes that to "1",
patch p2 further changes that to "2". Upstream accept the patches, and
I later "stg pull" them. When reapplying p1 after the pull, stg
generates a merge conflict since upstream changed the "0" to "2" and
p1 changes the "0" to "1".
This situation arises for every line that's modified in more than one
patch, and for every such patch except the last one. And it's really
annoying, since it's intuitively obvious that there aren't actually
any conflicts, since upstream accepted my patches verbatim.
I suppose one way to fix it manually would be to first fetch, glance
at the new upstream commits and try to find any accepted patches, and
then "stg pull" the commit corresponding to the earliest patch in my
series; repeat for every patch in the series. The queston is, how can
we automate it?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 20:27 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <62354.84.163.87.135.1141068867.squirrel@mail.geht-ab-wie-schnitzel.de>
Nicolas Vilz 'niv' <niv@iaglans.de> 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.
> >> 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
^ permalink raw reply
* Re: [PATCH] gitweb: Enable tree (directory) history display
From: Linus Torvalds @ 2006-02-27 19:56 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060227185554.75822.qmail@web31810.mail.mud.yahoo.com>
On Mon, 27 Feb 2006, Luben Tuikov wrote:
>
> This patch allows history display of whole trees/directories,
> a la "git-rev-list HEAD <dir or file>", but somewhat
> slower, since exported git repository doesn't have
> the files checked out so we have to use
> "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'"
No no.
Just use
git-rev-list $hash -- $file_name
where the "--" is the important part.
As a usability-enhancer, you can leave out the "--" to separate filenames
and other things, but when you leave out the "--", git requires that the
filenames exist.
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 19:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
> Nicolas Vilz 'niv' <niv@iaglans.de> 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.
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...
>> 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
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060227185557.GA32142@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
> > > 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
^ permalink raw reply
* [PATCH] contrib/git-svn: tell the user to not modify git-svn-HEAD directly
From: Eric Wong @ 2006-02-27 19:04 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
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 <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.txt | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
4676a850ad5a9e4a88fa5dfba1ac231a58bffda1
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index b4b7789..b588a2a 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -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
--------------------------
--
1.2.3.gfc24dc-dirty
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Jan Harkes @ 2006-02-27 18:55 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
> > 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
^ permalink raw reply
* [PATCH] gitweb: Enable tree (directory) history display
From: Luben Tuikov @ 2006-02-27 18:55 UTC (permalink / raw)
To: git
Hi,
I find this patch very useful, especially when a directory (tree) describes
a project.
This patch allows history display of whole trees/directories,
a la "git-rev-list HEAD <dir or file>", but somewhat
slower, since exported git repository doesn't have
the files checked out so we have to use
"$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'"
method. Maybe someone can find a speed up for this. And better yet,
maybe links can be static as opposed to dynamic, so that you don't have to
navigate each and everytime if you want to find the history of the same
directory.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb.cgi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
5c8ae3db3561238a57201fcb3297f16d7b37f377
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..452528f 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1504,6 +1504,7 @@ sub git_tree {
"</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=tree;h=$t_hash$base_key;f=$base$t_name")}, "tree") .
+ " | " . $cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=history;h=$hash_base;f=$base$t_name")}, "history") .
"</td>\n";
}
print "</tr>\n";
--
1.2.3.g6db0
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 18:46 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <62502.84.163.87.135.1141063190.squirrel@mail.geht-ab-wie-schnitzel.de>
Nicolas Vilz 'niv' <niv@iaglans.de> 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
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Rutger Nijlunsing @ 2006-02-27 18:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Christopher Faylor, git
In-Reply-To: <4402C40D.2010805@op5.se>
On Mon, Feb 27, 2006 at 10:19:09AM +0100, Andreas Ericsson wrote:
> Rutger Nijlunsing wrote:
> >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
> >
> >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
> >>
> >>>filesystem is slow and locked down, and exec-attribute is NOT really
> >>>useful even on NTFS (it is somehow related to execute permission and
> >>>open files. I still cannot figure out how exactly are they related).
> >>
> >>Again, it's not clear if you're talking about Windows or Cygwin but
> >>under Cygwin, in the default configuration, the exec attribute means the
> >>same thing to cygwin as it does to linux.
> >
> >
> >I don't know about native Windows speed, but comparing NutCracker with
> >Cygwin on a simple 'find . | wc -l' already gives a clue that looking
> >at Cygwin to benchmark NT file inspection IO will give a skewed
> >picture:
> >
>
> Well, naturally. Cygwin is a userland implementation of a sane
> filesystem on top of a less sane one. File IO is bound to be slower when
> one FS is emulated on top of another. I think cygwin users are aware of
> this and simply accept the speed-for-sanity tradeoff. I know I would.
MKS NutCracker tries to solve the same issues as Cygwin tries to
solve. But maybe less sane, I don't know. But a simple 'find' is
several times faster than a Cygwin 'find'. Yes, very
unscientific. Just as unscientific as 'git is slow on Windows,
therefore Windows IO is slow'.
I'm not saying Cygwin is bad (actually, I'm installing on every
Windows PC I get my hand on ;), but using Cygwin for all file IO
instead of native Windows IO makes git a magnitude slower on Windows
than could-be. So a small portability layer with a function like
'given all filenames with all mtimes' might help, or we could look at
why Cygwin is slower in this case. Alas my Windows profiling skills
aren't that good...
Regards,
Rutger.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: cg-status and empty directories
From: Jim MacBaine @ 2006-02-27 18:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44031941.1020806@op5.se>
On 2/27/06, Andreas Ericsson <ae@op5.se> wrote:
> I'm afraid not.
>
> You should also note that git doesn't track permissions exactly. It just
> notices an execution bit and uses it to determine if it should write the
> working tree using (0666 ^ umask) or (0777 ^ umask). This makes it
> fairly unsuitable for /etc tracking unless you add some sort of
> permission restoring thing to it.
I'm aware of those limitations. It is not a backup mechanism at all
and permissions are handled by a small perl script.
However, I'm just curious to know, why cg-status suddenly started to
care about empty directories.
Regards,
Jim
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Christopher Faylor @ 2006-02-27 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060227183049.GA13195@nospam.com>
On Mon, Feb 27, 2006 at 07:30:49PM +0100, Rutger Nijlunsing wrote:
>However, the point I was trying to make was that git might be sped up
>by a magnitude (although not all of the magnitudes in comparison to
>Linux) by looking at why the file IO is this slow: Windows' file IO is
>_not_ the only reason. Using a different/new/better fitted interface
>to Cygwin or Win32 for a specific git task might help, although I have
>no clue what or how.
I'm going to revisit Cygwin's file I/O soon to see if I can figure out
what's adding the overhead and see if it really is inavoidable. It's
been a while since I've gone through that exercise so it should prove
instructive.
cgf
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Rutger Nijlunsing @ 2006-02-27 18:30 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060227011801.GB9264@trixie.casa.cgf.cx>
On Sun, Feb 26, 2006 at 08:18:01PM -0500, Christopher Faylor wrote:
> On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:
> >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
> >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
> >>>filesystem is slow and locked down, and exec-attribute is NOT really
> >>>useful even on NTFS (it is somehow related to execute permission and
> >>>open files. I still cannot figure out how exactly are they related).
> >>
> >>Again, it's not clear if you're talking about Windows or Cygwin but
> >>under Cygwin, in the default configuration, the exec attribute means
> >>the same thing to cygwin as it does to linux.
> >
> >I don't know about native Windows speed, but comparing NutCracker with
> >Cygwin on a simple 'find . | wc -l' already gives a clue that looking
> >at Cygwin to benchmark NT file inspection IO will give a skewed
> >picture:
> >
> >##### NutCracker $ time find . | wc -l
> >
> >real 0m 1.44s
> >user 0m 0.45s
> >sys 0m 0.98s
> >25794
> >
> >##### Cygwin $ time c:\\cygwin\\bin\\find . | wc -l
> >
> >real 0m 6.72s
> >user 0m 1.09s
> >sys 0m 5.59s
> >25794
> >
> >##### CMD.EXE + DIR /S C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s
> >>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata
> >6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps
> >
> >##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\PROJECT>
> >c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l 2.79user 7.81system
> >0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794
>
> I'm lost. What does this have to do with the exec attribute?
>
> Or, were you just climbing aboard the "Cygwin sure is slow" bandwagon?
I tried to get on the bandwagon 'NT file IO magnitudes slower => git
magnitudes slower', but missed the parade a week ago. Then another
parade showed up, but I managed to delete most of it with a
misfortunate shift-something in mutt... And then even messed up in
keeping the wrong paragraph... *hmpf*
However, the point I was trying to make was that git might be sped up
by a magnitude (although not all of the magnitudes in comparison to
Linux) by looking at why the file IO is this slow: Windows' file IO is
_not_ the only reason. Using a different/new/better fitted interface
to Cygwin or Win32 for a specific git task might help, although I have
no clue what or how.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 17:59 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 17:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Aubrey, git
In-Reply-To: <44033241.6070001@op5.se>
On Mon, 27 Feb 2006, Andreas Ericsson wrote:
>
> Did you by any chance do chmod -R, chown -R or start an ntp daemon somewhere
> in between there (don't know if clock skews will be detected by git, but...)?
off on this tangent: git shouldn't care about clock skew, because git
never cares about the current time. The only thing that matters is that
"stat()" returns the same time when called sequentially.
Now, if you have a distributed filesystem, and the _filesystem_ has some
strange clock-skew problem, that would definitely screw up git.
That sounds insane, but a trivial case of it might be a networked
filesystem where the mtime/ctime for a file create is filled in by the
client first, but then the server will do the "final version" when it
actually writes the file.
We used to have some bugs in our NFS client that did things like that: the
"mtime" of a file had this confusing duality between "client time" and
"server time", and it depended on whether the client had done a "getattr"
to the server which one you saw.
I could well imagine that we still have some bug like that (ctime in
particular is much less used than mtime, and thus more likely to have not
been noticed). And it could be much worse on some less-commonly-used and
less-unixy networked filesystem like smb, which is why I was wondering
what OS version and filesystem Aubrey might be using.
Linus
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 17:19 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>
On Tue, 28 Feb 2006, Aubrey wrote:
>
> =================================================================
> aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
> ----snip----
> diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
> diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h
Ok, this is _definitely_ your index being out of touch with your file
contents.
Run "git-update-index --refresh" and it should be ok.
Now the question is why the index got out-of-kilter with the file contents
in the first place. I used to have all these debug aids to show why git
thought a file had changed, but we've not had any bugs here for a long
long time, so..
The final checkout of the "git clone" should have made sure that the index
is up-to-date.
> > git clone remote-repo localdir
> > cd localdir
> > vi somefile
> > git diff
>
> Yes, exactly right.
>
> > then you did everything right, and if it gives any diff other than your
> > changes to "somefile", something is buggy. Need more info.
> >
> > Does "git diff" and "git diff HEAD" give different results, btw?
>
> Yes. the two commands give the same results.
>
> I'm using git-1.2.3
What OS/filesystem?
The way the index keeps track of files that haven't changed is by checking
the size, the mtime and the ctime of the inode. It also checks the
user/gid and inode number. If you use a filesystem where those might
change (networked?), that might cause this..
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox