Re: [PATCH] git svn fetch: Create correct commit timestamp when using --localtime
Junio C Hamano writes: > > Yep, seems alright. Can you apply directly? > > Been a bit preoccupied as of late. Thanks. > > Surely, I'll just add your Reviewed-by: myself ;-) OK, thanks. This will fix the bug I've reported here a week or so ago (see the References header). urs
[PATCH] git svn fetch: Create correct commit timestamp when using --localtime
In parse_svn_date() prepend the correct UTC offset to the timestamp
returned. This is the offset in effect at the commit time instead of
the offset in effect at calling time.
Signed-off-by: Urs Thuermann
---
perl/Git/SVN.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 98518f4..bc4eed3 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1416,7 +1416,7 @@ sub parse_svn_date {
delete $ENV{TZ};
}
- my $our_TZ = get_tz_offset();
+ my $our_TZ = get_tz_offset($epoch_in_UTC);
# This converts $epoch_in_UTC into our local timezone.
my ($sec, $min, $hour, $mday, $mon, $year,
--
2.1.4
Re: git svn fetch --localtime produces wrong commit times
Urs Thuermann writes: > I could find the bug grepping through /usr/lib/git-core/git-svn, maybe > it's in GIT::SVN::Fetcher or some other GIT::SVN module. Oops, that should be "could *not* find", of course. urs
git svn fetch --localtime produces wrong commit times
In converting a SVN repository to git, the commit timestamp is
generated incorrectly. I use "git svn fetch --localtime" and the
offset from UTC is always set to +0200 (probably because that is the
current local offset here, i.e. Europe/Berlin) even for times when it
should be +0100.
For example, in my SVN working copy I get
$ svn log -r152
r152 | urs | 2010-08-16 11:05:52 +0200 (Mon, 16 Aug 2010) | 2 lines
Add error checks on input file streams
$ svn log -r158
r158 | urs | 2010-11-24 00:24:13 +0100 (Wed, 24 Nov 2010) | 16 lines
Make code portable to Linux/amd64
After converting to git using
$ mkdir use
$ cd use
$ git svn init -s file://$HOME/SVN/use
Initialized empty Git repository in /home/urs/GIT/use/.git/
$ git svn fetch -q -A ../ADM/git.svn-authors --localtime
r1 = 12cb83315be96e594a98b42db7ae57d19e0c7973 (refs/remotes/origin/trunk)
...
r162 = 99ff393f1d64f330b14d6e06412b94fd3023d616 (refs/remotes/origin/trunk)
Checked out HEAD:
file:///home/urs/SVN/use/trunk r162
I see wrong commit timestamps:
$ git log
...
commit c6b4f7aaa66650a16de67d32fb83d541b1973331
Author: Urs Thuermann
Date: Wed Nov 24 00:24:13 2010 +0200
Make code portable to Linux/amd64
git-svn-id: file:///home/urs/SVN/use/trunk@158
b3714422-7cff-11dd-9a33-b89007e0d947
...
commit a9d95e506681ac5742d2d0927c93f22c541ff170
Author: Urs Thuermann
Date: Mon Aug 16 11:05:52 2010 +0200
Add error checks on input file streams
git-svn-id: file:///home/urs/SVN/use/trunk@152
b3714422-7cff-11dd-9a33-b89007e0d947
...
In revision 152 the timestamp is correct, but for revision 158 the UTC
offset is +0200 instead of +0100. Then, of course, also the POSIX
timestamp in the commit object is wrong:
$ git cat-file -p c6b4f7aaa66650a16de67d32fb83d541b1973331
tree ff4528220ddcf8beca9f4958fbb947d5ed85808e
parent edcaeb292153663664d850bafe1dad12daab4165
author Urs Thuermann 1290551053 +0200
committer Urs Thuermann 1290551053 +0200
Make code portable to Linux/amd64
...
$ date -d@1290551053 +%F\ %T\ %z
2010-11-23 23:24:13 +0100
The correct timestamp would be 2010-11-24 00:24:13 +0100, or, as a
POSIX time_t 1290554653.
I could find the bug grepping through /usr/lib/git-core/git-svn, maybe
it's in GIT::SVN::Fetcher or some other GIT::SVN module.
Is a fix available for this bug?
urs
Re: Migration from CVS to Git looses merges
Andreas Schwab writes:
> Merges are recognized purely by matching the commit message, and the
> regexp must capture the branch name in the first subexpr. The -m option
> enables some default regexps but won't match your example. You can use
> -M 'Merge branch ([-\w]+)' to match it.
Thanks, I tried again and now it works. I misread the man page and
also tried enclosing the regexp in //, also tried to escape the
parentheses (as in BRE), and I thought I also tried 'Merge branch (.*)'.
Obviously, I missed that one since it now works.
BTW, I now looked up the regexes for -m in git-cvsimport.perl. Should
probably in the man page.
I also suggest the following patch, so that -m would work with my not
so uncommon merge commit message:
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 1e4e65a..1f8044b 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -207,7 +207,7 @@ if ($#ARGV == 0) {
our @mergerx = ();
if ($opt_m) {
- @mergerx = ( qr/\b(?:from|of|merge|merging|merged) ([-\w]+)/i );
+ @mergerx = ( qr/\b(?:from|of|merge|merging|merged) (?:branch
)?([-\w]+)/i );
}
if (@opt_M) {
push (@mergerx, map { qr/$_/ } @opt_M);
urs
Migration from CVS to Git looses merges
I want to convert several old CVS repositories to Git. Some of these CVS repositories contain branches, which have later been merged to the main trunk. When I try to convert using cvs2git or git cvsimport the branches appear in the new git repository but they are not merged to the master branch. Here is an example of how the branches in the CVS repository were created and merged: cd /tmp export CVSROOT=$PWD/CVS cvs init mkdir CVS/foo cvs co foo cd foo (date; seq 10; date) > bar cvs add bar cvs ci -m msg1 # rev 1.1 sleep 1 printf "1c\n%s\n.\nwq\n" "`date`" | ed bar cvs ci -m msg2 # rev 1.2 sleep 1 cvs tag -b a-branch sleep 1 printf "1c\n%s\n.\nwq\n" "`date`" | ed bar cvs ci -m msg3 # rev 1.3 sleep 1 cvs up -r a-branch printf "12c\n%s\n.\nwq\n" "`date`" | ed bar cvs ci -m msg-b1# rev 1.2.2.1 sleep 1 printf "12c\n%s\n.\nwq\n" "`date`" | ed bar cvs ci -m msg-b2# rev 1.2.2.2 sleep 1 cvs up -A cvs up -j a-branch cvs ci -m "Merge branch a-branch" # rev 1.4 Now I have tried 2 ways to convert this to git: 1. mkdir g; cd g; git cvsimport -A -m foo 2. mkdir g; cd g; git init; cvs2git --blobfile=foo.blob --dumpfile=foo.dump --username=urs ../CVS/foo cat foo.blob foo.dump | git fast-import In both cases, the branch "a-branch" is in the git repository but is not merged with the master branch, i.e. rev 1.4 has only parent 1.3 but not 1.2.2.2. I also tried cvsimport with several regexes passed using -M to match "Merge branch a-branch", but still the same result. How should the CVS repository be converted to git, so that the commit corresponding to rev 1.4 has two parents, 1.3 and 1.2.2.2? urs
Re: How to keep log history when renaming and changing simultaneously
Igor Djordjevic writes: > For both cases (renaming and splitting), would using `--find-copies` > work for you? Perhaps with some low threshold value to start with, if > the default one yields no results. > > If interested, adding `--name-status` to the mix will show similarity > percentage between old and new file(s). I didn't know --find-copies and --name-status and I've now looked them up in the doc. Looks interesting but instead of looking for similarity it would be better IMHO if there was a command "git cp" and that "git mv" and "git cp" were recorded in the history somehow. I'm still using CVS (and SVN in some few cases) but considering changing to git. There are some things, however, that I can do more easily in CVS (like editing CVS ,v files instead of git commit --amend) and I need to learn more git before I want to change (and migrate existing repos). urs
How to keep log history when renaming and changing simultaneously
Sometimes I need to rename and change a file in one commit. One
example would be a file foo.h that begins with
#ifndef FOO_H
#define FOO_H
which should be renamed bar.h and have the FOO_H changed to BAR_H.
In subversion I would
svn mv foo.h bar.h; vi bar.h; svn ci
and then a
svn log bar.h
also shows the history of that file when it was named foo.h.
This does not work in git. After committing,
git mv foo.h bar.h; vi bar.h; git commit -a
the command
git log --follow bar.h
shows only the history of the file when it was named bar.h, but not
its life as foo.h.
The only workaround I found was to do the rename and the change in two
separate commits, so that git sees the same name and the same SHA hash
which allows it to follow the files' history. This can be a problem
when the intermediate version with either only the change or only the
rename doesn't compile correctly.
Is there a better way to do this in git?
A similar problem is splitting a file into two files. With subversion
I'd do
printf "void foo() {}\nint main() { foo(); }\n" > prog.c
svn add prog.c; svn ci -m "Add prog.c"
Then I would split
svn cp prog.c foo.c; svn cp prog.c main.c; svn rm prog.c
printf "2d\nwq\n" | ed foo.c; printf "1d\nwq\n" | ed main.c
svn ci -m "Split prog.c"; svn up
and I get
$ svn log -v
r2 | urs | 2017-04-17 10:03:06 +0200 (Mon, 17 Apr 2017) | 1 line
Changed paths:
A /foo.c (from /prog.c:1)
A /main.c (from /prog.c:1)
D /prog.c
Split prog.c
r1 | urs | 2017-04-17 10:02:51 +0200 (Mon, 17 Apr 2017) | 1 line
Changed paths:
A /prog.c
Add prog.c
And I can also see this when I run svn log on one of both files.
How could I do this in git?
urs
