* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-15 22:09 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
> > > Any chance you can update it with more examples?
> > > Especially one that show how one can do one big initial
> > > commit then merge your own changes on top of that?
> >
> > Hmm.. large imports from git to svn can get confusing, and generally
> > aren't very useful on the svn side since history gets flattened.
> > So I generally don't recommend importing complete git histories into
> > svn.
>
> Yes, that's what I am trying to avoid below. Basically I want
> to commit to SVN the
> whole u-boot tree as one commit up to the point where I
> started to do my changes.
> Then I want my changes per commit on top of that. However I
> don't want to loose the
> ability to merge/pull in future updates from denx u-boot tree.
>
> I just don't know how to do it, the script below fails when
> it tries to
> pull the rest of the tree. Any ideas?
I really need some advice here, if you can share some ideas that would be great.
>
> >
> > > Something like this
> > > REPO="file:///tmp/SVNuboot"
> > > REPO_PATH="/tmp/SVNuboot"
> > > GIT_REPO="/tmp/mygituboot"
> > > ORG_REPO="/usr/local/src/u-boot"
> > > rm -rf "$REPO_PATH"
> > > rm -rf "$GIT_REPO"
> > > svnadmin create "$REPO_PATH"
> > > svn mkdir -m "initial repo layout" "$REPO"/trunk
> > "$REPO"/branches "$REPO"/tags
> > > mkdir -p "$GIT_REPO"
> > > cd "$GIT_REPO"
> > > git-svn init "$REPO"/trunk
> > > echo [user] >> .git/config
> > > echo name="jocke" >> .git/config
> > > echo email="Joakim.Tjernlund@transmode.se" >> .git/config
> > > git-svn fetch
> > > git checkout -b svn-branch remotes/git-svn
> > > git-fetch "$ORG_REPO" tmcu2:tmcu
> > > git-branch initial-uboot f5e0d03970409feb3c77ab0107d5dece6b7d45c9
> > > git pull . initial-uboot
> > > # --squash makes one large commit.
> > > git pull --squash . initial-uboot
> > > cg-commit -m "merge up to
> f5e0d03970409feb3c77ab0107d5dece6b7d45c9"
> > > git-svn commit -q remotes/git-svn..svn-branch
> > > git pull . tmcu # This doesn't work, I get merge conflicts
> > > git-svn commit -q remotes/git-svn..svn-branch
> > >
> > > Anyhow, I am glad to report that after applying your patch all my
> > > problems with went away, no more Too many open file desc, memory
> > > alloc failed or Inappropriate ioctl for device, Thanks a lot.
> >
> > Cool, good to know. It seems like the apply_textdelta
> returning undef
> > was a result of memory allocation failures, then.
>
> Or possibly the older subversion I used(1.3.2), now I am on 1.4.0
>
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Theodore Tso @ 2006-10-15 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Stephen Hemminger
In-Reply-To: <7v4pu62ite.fsf@assigned-by-dhcp.cox.net>
On Sat, Oct 14, 2006 at 11:29:17PM -0700, Junio C Hamano wrote:
> It was brought to my attention that the public git.git
> repository cannot be cloned with older versions of git. More
> precisely, packs generated with post 16854571 (NOT contained in
> v1.4.2.3 but in the current "master" and more importantly in
> v1.4.3-rc3 which I tagged tonight) can contain deltas that are
> not compatible with the version of git before d60fc1c8, which
> means that v1.1.6 and older (v1.2.0 and later are Ok).
By the way, note that Ubuntu Dapper (the current stable version of
Ubuntu) is shipped with git version 1.1.3, and that incompatibility
extends not to the git repository, but also the Linux-2.6 repostiory
at
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
- Ted
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Linus Torvalds @ 2006-10-15 23:52 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git, Stephen Hemminger
In-Reply-To: <20061015224012.GC5092@thunk.org>
On Sun, 15 Oct 2006, Theodore Tso wrote:
>
> By the way, note that Ubuntu Dapper (the current stable version of
> Ubuntu) is shipped with git version 1.1.3, and that incompatibility
> extends not to the git repository, but also the Linux-2.6 repostiory
> at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
That should have been fixed earlier today, since I forced a repack when
this was discovered.
So if somebody still can't pull it with old git tools, please holler.
That said, Ubuntu should definitely upgrade.
Linus
^ permalink raw reply
* [PATCH] bisect reset: Leave the tree in usable state if git-checkout failed
From: Petr Baudis @ 2006-10-16 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I had local modifications in the tree and doing bisect reset required me to
manually edit .git/HEAD.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-bisect.sh | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 06a8d26..09cd179 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -179,11 +179,12 @@ bisect_reset() {
*)
usage ;;
esac
- git checkout "$branch" &&
- rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
- rm -f "$GIT_DIR/BISECT_LOG"
- rm -f "$GIT_DIR/BISECT_NAMES"
+ if ! git checkout "$branch"; then
+ rm -fr "$GIT_DIR/refs/bisect"
+ rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
+ rm -f "$GIT_DIR/BISECT_LOG"
+ rm -f "$GIT_DIR/BISECT_NAMES"
+ fi
}
bisect_replay () {
^ permalink raw reply related
* [PATCH] svnimport: Fix broken tags being generated
From: Petr Baudis @ 2006-10-16 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently git-svnimport generates broken tags missing the timespec in the
'tagger' line. This is a random stab at a minimal fix.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 988514e..aca0e4f 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -838,7 +838,7 @@ # }
print $out ("object $cid\n".
"type commit\n".
"tag $dest\n".
- "tagger $committer_name <$committer_email>\n") and
+ "tagger $committer_name <$committer_email> 0 +0000\n") and
close($out)
or die "Cannot create tag object $dest: $!\n";
^ permalink raw reply related
* Re: [PATCH] bisect reset: Leave the tree in usable state if git-checkout failed
From: Petr Baudis @ 2006-10-16 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061016005925.27019.38262.stgit@machine.or.cz>
Dear diary, on Mon, Oct 16, 2006 at 02:59:25AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> I had local modifications in the tree and doing bisect reset required me to
> manually edit .git/HEAD.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> git-bisect.sh | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 06a8d26..09cd179 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -179,11 +179,12 @@ bisect_reset() {
> *)
> usage ;;
> esac
> - git checkout "$branch" &&
> - rm -fr "$GIT_DIR/refs/bisect"
> - rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
> - rm -f "$GIT_DIR/BISECT_LOG"
> - rm -f "$GIT_DIR/BISECT_NAMES"
> + if ! git checkout "$branch"; then
Doh, please drop the !. I had it that way before and added the negation
mark as a last-minute "fix". :/ Sorry. Not being too good at doing
random shell fixes in the middle of C coding.
> + rm -fr "$GIT_DIR/refs/bisect"
> + rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
> + rm -f "$GIT_DIR/BISECT_LOG"
> + rm -f "$GIT_DIR/BISECT_NAMES"
> + fi
> }
>
> bisect_replay () {
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* git-pull question
From: Joakim Tjernlund @ 2006-10-16 1:00 UTC (permalink / raw)
To: git
Why isn't
git checkout -b myb otherb
git pull . thirdb
the same as
git checkout -b myb otherb
git pull . thirdb:myb
Jocke
^ permalink raw reply
* cogito-0.16: t/test-lib.sh: Unportable test(1) construct
From: Thomas Klausner @ 2006-10-16 1:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 246 bytes --]
Hi!
As of version 0.16, cogito is using an unportable bash extension
"==" for test(1) in t/test-lib.sh. This is not supported by most
other shells or even test(1) from GNU coreutils. Please use "="
instead. A patch is attached.
Thanks,
Thomas
[-- Attachment #2: patch-aa --]
[-- Type: text/plain, Size: 851 bytes --]
$NetBSD: patch-aa,v 1.1 2006/10/16 00:44:15 wiz Exp $
--- t/test-lib.sh.orig 2005-11-27 16:26:16.000000000 +0000
+++ t/test-lib.sh
@@ -87,16 +87,16 @@ test_failure_ () {
say "FAIL $test_count: $1"
shift
echo "$@" | sed -e 's/^/ /'
- test "$immediate" == "" || exit 1
+ test "$immediate" = "" || exit 1
}
test_debug () {
- test "$debug" == "" || eval "$1"
+ test "$debug" = "" || eval "$1"
}
test_expect_failure () {
- test "$#" == 2 ||
+ test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-failure"
say >&3 "expecting failure: $2"
if eval >&3 2>&4 "$2"
@@ -108,7 +108,7 @@ test_expect_failure () {
}
test_expect_success () {
- test "$#" == 2 ||
+ test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
say >&3 "expecting success: $2"
if eval >&3 2>&4 "$2"
^ permalink raw reply
* Re: cogito-0.16: t/test-lib.sh: Unportable test(1) construct
From: Petr Baudis @ 2006-10-16 1:47 UTC (permalink / raw)
To: Thomas Klausner; +Cc: git, nico-linux-git
In-Reply-To: <20061016010520.GS25390@danbala.tuwien.ac.at>
Hi,
Dear diary, on Mon, Oct 16, 2006 at 03:05:20AM CEST, I got a letter
where Thomas Klausner <tk@giga.or.at> said that...
> As of version 0.16, cogito is using an unportable bash extension
> "==" for test(1) in t/test-lib.sh. This is not supported by most
> other shells or even test(1) from GNU coreutils. Please use "="
> instead. A patch is attached.
thanks, applied. Please generate -p1 patches in the future and sign
them off.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Stephen Hemminger @ 2006-10-16 2:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610151650570.3962@g5.osdl.org>
On Sun, 15 Oct 2006 16:52:04 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 15 Oct 2006, Theodore Tso wrote:
> >
> > By the way, note that Ubuntu Dapper (the current stable version of
> > Ubuntu) is shipped with git version 1.1.3, and that incompatibility
> > extends not to the git repository, but also the Linux-2.6 repostiory
> > at
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> That should have been fixed earlier today, since I forced a repack when
> this was discovered.
>
> So if somebody still can't pull it with old git tools, please holler.
>
> That said, Ubuntu should definitely upgrade.
>
> Linus
They made some nice about putting a new version in the backport
repository.
^ permalink raw reply
* Re: On blame/pickaxe
From: Petr Baudis @ 2006-10-16 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git, Linus Torvalds
In-Reply-To: <7vr6xddm7h.fsf@assigned-by-dhcp.cox.net>
Thanks for the nice writeup!
Dear diary, on Fri, Oct 13, 2006 at 03:43:46AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When done with one parent, if you are a merge, you will then try
> to pass the blame on the remaining part that you are still
> suspected for to other parents.
(This got me nervous but I guess it actually makes sense - if only one
parent modified a line, it's right to pass the blame up; else if you
took one parent's version verbatim, it's right to pass the blame up as
well (I think); else you've already got the blame assigned to the merge
commit and everything is all right.)
> To blame the implementation of foo() to the parent, we could do
> something like this:
>
> for each blame_entry that you are still suspected for,
> diff those lines (and only those lines) with the parent,
> to see if you find a copy. If there is a copy, you can
> pass the blame to the parent.
Now, this is very nifty and so for moving functions around, but I
think it is very dangerous for anything where ordering matters - large
arrays definitions, patch series files, etc. In that case, you've
completely ommitted the fact that the movement occured, which can be
crucial and based on the current behaviour of the tools, I think people
expect this now. To put it shortly, "who wrote this line" vs "who put
this line here".
I would prefer to stay more conservative here by default. Graphical
tools could solve this by some nice presentation like
3fea1 int moved() -.
3fea1 { |
28abc watch(more + anime); | 17d50
17d50 return !hypno; |
3fea1 } -'
Dear diary, on Sun, Oct 15, 2006 at 01:43:53AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I have to admit that I am becoming quite fond of the name
> "pickaxe", by the way.
Gaah, please don't. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-16 2:52 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <45329359.1030302@gmail.com>
On Sun, 15 Oct 2006, A Large Angry SCM wrote:
> Nicolas Pitre wrote:
> >
> > The delta-base-offset case included a new object type that wasn't used
> > before hence there is no room for confusion, and yet that new delta object
> > could be encoded according to pack version 2 or pack version 3 which makes
> > it orthogonal to the pack version itself.
>
> It's not a new object type. It's a new object _encoding_ method.
Not at all. If it was only a question of encoding method, then both of
them could always be interchangeable and supersede the other, which is
not the case here.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-16 3:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jakub Narebski, git
In-Reply-To: <9e4733910610151249m37c9f6abv37e07d7a801758bc@mail.gmail.com>
Dear diary, on Sun, Oct 15, 2006 at 09:49:08PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> On 10/15/06, Petr Baudis <pasky@suse.cz> wrote:
> >> I am still working with the developers of the cvs2svn import tool to
> >> fix things so that Mozilla CVS can be correctly imported. There are
> >> still outstanding bugs in cvs2svn preventing a correct import. MozCVS
> >> can be imported, but the resulting repository is not entirely correct.
> >>
> >> Once they get the base cvs2svn fixed I'll port my patches to turn it
> >> into cvs2git again.
> >
> >So what exactly is the cvs2git status now? AFAIU, there's a tool that
> >parses the CVS repository and that is then "piped" to git-fastimport?
> >git-fastimport is available somewhere (perhaps it would be interesting
> >to publish it at repo.or.cz or something), is the current cvs2git
> >version available as well?
>
> cvs2git is a set of patches that get applied to cvs2svn. The patches
> modify cvs2svn to output things in a format that git-fastimport can
> consume.
By the way, isn't what you want an incremental importer, because of the
1.9 branch? According to its homepage, cvs2svn is not designed for
incremental importing. Or are you fixing that as well?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Jon Smirl @ 2006-10-16 3:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061016032314.GA20017@pasky.or.cz>
On 10/15/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 15, 2006 at 09:49:08PM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > On 10/15/06, Petr Baudis <pasky@suse.cz> wrote:
> > >> I am still working with the developers of the cvs2svn import tool to
> > >> fix things so that Mozilla CVS can be correctly imported. There are
> > >> still outstanding bugs in cvs2svn preventing a correct import. MozCVS
> > >> can be imported, but the resulting repository is not entirely correct.
> > >>
> > >> Once they get the base cvs2svn fixed I'll port my patches to turn it
> > >> into cvs2git again.
> > >
> > >So what exactly is the cvs2git status now? AFAIU, there's a tool that
> > >parses the CVS repository and that is then "piped" to git-fastimport?
> > >git-fastimport is available somewhere (perhaps it would be interesting
> > >to publish it at repo.or.cz or something), is the current cvs2git
> > >version available as well?
> >
> > cvs2git is a set of patches that get applied to cvs2svn. The patches
> > modify cvs2svn to output things in a format that git-fastimport can
> > consume.
>
> By the way, isn't what you want an incremental importer, because of the
> 1.9 branch? According to its homepage, cvs2svn is not designed for
> incremental importing. Or are you fixing that as well?
cvsps works ok on small amounts of data, but it can't handle the full
Mozilla repo. The current idea is to convert the full repo with
cvs2git and build the ini file needed by cvsps to support incremental
imports. After that use cvsps.
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git-svn and u-boot broken.
From: Eric Wong @ 2006-10-16 3:47 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <012b01c6f0a6$a1a636e0$1267a8c0@Jocke>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > Any chance you can update it with more examples?
> > > > Especially one that show how one can do one big initial
> > > > commit then merge your own changes on top of that?
> > >
> > > Hmm.. large imports from git to svn can get confusing, and generally
> > > aren't very useful on the svn side since history gets flattened.
> > > So I generally don't recommend importing complete git histories into
> > > svn.
> >
> > Yes, that's what I am trying to avoid below. Basically I want
> > to commit to SVN the
> > whole u-boot tree as one commit up to the point where I
> > started to do my changes.
> > Then I want my changes per commit on top of that. However I
> > don't want to loose the
> > ability to merge/pull in future updates from denx u-boot tree.
> >
> > I just don't know how to do it, the script below fails when
> > it tries to
> > pull the rest of the tree. Any ideas?
>
> I really need some advice here, if you can share some ideas that would be great.
>
> >
> > >
> > > > Something like this
> > > > REPO="file:///tmp/SVNuboot"
> > > > REPO_PATH="/tmp/SVNuboot"
> > > > GIT_REPO="/tmp/mygituboot"
> > > > ORG_REPO="/usr/local/src/u-boot"
> > > > rm -rf "$REPO_PATH"
> > > > rm -rf "$GIT_REPO"
> > > > svnadmin create "$REPO_PATH"
> > > > svn mkdir -m "initial repo layout" "$REPO"/trunk
> > > "$REPO"/branches "$REPO"/tags
> > > > mkdir -p "$GIT_REPO"
> > > > cd "$GIT_REPO"
> > > > git-svn init "$REPO"/trunk
> > > > echo [user] >> .git/config
> > > > echo name="jocke" >> .git/config
> > > > echo email="Joakim.Tjernlund@transmode.se" >> .git/config
> > > > git-svn fetch
> > > > git checkout -b svn-branch remotes/git-svn
> > > > git-fetch "$ORG_REPO" tmcu2:tmcu
I assume the tmcu* branch is private as I don't see it in the u-boot
repo.
> > > > git-branch initial-uboot f5e0d03970409feb3c77ab0107d5dece6b7d45c9
> > > > git pull . initial-uboot
> > > > # --squash makes one large commit.
> > > > git pull --squash . initial-uboot
> > > > cg-commit -m "merge up to
> > f5e0d03970409feb3c77ab0107d5dece6b7d45c9"
> > > > git-svn commit -q remotes/git-svn..svn-branch
> > > > git pull . tmcu # This doesn't work, I get merge conflicts
> > > > git-svn commit -q remotes/git-svn..svn-branch
Using -q suppresses potentially useful information. I wouldn't use
it if you're not sure about what you're doing.
I would do something like this:
... (same stuff as above before with svn setup...)
git clone $ORG_REPO $GIT_REPO
cd $GIT_REPO
git-svn init "$REPO"/trunk
git-svn fetch
# sync the SVN repo with initial-uboot
# this will just commit a snapshot, without history, which I assume
# is what you want.
git-branch initial-uboot f5e0d03970409feb3c77ab0107d5dece6b7d45c9
git-svn commit initial-uboot
git checkout -b svn-branch remotes/git-svn
git-pull . tmcu2
# this should work assuming the path from initial-uboot..tmcu2 is linear
# use gitk initial-uboot..tmcu2 to check
git-svn dcommit
Also, git-svn is really designed for individual developers who prefer to
use git, but need to interact with project that already uses SVN.
u-boot already uses git, so I don't see why you'd need git-svn :)
--
Eric Wong
^ permalink raw reply
* Re: VCS comparison table
From: Martin Pool @ 2006-10-16 3:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <egr3ud$nqm$1@sea.gmane.org>
On 14 Oct 2006, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Smirl wrote:
>
> > It refers to this comparison chart between source control systems.
> > http://bazaar-vcs.org/RcsComparisons
>
> It is quite obvious that comparison of programs of given type (SMC)
> on some program site (Bazaar-NG) is usually biased towards said program,
> perhaps unconsciously: by emphasizing the features which were important
> for developers of said program.
I don't think I saw the original post but thanks for the feedback, we'll
update it.
> Gaah, subscribe-to-post mailing list!
No, it's just moderated for first time posters to avoid spam. Your
message got through.
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Junio C Hamano @ 2006-10-16 4:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610151433310.17085@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> As for pack v4... My opinion is that nothing justifies it so far. So if
> I can convince Junio there shouldn't be any v4 just yet.
The only concern I have is the commit walkers (rsync has the
same problem as well but we honestly do not care). They just
grab existing packs and try to use them. I have been wondering
if it might be safer to mark the delta-base-offset encoded packs
v4 to make sure the clients would get "I know only v2 and v3 but
you fed me v4" message.
People who own public repositories and who care about commit
walkers need to refrain from using delta-base-offset when
repacking (which can be done via configuration mechanism
already).
If download goes over git native protocol, there is no such
worry -- they can pack using delta-base-offset and older clients
will be fed a pack with 20-byte base object name just fine, so my
worry is really only about commit walkers.
^ permalink raw reply
* Re: [PATCH] svnimport: Fix broken tags being generated
From: Junio C Hamano @ 2006-10-16 5:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061016010037.27259.26157.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Currently git-svnimport generates broken tags missing the timespec in the
> 'tagger' line. This is a random stab at a minimal fix.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
Interesting. Applied.
I remember that older "git tag" does not even add the tagger
line (the kernel history starts using one from 2.6.13-rc4 on Jul
28, 2005). Does gitweb handle those tags correctly, I wonder?
Especially for 2.6.11-tree tag there is no info you can guess
any "age" information from.
^ permalink raw reply
* Re: On blame/pickaxe
From: Junio C Hamano @ 2006-10-16 6:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Luben Tuikov, git, Linus Torvalds
In-Reply-To: <20061016022159.GZ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Thanks for the nice writeup!
>
> Dear diary, on Fri, Oct 13, 2006 at 03:43:46AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> When done with one parent, if you are a merge, you will then try
>> to pass the blame on the remaining part that you are still
>> suspected for to other parents.
>
> (This got me nervous but I guess it actually makes sense - if only one
> parent modified a line, it's right to pass the blame up; else if you
> took one parent's version verbatim, it's right to pass the blame up as
> well (I think); else you've already got the blame assigned to the merge
> commit and everything is all right.)
Well, this part is the classic blame algorithm. The beauty of
it is that a merge case falls out as a natural consequence of
the one-parent case and you do not have to do anything special.
You either inherited a line from your parent (or one or more of
your parents) or you created the line yourself. If you subtract
what you can blame your parents for, the remainder is what you
introduced. The number of parents you have does not have any
effect on that logic.
> Now, this is very nifty and so for moving functions around, but I
> think it is very dangerous for anything where ordering matters - large
> arrays definitions, patch series files, etc. In that case, you've
> completely ommitted the fact that the movement occured, which can be
> crucial and based on the current behaviour of the tools, I think people
> expect this now. To put it shortly, "who wrote this line" vs "who put
> this line here".
That's exactly why we have -f and -n options, so that the
program that reads from blame output can tell where things came
from. It is not about "who wrote it" vs "who put it here";
pickaxe gives a lot more than that: "where did this originally
come from", i.e. "by whom in which file at what line number was
the line created".
If the user is not prepared to see code movement, pickaxe can be
run without -M nor -C to get the classic blame output.
By the way, We would not want to do the code movement (or
copying from unrelated file) for very trivial lines. E.g. you
would not want to blame the following three lines:
+ }
+}
+#endif
to a random file that happens to have the exact copy of the
above that is not related at all. Something like the above can
happen almost anywhere. The current implementation of -M/-C
does not do this very well. find_copy_in_blob() currently
passes blame to the parent when it finds nontrivial copies, but
instead it should inspect the patch and return a score, and the
caller should take the parent with the best match and assign
blame to it.
^ permalink raw reply
* Re: git-pull question
From: Johannes Schindelin @ 2006-10-16 9:11 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <012c01c6f0be$7d329fc0$1267a8c0@Jocke>
Hi,
On Mon, 16 Oct 2006, Joakim Tjernlund wrote:
> Why isn't
> git checkout -b myb otherb
> git pull . thirdb
>
> the same as
> git checkout -b myb otherb
> git pull . thirdb:myb
You have to understand that "thirdb:myb" means "fetch the branch thirdb
and _store_ it as myb (if it fast forwards)".
So, it makes no sense at all to use the "remote:local" syntax with pull.
Hth,
Dscho
^ permalink raw reply
* Re: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-16 10:06 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061016034736.GA8782@localdomain>
Eric Wong wrote:
[SNIP]
>
> Using -q suppresses potentially useful information. I wouldn't use
> it if you're not sure about what you're doing.
OK.
>
> I would do something like this:
>
> ... (same stuff as above before with svn setup...)
> git clone $ORG_REPO $GIT_REPO
> cd $GIT_REPO
> git-svn init "$REPO"/trunk
> git-svn fetch
>
> # sync the SVN repo with initial-uboot
> # this will just commit a snapshot, without history, which I assume
> # is what you want.
> git-branch initial-uboot f5e0d03970409feb3c77ab0107d5dece6b7d45c9
> git-svn commit initial-uboot
> git checkout -b svn-branch remotes/git-svn
> git-pull . tmcu2
>
> # this should work assuming the path from initial-uboot..tmcu2 is linear
> # use gitk initial-uboot..tmcu2 to check
> git-svn dcommit
Great! This was exactly what I wanted, thanks. I never realized that one should
do git-svn commit initial-uboot to get that single commit.
I also replaced git-svn dcommit with git-svn commit remotes/git-svn..svn-branch
as I don't have that version yet.
You should add this as an example I think.
Can I ask for an example that used multi-init and multi-fetch? I tried, but
could not make it work.
>
> Also, git-svn is really designed for individual developers who prefer to
> use git, but need to interact with project that already uses SVN.
> u-boot already uses git, so I don't see why you'd need git-svn :)
Yes, but the thing is that the rest of our product is svn based including
the build env. So I have to supply a SVN tree for build purposes and if someone
else has to do a minor fix I can't ask him to learn git first :(
jcoke
^ permalink raw reply
* StGIT patches
From: Catalin Marinas @ 2006-10-16 11:04 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Hi Robin,
I saw some StGIT patches you posted on the mailing list. I eventually
finished my holiday and can integrate them. Could you please send them
to me again to make sure I won't miss any?
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] svnimport: Fix broken tags being generated
From: Petr Baudis @ 2006-10-16 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpscsx1hr.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Oct 16, 2006 at 07:40:00AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Currently git-svnimport generates broken tags missing the timespec in the
> > 'tagger' line. This is a random stab at a minimal fix.
> >
> > Signed-off-by: Petr Baudis <pasky@suse.cz>
>
> Interesting. Applied.
>
> I remember that older "git tag" does not even add the tagger
> line (the kernel history starts using one from 2.6.13-rc4 on Jul
> 28, 2005). Does gitweb handle those tags correctly, I wonder?
It seems from git_tag() that the original author thought about that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-16 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64ekyikn.fsf@assigned-by-dhcp.cox.net>
On Sun, 15 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > As for pack v4... My opinion is that nothing justifies it so far. So if
> > I can convince Junio there shouldn't be any v4 just yet.
>
> The only concern I have is the commit walkers (rsync has the
> same problem as well but we honestly do not care). They just
> grab existing packs and try to use them. I have been wondering
> if it might be safer to mark the delta-base-offset encoded packs
> v4 to make sure the clients would get "I know only v2 and v3 but
> you fed me v4" message.
It'll get "this pack contains an unknown object type" kind of message,
which is almost as good IMHO, with the same end result.
Nicolas
^ permalink raw reply
* [RFC/PATCH] git-fetch: Use already fetched branch with the --local flag.
From: Santi Béjar @ 2006-10-16 13:40 UTC (permalink / raw)
To: Git Mailing List
It allows to separate when you fetch from when you merge. So, a "git pull"
can be:
$ git fetch
$ git pull --local
and the pull call can be made later. This is usefull when you have multiple
branches and you want to merge the same "upstream" branch, or when you are
offline but you have already fetched the remote branch.
Note that this is different from:
$ git fetch
$ git pull . origin
(1) you do not have to tell explicitly the branch to merge
(2) the commit message is exactly as with "git pull"
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/fetch-options.txt | 3 +++
git-fetch.sh | 25 +++++++++++++++++++------
git-parse-remote.sh | 22 ++++++++++++++++++++++
3 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 13f34d3..3a6cb3d 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -39,3 +39,6 @@
check. Note that fetching into the current branch will not
update the index and working directory, so use it with care.
+\--local::
+ Do not fetch from the remote repository. Use the already fetched
+ branches to program the merge for `git-pull`.
diff --git a/git-fetch.sh b/git-fetch.sh
index 79222fb..5ff800a 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -21,6 +21,7 @@ update_head_ok=
exec=
upload_pack=
keep=--thin
+local_fetch=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -56,6 +57,9 @@ do
--reflog-action=*)
rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
;;
+ --local)
+ local_fetch=t
+ ;;
-*)
usage
;;
@@ -80,6 +84,10 @@ refs=
rref=
rsync_slurped_objects=
+[ "$local_fetch" = t ] && [ "$remote_nick" = "$remote" ] && \
+ [ "$remote" != "." ] && \
+ die "Flag --local only compatible with remote shorthands"
+
rloga="$rloga $remote_nick"
test "$remote_nick" = "$remote" || rloga="$rloga $remote"
@@ -285,8 +293,8 @@ fetch_main () {
rref="$rref$LF$remote_name"
# There are transports that can fetch only one head at a time...
- case "$remote" in
- http://* | https://* | ftp://*)
+ case "$local_fetch,$remote" in
+ ,http://* | ,https://* | ,ftp://*)
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
@@ -313,7 +321,7 @@ fetch_main () {
echo >&2 Fetching "$remote_name from $remote" using http
git-http-fetch -v -a "$head" "$remote/" || exit
;;
- rsync://*)
+ ,rsync://*)
TMP_HEAD="$GIT_DIR/TMP_HEAD"
rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
head=$(git-rev-parse --verify TMP_HEAD)
@@ -343,6 +351,11 @@ fetch_main () {
rsync_slurped_objects=t
}
;;
+ t,*)
+ [ -z "$local_name" ] &&\
+ local_name=$(get_ref_for_remote_branch "$remote_nick" "$remote_name")
+ head=$(git-rev-parse --verify $local_name^0) || exit
+ ;;
*)
# We will do git native transport with just one call later.
continue ;;
@@ -353,8 +366,8 @@ fetch_main () {
done
- case "$remote" in
- http://* | https://* | ftp://* | rsync://* )
+ case "$local_fetch,$remote" in
+ ,http://* | ,https://* | ,ftp://* | ,rsync://* | t,*)
;; # we are already done.
*)
( : subshell because we muck with IFS
@@ -406,7 +419,7 @@ fetch_main () {
fetch_main "$reflist"
# automated tag following
-case "$no_tags$tags" in
+case "$no_tags$tags$local_fetch" in
'')
case "$reflist" in
*:refs/*)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c325ef7..679f73c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -236,3 +236,25 @@ resolve_alternates () {
esac
done
}
+
+get_ref_for_remote_branch (){
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | config-partial | branches | branches-partial)
+ test "$1" = . && echo $2
+ ;;
+ config)
+ ref=$(git-repo-config --get-all "remote.$1.fetch" |\
+ grep "^$2:")
+ expr "z$ref" : 'z[^:]*:\(.*\)'
+ ;;
+ remotes)
+ ref=$(sed -ne '/^Pull: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1" | grep "$2:")
+ expr "z$ref" : 'z[^:]*:\(.*\)'
+ ;;
+ *)
+ die "internal error: get-ref-for-remote-branch $1 $2" ;;
+ esac
+}
--
1.4.3.rc2.ga442
^ permalink raw reply related
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