* Re: git-svn "cannot lock ref" error during fetch
From: Eric Wong @ 2007-06-07 6:31 UTC (permalink / raw)
To: James Peach; +Cc: git
In-Reply-To: <50C9688F-9C62-43AC-A84D-D84561671BAC@mac.com>
James Peach <jamespeach@mac.com> wrote:
> Hi all,
>
> I'm new to git, and I'm experimenting with using git-svn to interact
> with a large SVN repository with lots of branches.
>
> I initially did an init like this:
>
> git-svn init -t tags -b branches -T trunk svn+ssh://server/svn/project
>
> Then I did a git-svn fetch, which started pulling all the branches.
> After a while, however, it hit a branch that it couldn't pull:
>
> Found branch parent: (tags/project-92~9)
> 767f1f1601a4deae459c99ea6c1d1b9ba8f57a65
> Following parent with do_update
> ...
> Successfully followed parent
> fatal: refs/remotes/tags/project-92~9: cannot lock the ref
> update-ref -m r13726 refs/remotes/tags/project-92~9
> 950638ff72acc278156a0d55baafbabb43f2b772: command returned error: 128
>
> Some amount of searching failed to turn up any hints on what this
> error means or how I can work around it. I'd appreciate any advice ...
Is there a tag actually named "project-92~9"? If so, it's
an invalid branch name for git. I started working on a way
around it by mapping new names to it, but haven't gotten around to
finishing it....
--
Eric Wong
^ permalink raw reply
* Error trying to use dcommit
From: Jean-Marc Valin @ 2007-06-07 6:12 UTC (permalink / raw)
To: git
Hi,
I've made some changes to an svn project in git and trying to dcommit, I
get:
% git-svn dcommit
Merge conflict during commit: Your file or directory 'TODO' is probably
out-of-date: The version resource does not correspond to the resource
within the transaction. Either the requested version resource is out of
date (needs to be updated), or the requested version resource is newer
than the transaction root (restart the commit). at
/usr/local/bin/git-svn line 405
Basically, I did an git-svn init http://svn.xiph.org/trunk/speex and
then modified the TODO file in both svn and git. I did a fetch & rebase
of the git repository, then made another modification in git and tried
to dcommit. Some bits of potentially useful info from an IRC discussion:
<mugwump> git-log shows HEAD~2 as the last SVN commit (ie, includes the
git-svn-id: in the commit message)
<mugwump> the commitid is a9b9f3c
<mugwump> so, I used this to see what git-svn expects the file to be:
<mugwump> git-cat-file blob a9b9f3c:TODO > TODO.gitsvn
<mugwump> svn cat http://svn.xiph.org//trunk/speex/TODO > TODO.svn
<mugwump> however those files are identical
<mugwump> which is good. but makes the error confusing
The rest of below.
Cheers,
Jean-Marc
<jmworx> "Merge conflict during commit: Your file or directory 'TODO' is
probably out-of-date: The version resource does not correspond to the
resource within the transaction. Either the requested version resource
is out of date (needs to be updated), or the requested version resource
is newer than the transaction root (restart the commit). at
/usr/local/bin/git-svn line 405"
<jmworx> I'm getting this trying to do a "git-svn dcommit" and I had
done a "git-svn fetch; git-svn rebase" just before that.
<mugwump> jmworx: perhaps send that to the list...
<jmworx> mugwump: What should I say? Don't even know whether it's a bug
or a feature...
<mugwump> that out of date message shouldn't appear if you've
successfully rebased
<mugwump> you could perhaps diagnose by comparing the contents of the
file that you're checking in and the version in the last svn commit in
your git history
<mugwump> was there a merge involved? it might be the "choosing the
wrong base" problem
<jmworx> mugwump: basically, I grabbed the content of svn. Then I
modified the file locally (git) and remotely (svn).
<jmworx> Then I did git-svn fetch and git-svn rebase.
<jmworx> The modifications from the svn were merged (did not conflict).
<jmworx> Then I made another modification locally (git) and committed it.
<jmworx> At last, I attempted to dcommit and got this error.
<mugwump> alright, so you're testing this case - you make a change to
the same file someone else does
<mugwump> so, git-svn will expect that file to have the contents in svn
the same as the last svn commit it knows
<jmworx> shouldn't the rebase have fixed that?
<mugwump> yes
<mugwump> so, find the first commit in `git log` that shows a git-svn-id:
<mugwump> get its commitid, then use: git-cat-file blob commitid:PATH |
md5sum
<mugwump> then use svn cat svnurl/trunk/PATH | md5sum
<mugwump> just to see what's going on
<jmworx> what do I substitute PATH for exactly?
<mugwump> TODO I guess
<jmworx> my svn repo is http://svn.xiph.org/ and I checked out only
trunk/speex
<mugwump> can you share the git repo somewhere temporary? or just the
packfile even
<jmworx> git-cat-file blob commitid:TODO doesn't work
<jmworx> I can upload the git repo if you tell me how (or just a tarball?
<mugwump> well you can just rsync the .git dir to a web server somewhere
<jmworx> http://people.xiph.org/~jm/speex-git.tar.gz
<jmworx> It's only 6 MB
<jmworx> mugwump: Got the tarball?
<mugwump> sorry jmworx was providing internal git support too :)
<mugwump> right, so here's what I did:
<mugwump> git-log shows HEAD~2 as the last SVN commit (ie, includes the
git-svn-id: in the commit message)
<mugwump> the commitid is a9b9f3c
<jmworx> so...
<mugwump> so, I used this to see what git-svn expects the file to be:
<mugwump> git-cat-file blob a9b9f3c:TODO > TODO.gitsvn
<mugwump> svn cat http://svn.xiph.org//trunk/speex/TODO > TODO.svn
<mugwump> however those files are identical
<mugwump> which is good. but makes the error confusing
<jmworx> So the rebased worked?
<mugwump> looks like it
<mugwump> but I'm not sure why your dcommit isn't working ... but that
debugging info will be useful for eric
<jmworx> where should I post then?
<mugwump> git@vger.kernel.org
<jmworx> mugwump: Just to make sure, you're getting the same error while
doing a dcommit?
<mugwump> well no I get authorization failed :)
<jmworx> Right...
<jmworx> Just to make sure, the command is "git-svn dcommit", right?
<mugwump> sure
^ permalink raw reply
* Re: git-svn error msg
From: Eric Wong @ 2007-06-07 6:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <008601c7a844$56dc5030$0e67a8c0@Jocke>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> git-svn init file:///usr/local/src/tst-git-svn/svn-uboot-repo/
> and then
> git-svn fetch yields lots of:
> Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
> Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
> ....
>
> seems to work though.
>
> git version - 1.5.1.3
Probably/hopefully harmless. Although I would like to know what's
causing it, though... Are git-svn-id: lines generated correctly
in your commit messages?
--
Eric Wong
^ permalink raw reply
* Re: git-svn "cannot lock ref" error during fetch
From: Lars Hjemli @ 2007-06-07 6:54 UTC (permalink / raw)
To: Eric Wong; +Cc: James Peach, git
In-Reply-To: <20070607063158.GA2809@muzzle>
On 6/7/07, Eric Wong <normalperson@yhbt.net> wrote:
> James Peach <jamespeach@mac.com> wrote:
> > update-ref -m r13726 refs/remotes/tags/project-92~9
> > 950638ff72acc278156a0d55baafbabb43f2b772: command returned error: 128
> >
> > Some amount of searching failed to turn up any hints on what this
> > error means or how I can work around it. I'd appreciate any advice ...
>
> Is there a tag actually named "project-92~9"? If so, it's
> an invalid branch name for git. I started working on a way
> around it by mapping new names to it, but haven't gotten around to
> finishing it....
>
fwiw: a similar error occurs when a svn tag-/branchname contains
spaces. The culprit seems to be $self->refname in
command_noisy('update-ref', '-m', "r$rev",
$self->refname, $commit);
in rev_db_set()
--
larsh
^ permalink raw reply
* git-cvsimport cannot handle zsh CVS repo
From: Gerrit Pape @ 2007-06-07 7:33 UTC (permalink / raw)
To: git; +Cc: 426617
Hi, I'm stuck tracking down this issue, unfortunately reproducing it
seems to take ages. Any help would be appreciated.
Please see http://bugs.debian.org/426617
---
Package: git-cvs
Version: 1:1.5.1.4-2
Severity: normal
After multiple invocations, I get the following.
% git-cvsimport -v -d :pserver:anonymous@zsh.cvs.sourceforge.net:/cvsroot/zsh zsh
fatal: Needed a single revision
Running cvsps...
WARNING: revision 1.1.1.7.2.1 of file Src/Zle/zle_refresh.c on unnamed branch
[...]
skip patchset 6963: 1180450228 before 1180474771
skip patchset 6964: 1180458067 before 1180474771
skip patchset 6965: 1180474771 before 1180474771
DONE.
fatal: Needed a single revision
Can merge only exactly one commit into empty head
Could not merge origin into the current branch.
---
Thanks, Gerrit.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Bryan Childs @ 2007-06-07 7:57 UTC (permalink / raw)
To: linux@horizon.com; +Cc: git
In-Reply-To: <20070607043632.31891.qmail@science.horizon.com>
On 7 Jun 2007 00:36:32 -0400, linux@horizon.com <linux@horizon.com> wrote:
> There's no reason that git can't do everything you have svn doing.
> What SVN calls "commit access" is what git refers to as "push access",
> but it's exactly the same thing. I don't see how it's the tiniest bit
> more difficult.
<snip>
Thanks for this extremely length and informative reply - it's answered
all our concerns, and we may well move to git sooner rather than later
now!
Bryan
^ permalink raw reply
* [PATCH] gitweb: change filename/directory name of snapshots
From: Matthias Lederhofer @ 2007-06-07 9:27 UTC (permalink / raw)
To: git
/.git or .git is removed from the project name and the
basename of the remaining path is used as the beginning of
the filename and as the directory in the archive.
The regexp will actually not strip off /.git or .git if there
wouldn't be anything left after removing it.
Currently the full project name is used as directory in the
archive and the basename is used as filename. For example a
repository named foo/bar/.git will have a archive named
.git-<version>.* and extract to foo/bar/.git. With this patch
the file is named bar-<version>.* and extracts to bar.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Imho the old behaviour does not make much sense but perhaps there are
users out there relying on the old behaviour. OTOH relying on
a web interface not to change is quite bad, especially if you
could do the same using the git repository which would be much
more reliable.
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e92596c..1777393 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4001,8 +4001,10 @@ sub git_snapshot {
my $git = git_cmd_str();
my $name = $project;
+ $name =~ s,([^/])/*\.git$,$1,;
+ $name = basename($name);
+ my $filename = to_utf8($name);
$name =~ s/\047/\047\\\047\047/g;
- my $filename = to_utf8(basename($project));
my $cmd;
if ($suffix eq 'zip') {
$filename .= "-$hash.$suffix";
--
1.5.2.1.888.gd5e4e
^ permalink raw reply related
* Re: git-svn error msg
From: Joakim Tjernlund @ 2007-06-07 11:22 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070607063723.GB2809@muzzle>
On Wed, 2007-06-06 at 23:37 -0700, Eric Wong wrote:
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > git-svn init file:///usr/local/src/tst-git-svn/svn-uboot-repo/
> > and then
> > git-svn fetch yields lots of:
> > Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
> > Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
> > ....
> >
> > seems to work though.
> >
> > git version - 1.5.1.3
>
> Probably/hopefully harmless. Although I would like to know what's
> causing it, though... Are git-svn-id: lines generated correctly
> in your commit messages?
>
Well, can't tell since I can't commit.
This is whats I did(from http://utsl.gen.nz/talks/git-svn/intro.html#howto-track )
git clone -l /usr/local/src/tm-uboot/u-boot my-uboot2.clone
git-config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git-svn init file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk
git-svn fetch
The /usr/local/src/tm-uboot/u-boot is a repo that is using git-svn and I wan't
to clone it.
git svn fetch ended with:
Done rebuilding .git/svn/git-svn/.rev_db.17788414-8b20-0410-8e02-ac2c1e7fead6
D lib_i386/Makefile
D lib_i386/bios.S
D lib_i386/bios.h
.....
D drivers/videomodes.h
D drivers/w83c553f.c
D drivers/
W: -empty_dir: trunk/board
W: -empty_dir: trunk/common
W: -empty_dir: trunk/cpu
W: -empty_dir: trunk/disk
W: -empty_dir: trunk/doc
W: -empty_dir: trunk/drivers
W: -empty_dir: trunk/dtt
W: -empty_dir: trunk/examples
W: -empty_dir: trunk/fs
W: -empty_dir: trunk/include
W: -empty_dir: trunk/lib_arm
W: -empty_dir: trunk/lib_blackfin
W: -empty_dir: trunk/lib_generic
W: -empty_dir: trunk/lib_i386
W: -empty_dir: trunk/lib_m68k
W: -empty_dir: trunk/lib_microblaze
W: -empty_dir: trunk/lib_mips
W: -empty_dir: trunk/lib_nios
W: -empty_dir: trunk/lib_nios2
W: -empty_dir: trunk/lib_ppc
W: -empty_dir: trunk/nand_spl
W: -empty_dir: trunk/net
W: -empty_dir: trunk/post
W: -empty_dir: trunk/rtc
W: -empty_dir: trunk/tools
Last fetched revision of refs/remotes/git-svn was r76, but we are about to fetch: r1!
If I try to commit I get:
git svn dcommit
Unable to determine upstream SVN information from HEAD history
Note: the file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk is a local
copy of the real subversion repo.
^ permalink raw reply
* [PATCH 2/2] Quiet the output from git-init when cloning, if requested.
From: Jeffrey C. Ollie @ 2007-06-07 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Jeffrey C. Ollie
In-Reply-To: <11812206303473-git-send-email-jeff@ocjtech.us>
From: Jeffrey C. Ollie <jeff@ocjtech.us>
Now that git-init has an option to quiet itself, use it if the -q
option was specified on the clone command line.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index fdd354f..4cc09e3 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -184,7 +184,7 @@ yes)
GIT_DIR="$D" ;;
*)
GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init ${template+"$template"} || usage
+esac && export GIT_DIR && git-init $quiet ${template+"$template"} || usage
if test -n "$reference"
then
--
1.5.2.GIT
^ permalink raw reply related
* [PATCH 1/2] Add an option to quiet git-init.
From: Jeffrey C. Ollie @ 2007-06-07 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Jeffrey C. Ollie
git-init lacks an option to suppress non-error and non-warning output -
this patch adds one.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
---
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 6 +++++-
builtin-init-db.c | 14 +++++++++-----
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 5412135..64e7fc1 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -8,7 +8,7 @@ git-init-db - Creates an empty git repository
SYNOPSIS
--------
-'git-init-db' [--template=<template_directory>] [--shared[=<permissions>]]
+'git-init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
DESCRIPTION
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 1b64d3a..b5d17ee 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one
SYNOPSIS
--------
-'git-init' [--template=<template_directory>] [--shared[=<permissions>]]
+'git-init' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
@@ -16,6 +16,10 @@ OPTIONS
--
+-q, \--quiet::
+
+Only print error and warning messages, all other output will be suppressed.
+
--template=<template_directory>::
Provide the directory from which templates will be used. The default template
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 4df9fd0..68b2a1e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -265,7 +265,7 @@ static int create_default_files(const char *git_dir, const char *template_path)
}
static const char init_db_usage[] =
-"git-init [--template=<template-directory>] [--shared]";
+"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -280,6 +280,7 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *template_dir = NULL;
char *path;
int len, i, reinit;
+ int quiet = 0;
for (i = 1; i < argc; i++, argv++) {
const char *arg = argv[1];
@@ -289,6 +290,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
shared_repository = git_config_perm("arg", arg+9);
+ else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
+ quiet = 1;
else
usage(init_db_usage);
}
@@ -335,10 +338,11 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
- printf("%s%s Git repository in %s/\n",
- reinit ? "Reinitialized existing" : "Initialized empty",
- shared_repository ? " shared" : "",
- git_dir);
+ if (!quiet)
+ printf("%s%s Git repository in %s/\n",
+ reinit ? "Reinitialized existing" : "Initialized empty",
+ shared_repository ? " shared" : "",
+ git_dir);
return 0;
}
--
1.5.2.GIT
^ permalink raw reply related
* git-log fatal error in empty repo
From: Steve Hoelzer @ 2007-06-07 13:34 UTC (permalink / raw)
To: git
git-log will return a fatal error for an empty repo, like so:
$ git --version
git version 1.5.2.73.g18bece
$ mkdir mytest
$ cd mytest
$ git-init
Initialized empty Git repository in .git/
$ git-log
fatal: bad default revision 'HEAD'
It would be nice if git-log was quiet or returned a "no log" message
instead of the fatal error.
Steve
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Nicolas Pitre @ 2007-06-07 13:38 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <466793EB.2060102@vilain.net>
On Thu, 7 Jun 2007, Sam Vilain wrote:
> Nicolas Pitre wrote:
> >> 2. repack takes too long to run very regularly; it's an occasional
> >> command.
> > It doesn't take long at all when you don't use -a.
>
> Well that depends how many loose objects there are :) I heard about on
> Windows a case where packing 30k loose objects took over an hour.
And your patch cannot change anything to that, right?
You shouldn't wait until 30k loose objects accumulate before repacking.
> >> What I'm aiming for is something which is light enough that it might
> >> even win back the performance loss you got from 1), and to solve the
> >> perception problem of 3).
> >
> > Run git-repack without -a from some hook. You can even launch it in the
> > background.
> >
> > Or what am I missing?
>
> If you repack every 100 objects without -a, sure it will be fast, but
> you'll end up with too many packs.
You just need to adjust this treshold of 100 objects.
And latest GIT behaves _much_ better with lots of packs, almost like if
there was only one pack. See the test results I posted to the list.
Nicolas
^ permalink raw reply
* Re: git-svn dcommit failure
From: Florian Weimer @ 2007-06-07 14:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070605101744.GA12948@muzzle>
* Eric Wong:
>> After manually committing the offending changes via Subversion, I
>> git-svn has begun to work again, too (but I haven't yet tried to
>> change the same files).
>
> Would upgrading to 1.5.2 final have helped?
I've upgraded to this version, but since it's not exactly trivial for
me to test this on the Subversion side, it'll take some time until I
can be confident that the bug was indeed fixed in the
6442754d6cc0056cf5b69b43d218f8b6d317e7f5 revision.
Is there some kind of magic environment variable I could set to get
tracing information? If such bugs turn up, I'd try to debug them on
my own and submit a fix, or at least a reproduction recipe. (The
repository itself may contain personally identifiable information in
test cases and hence, cannot be shared.)
^ permalink raw reply
* Re: git does the wrong thing with ambiguous names
From: Brandon Casey @ 2007-06-07 14:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070607000100.GE3969@steel.home>
Alex Riesen wrote:
> Alex Riesen, Thu, Jun 07, 2007 01:33:27 +0200:
>> Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
>>> Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
[snip]
> This one is much shorter and less friendly. Suggested by Junio on irc.
> It makes checkout always prefer a branch.
>
> diff --git a/git-checkout.sh b/git-checkout.sh
> index 6b6facf..282c84f 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -67,6 +67,8 @@ while [ "$#" != "0" ]; do
> new_name="$arg"
> if git-show-ref --verify --quiet -- "refs/heads/$arg"
> then
> + rev=$(git-rev-parse --verify "refs/heads/$arg^0" 2>/dev/null)
> + new="$rev"
> branch="$arg"
> fi
> elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
>
This doesn't work.
Now the working directory contents are never updated when switching
branches.
Run my test script, or add an 'echo "some data" > a' in your shell code
so that the two branches have different contents.
-brandon
^ permalink raw reply
* Re: git does the wrong thing with ambiguous names
From: Brandon Casey @ 2007-06-07 14:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070606233327.GD3969@steel.home>
Alex Riesen wrote:
> Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
>> Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
>>> When a branch and tag have the same name, a git-checkout using that name
>>> succeeds (exits zero without complaining), switches to the _branch_, but
>>> updates the working directory contents to that specified by the _tag_.
>>> git-status show modified files.
>> Bad. To reproduce:
>>
>> mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
>> :>b && git add . && git commit -m2 && git tag master HEAD^ &&
>> find .git/refs/ && gco -b new && gco master && git status
>>
>
> git-rev-parse actually warns about ambguities:
>
> $ git-rev-parse --verify master
> warning: refname 'master' is ambiguous.
> dd5cdc387f2160bf04d02ac08dfdaf952f769357
>
> It's just that the warning is thrown away in git-checkout.sh
>
> A quick and _very_ messy fix could like like that:
[snip patch]
This one suffers from what Junio described previously on the mailing
list, when get_sha1_basic() fails, get_sha1_1() continues trying
alternatives. The risk is that one of those alternatives could match,
for example if the ambiguous branch and tag name is 'dead'.
-brandon
^ permalink raw reply
* [PATCH] cvsserver: Make req_Root more critical of its input data
From: Frank Lichtenheld @ 2007-06-07 14:57 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
The path submitted with the Root request has to be absolute
(cvs does it this way and it may save us some sanity checks
later)
If multiple roots are specified (e.g. because we use
pserver authentication which will already include the
root), ensure that they say all the same.
Probably neither is a security risk, and neither should ever
be triggered by a sane client, but when validating
input data, it's better to be save than sorry.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 11 +++++++++++
t/t9400-git-cvsserver-server.sh | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 2b4825a..d41b29f 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -167,6 +167,17 @@ sub req_Root
my ( $cmd, $data ) = @_;
$log->debug("req_Root : $data");
+ unless ($data =~ m#^/#) {
+ print "error 1 Root must be an absolute pathname\n";
+ return 0;
+ }
+
+ if ($state->{CVSROOT}
+ && ($state->{CVSROOT} ne $data)) {
+ print "error 1 Conflicting roots specified\n";
+ return 0;
+ }
+
$state->{CVSROOT} = $data;
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index e9ef315..41dcf64 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -110,6 +110,40 @@ test_expect_success 'pserver authentication failure (login/non-anonymous user)'
tail -n1 log | grep -q "^I HATE YOU$"'
+# misuse pserver authentication for testing of req_Root
+
+cat >request-relative <<EOF
+BEGIN AUTH REQUEST
+gitcvs.git
+anonymous
+
+END AUTH REQUEST
+EOF
+
+cat >request-conflict <<EOF
+BEGIN AUTH REQUEST
+$SERVERDIR
+anonymous
+
+END AUTH REQUEST
+Root $WORKDIR
+EOF
+
+test_expect_success 'req_Root failure (relative pathname)' \
+ 'if cat request-relative | git-cvsserver pserver >log 2>&1
+ then
+ echo unexpected success
+ false
+ else
+ true
+ fi &&
+ tail log | grep -q "^error 1 Root must be an absolute pathname$"'
+
+test_expect_success 'req_Root failure (conflicting roots)' \
+ 'cat request-conflict | git-cvsserver pserver >log 2>&1 &&
+ tail log | grep -q "^error 1 Conflicting roots specified$"'
+
+
#--------------
# CONFIG TESTS
#--------------
--
1.5.2.1
^ permalink raw reply related
* [PATCH] cvsserver: Add some useful commandline options
From: Frank Lichtenheld @ 2007-06-07 14:57 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <1181228221959-git-send-email-frank@lichtenheld.de>
Make git-cvsserver understand some options inspired by
git-daemon, namely --base-path, --export-all, --strict-paths.
Also allow the caller to specify a whitelist of allowed
directories, again similar to git-daemon.
While already adding option parsing also support the common
--help and --version options.
Rationale:
While the gitcvs.enabled configuration option already
offers means to limit git-cvsserver access to a repository,
there are some use cases where other methods of access
control prove to be more useful.
E.g. if setting up a pserver for a collection of public
repositories one might want limit the exported repositories
to exactly the directory this collection is located whithout
having to worry about other repositories that might lie around
with the configuration variable set (never trust your users ;)
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-cvsserver.txt | 42 ++++++++++++++++++++
git-cvsserver.perl | 79 ++++++++++++++++++++++++++++++++++++---
t/t9400-git-cvsserver-server.sh | 28 ++++++++++++++
3 files changed, 143 insertions(+), 6 deletions(-)
--interpolated-path can't be supported because the information isn't
available in CVS protocoll.
--user-path could be supported, I just hadn't motivation/time enough to
do that.
The documentation part of the patch could probably use some improvement
still.
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index e5005f0..6d1e311 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -7,10 +7,52 @@ git-cvsserver - A CVS server emulator for git
SYNOPSIS
--------
+
+SSH:
+
[verse]
export CVS_SERVER=git-cvsserver
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+pserver (/etc/inetd.conf):
+
+[verse]
+cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+Usage:
+
+[verse]
+'git-cvsserver' [options] [pserver|server] [<directory> ...]
+
+OPTIONS
+-------
+
+All these options obviously only make sense if enforced by the server side.
+They have been implemented to resemble the gitlink:git-daemon[1] options as
+closely as possible.
+
+--base-path <path>::
+Prepend 'path' to requested CVSROOT
+
+--strict-paths::
+Don't allow recursing into subdirectories
+
+--export-all::
+Don't check for `gitcvs.enabled` in config
+
+--version, -V::
+Print version information and exit
+
+--help, -h, -H::
+Print usage information and exit
+
+<directory>::
+You can specify a list of allowed directories. If no directories
+are given, all are allowed. This is an additional restriction, gitcvs
+access still needs to be enabled by the `gitcvs.enabled` config option
+unless '--export-all' was given, too.
+
+
DESCRIPTION
-----------
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index d41b29f..9fbd9db 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -22,6 +22,9 @@ use bytes;
use Fcntl;
use File::Temp qw/tempdir tempfile/;
use File::Basename;
+use Getopt::Long qw(:config require_order no_ignore_case);
+
+my $VERSION = '@@GIT_VERSION@@';
my $log = GITCVS::log->new();
my $cfg;
@@ -85,15 +88,52 @@ my $methods = {
my $state = { prependdir => '' };
$log->info("--------------- STARTING -----------------");
+my $usage =
+ "Usage: git-cvsserver [options] [pserver|server] [<directory> ...]\n".
+ " --base-path <path> : Prepend to requested CVSROOT\n".
+ " --strict-paths : Don't allow recursing into subdirectories\n".
+ " --export-all : Don't check for gitcvs.enabled in config\n".
+ " --version, -V : Print version information and exit\n".
+ " --help, -h, -H : Print usage information and exit\n".
+ "\n".
+ "<directory> ... is a list of allowed directories. If no directories\n".
+ "are given, all are allowed. This is an additional restriction, gitcvs\n".
+ "access still needs to be enabled by the gitcvs.enabled config option.\n";
+
+my @opts = ( 'help|h|H', 'version|V',
+ 'base-path=s', 'strict-paths', 'export-all' );
+GetOptions( $state, @opts )
+ or die $usage;
+
+if ($state->{version}) {
+ print "git-cvsserver version $VERSION\n";
+ exit;
+}
+if ($state->{help}) {
+ print $usage;
+ exit;
+}
+
my $TEMP_DIR = tempdir( CLEANUP => 1 );
$log->debug("Temporary directory is '$TEMP_DIR'");
+$state->{method} = 'ext';
+if (@ARGV) {
+ if ($ARGV[0] eq 'pserver') {
+ $state->{method} = 'pserver';
+ shift @ARGV;
+ } elsif ($ARGV[0] eq 'server') {
+ shift @ARGV;
+ }
+}
+
+# everything else is a directory
+$state->{allowed_roots} = [ @ARGV ];
+
# if we are called with a pserver argument,
# deal with the authentication cat before entering the
# main loop
-$state->{method} = 'ext';
-if (@ARGV && $ARGV[0] eq 'pserver') {
- $state->{method} = 'pserver';
+if ($state->{method} eq 'pserver') {
my $line = <STDIN>; chomp $line;
unless( $line =~ /^BEGIN (AUTH|VERIFICATION) REQUEST$/) {
die "E Do not understand $line - expecting BEGIN AUTH REQUEST\n";
@@ -178,13 +218,40 @@ sub req_Root
return 0;
}
- $state->{CVSROOT} = $data;
+ $state->{CVSROOT} = $state->{'base-path'} || '';
+ $state->{CVSROOT} =~ s#/+$##;
+ $state->{CVSROOT} .= $data;
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
+
+ if (@{$state->{allowed_roots}}) {
+ my $allowed = 0;
+ foreach my $dir (@{$state->{allowed_roots}}) {
+ next unless $dir =~ m#^/#;
+ $dir =~ s#/+$##;
+ if ($state->{'strict-paths'}) {
+ if ($ENV{GIT_DIR} =~ m#^\Q$dir\E/?$#) {
+ $allowed = 1;
+ last;
+ }
+ } elsif ($ENV{GIT_DIR} =~ m#^\Q$dir\E(/?$|/)#) {
+ $allowed = 1;
+ last;
+ }
+ }
+
+ unless ($allowed) {
+ print "E $ENV{GIT_DIR} does not seem to be a valid GIT repository\n";
+ print "E \n";
+ print "error 1 $ENV{GIT_DIR} is not a valid repository\n";
+ return 0;
+ }
+ }
+
unless (-d $ENV{GIT_DIR} && -e $ENV{GIT_DIR}.'HEAD') {
print "E $ENV{GIT_DIR} does not seem to be a valid GIT repository\n";
- print "E \n";
- print "error 1 $ENV{GIT_DIR} is not a valid repository\n";
+ print "E \n";
+ print "error 1 $ENV{GIT_DIR} is not a valid repository\n";
return 0;
}
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 41dcf64..392f890 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -143,6 +143,34 @@ test_expect_success 'req_Root failure (conflicting roots)' \
'cat request-conflict | git-cvsserver pserver >log 2>&1 &&
tail log | grep -q "^error 1 Conflicting roots specified$"'
+test_expect_success 'req_Root (strict paths)' \
+ 'cat request-anonymous | git-cvsserver --strict-paths pserver $SERVERDIR >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_failure 'req_Root failure (strict-paths)' \
+ 'cat request-anonymous | git-cvsserver --strict-paths pserver $WORKDIR >log 2>&1'
+
+test_expect_success 'req_Root (w/o strict-paths)' \
+ 'cat request-anonymous | git-cvsserver pserver $WORKDIR/ >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_failure 'req_Root failure (w/o strict-paths)' \
+ 'cat request-anonymous | git-cvsserver pserver $WORKDIR/gitcvs >log 2>&1'
+
+cat >request-base <<EOF
+BEGIN AUTH REQUEST
+/gitcvs.git
+anonymous
+
+END AUTH REQUEST
+EOF
+
+test_expect_success 'req_Root (base-path)' \
+ 'cat request-base | git-cvsserver --strict-paths --base-path $WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_failure 'req_Root failure (base-path)' \
+ 'cat request-anonymous | git-cvsserver --strict-paths --base-path $WORKDIR pserver $SERVERDIR >log 2>&1'
#--------------
# CONFIG TESTS
--
1.5.2.1
^ permalink raw reply related
* Re: git-svn "cannot lock ref" error during fetch
From: James Peach @ 2007-06-07 15:37 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070607063158.GA2809@muzzle>
On Jun 6, 2007, at 11:31 PM, Eric Wong wrote:
> James Peach <jamespeach@mac.com> wrote:
>> Hi all,
>>
>> I'm new to git, and I'm experimenting with using git-svn to interact
>> with a large SVN repository with lots of branches.
>>
>> I initially did an init like this:
>>
>> git-svn init -t tags -b branches -T trunk svn+ssh://server/svn/
>> project
>>
>> Then I did a git-svn fetch, which started pulling all the branches.
>> After a while, however, it hit a branch that it couldn't pull:
>>
>> Found branch parent: (tags/project-92~9)
>> 767f1f1601a4deae459c99ea6c1d1b9ba8f57a65
>> Following parent with do_update
>> ...
>> Successfully followed parent
>> fatal: refs/remotes/tags/project-92~9: cannot lock the ref
>> update-ref -m r13726 refs/remotes/tags/project-92~9
>> 950638ff72acc278156a0d55baafbabb43f2b772: command returned error: 128
>>
>> Some amount of searching failed to turn up any hints on what this
>> error means or how I can work around it. I'd appreciate any
>> advice ...
>
> Is there a tag actually named "project-92~9"?
unfortunately, there's more than one tag with this naming convention :(
> If so, it's
> an invalid branch name for git. I started working on a way
> around it by mapping new names to it, but haven't gotten around to
> finishing it....
Aha! I don't really need 90% of the tags - is there a way I can tell
the "git-svn fetch" not to bother with particular tags?
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: linux @ 2007-06-07 16:51 UTC (permalink / raw)
To: godeater, linux; +Cc: git
In-Reply-To: <5971b1ba0706070057l2d4b170emd8af733d888d6a56@mail.gmail.com>
> Thanks for this extremely length and informative reply - it's answered
> all our concerns, and we may well move to git sooner rather than later
> now!
You're welcome. You just seemed to be under some misapprehension.
Git can certainly do all the basic things that svn does, and just
as easily.
You'll only have to learn more because you'll want to do more.
There are three big things that you'll want to get used to
when coming from CVS or any other centralized version system:
1) Don't blink, you might miss it. If you're used to CVS, you might
wonder whether git actually *did* anything. Commits, in particular,
are instantaneous if the necessary data is cached in RAM, and it can
take a while to learn to trust that everything worked.
2) Commits can be undone. It can be a bit scary the way a command
like git-rebase will make a whole bunch if repository changes and
then maybe get stuck with a patch conflict. You want to be
comfortable undoing things, or amending commits if you're
not happy with what happened.
This is why novices (and I used to be one) are reassured by the
existence of "git merge --no-commit", but experienced users don't
see the point.
With git, pushing (or asking someone else to pull) is the
moment of truth. Committing has no lasting consequences.
3) Branches are your friend. CVS users think branches are a big
deal and require careful thought and planning. Git users branch
almost as often as CVS users commit. A typical "big change"
that might be a single commit in CVS would be a branch of
several commits in git.
In fact, a good piece of advice is to NEVER commit directly
to your trunk ("master"). Do ALL development on branches, and
merge them into the trunk.
I cheat on that a lot, but I also know how to fix things if I get
caught becauee a quick hack is proving not so quick: add a branch
reference to the tip I'm developing on and then back up the master
branch to where I should have left it when I started this project.
^ permalink raw reply
* git-svn removes merge
From: Joakim Tjernlund @ 2007-06-07 17:08 UTC (permalink / raw)
To: git
If I do this:
git checkout --track -b svn remotes/trunk
git checkout -b merge
git-am ../mbox
git checkout svn
#edit Makefile and commit
git-svn dcommit #Note 1
git pull . merge
git-svn dcommit
then git-svn dcommit removes the merge beteen svn and merge.
git log svn..merge shows all the commits that git-am ../mbox added.
How do I avoid this?
Jocke
Note 1:
If I skip this step then the last git-svn dcommit fails, why is that?
^ permalink raw reply
* Re: pull/merge --no-commit
From: kurt_p_lloyd @ 2007-06-07 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy54qqu8.fsf@assigned-by-dhcp.cox.net>
comments intermixed below
Junio C Hamano wrote:
> kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:
>
>> I run: git pull --no-commit ssh://<blah blah blah>
>>
>> then I run: git status
>>
>> it says: nothing to commit (working directory clean)
>>
>> then I run: git log
>>
>> it shows the commit message from the other user below a
>> commit sha1, and the change I pulled was indeed merged to
>> my file.
>>
>> Does this seem to be a bug, or am I doing something wrong?
>
> No bug, no user error.
>
> I suspect you did not have _ANY_ of your own development.
Spot on :)
> If that is the case, then it worked as you told it to. You asked
> no merge commit to be made, and it did not create a new merge
> commit.
Ah, the difference in terminology biting me here .... I'm used to
ClearCase, where the term "merge" includes so-called "trivial merges",
where a change is merely copied from one branch to another,
with no parallel changes on the receiving branch.
> Illustration. Earlier you had (probably your git-clone created
> this) this history:
>
> ---A---B---C---D
> ^ HEAD
>
> and your tip of the branch (and HEAD) was at commit D. You did
> not do any of your own development yourself, and then you pulled.
>
> In the meantime, the other repository had been busily working
> and has a few more commits:
>
> ---A---B---C---D---E---F---G---H
> ^ ^
> Your HEAD The tip of the branch you
> was here. pulled is here.
>
> In this case, because you do not have anything new to add to the
> history (remember, git history is a global DAG -- you and the
> other repository are building it by pushing and pulling), we
> move your HEAD to H (the tip of the branch you are pulling).
> There is no need to create a new merge commit, with or without
> the --no-commit option. This is called "fast forward".
Except here's the model that I am trying to follow....
It seems that 'pull' can be partitioned into 3 separate responsibilities:
1. Retrieve changes from the remote user's replica (without modifying
any /local/ branches).
2. Bring changes from "remote" into a local branch (without commit).
3. Commit.
My thoughts are that if I could have these be 3 different, sequential steps,
after step 1 I could peruse the "database" to see what "remote" changed, and
whether or not I may like such changes, and would want to /consider/ "taking"
them. If no then I do nothing. If yes then I do step 2.
After step 2 I may find that I don't really like those changes after all.
I only commit if I really do like those changes.
I don't want to overdo it here on the ClearCase stuff, but this
scenario is one which is very natural in that system:
1. multisite syncreplica
2. cleartool merge # even for "trivial merges"
3. cleartool checkin (or cleartool uncheckout if I don't like the changes)
more way below
> In a more interesting case, you will see a different behaviour.
> Let's suppose you started from the same state (i.e. cloned up to
> D), and built your own changes on top of it:
>
> Your HEAD
> v
> X---Y---Z
> /
> ---A---B---C---D
>
> while the other repository had the same E...H development line.
> You pull from them. Remember, pull is a fetch followed by a
> merge. After the fetch, you get this:
>
> Your HEAD
> v
> X---Y---Z
> /
> ---A---B---C---D---E---F---G---H
> ^
> The tip of the branch you
> pulled is here.
>
> This is not a "fast forward" situation and "git pull" would need
> a new merge commit, like this:
>
> Your HEAD used to be here
> v
> X---Y---Z-------M <- A new merge commit
> / / becomes HEAD
> ---A---B---C---D---E---F---G---H
> ^
> The tip of the branch you
> pulled is here.
>
> What --no-commit does is to prepare a tree to be used to create
> the merge commit "M", without actually creating a commit. So if
> you did "git pull --no-commit", your HEAD would stay at Z and
> your index and working tree is prepared to create the tree
> suitable to be committed as "M". After that, you have a chance
> to make further changes to your working tree before creating a
> commit with "git commit", to affect what is recorded in the
> resulting merge commit "M".
>
> In the case of "fast forward", --no-commit still moves the HEAD,
> and this is deliberate. Imagine if we did not move the head.
> Because the merge is "fast forward" in reality, what is left in
> the index and the working tree to be committed should exactly
> match what is in H. You may futz with the working tree further
> before actually creating the commit, and the next "git commit"
> would give you this graph:
>
> .---------------M
> / /
> ---A---B---C---D---E---F---G---H
> ^ ^
> Your HEAD The tip of the branch you
> is still here. pulled is here.
>
> The difference between H and M is strictly what you did to the
> index and the working tree between "pull --no-commit" and
> "commit".
>
> That is insane. Why? Because what you really did was to start
> from the tree of H, did your own development (i.e. "diff H M"),
> and made a commit. This is the reason why --no-commit does not
> do anything special when the pull is a fast forward.
>
> The resulting history should not be the above merge, but just
> like this:
>
> ---A---B---C---D---E---F---G---H---M
>
> You did a "fast forward", and did your own development to make a
> single commit, which is what this history should look like.
> There was no merge performed. Just a straight line of
> development on top of what you got from the other side.
I must compliment you on your excellent communication.
Maybe there is a different workflow to effectively achieve what
I want via steps 1, 2, and 3 (way above). In other words, OK I do
a 'pull', and all 3 steps occur together. Then suppose that I
contemplate the changes that got committed, and that I disapprove
of either a majority or all of those changes. I'd like to be able
to cleanly and easily recover from this with no related commits and
"revert commits" in git log. I'll add my own deliberate commits if
and when I decide that I really /would/ like some or all of those
changes eventually, in which case I would still like the proper
context to exist in the "database" for me to bring the selective
remote changes into my local branch in a natural way.
Are there git commands to best cover this scenario?
Kind regards,
-Kurt
^ permalink raw reply
* Re: pull/merge --no-commit
From: Junio C Hamano @ 2007-06-07 18:58 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: git
In-Reply-To: <46684EFD.1080804@alcatel-lucent.com>
kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:
> Maybe there is a different workflow to effectively achieve what
> I want via steps 1, 2, and 3 (way above). In other words, OK I do
> a 'pull', and all 3 steps occur together. Then suppose that I
> contemplate the changes that got committed, and that I disapprove
> of either a majority or all of those changes. I'd like to be able
> to cleanly and easily recover from this with no related commits and
> "revert commits" in git log.
Let's say you did this:
$ git pull $other_party
A "pull" is a "fetch" (download their history and objects)
followed by a "merge" (integrate that history with your
history). When it goes without merge conflicts you need to
resolve by hand, the above will move your HEAD to reflect the
new histroy of your project, including the fact that you merged
with the $other_party, at this point. The above command gives
you the overview of the change in the form of diffstat.
You would naturally want to inspect and convince yourself that
you did not pull crap from the $other_party. A special symbol
ORIG_HEAD is set up after a "merge" (be it a "fast forward" or a
true merge) that lets you easily access where the tip of your
branch was before the merge.
To view the damage the $other_party inflicted on you as a whole:
$ git diff ORIG_HEAD..
Or to inspect individual patches:
$ git log -p ORIG_HEAD..
Some people seem to prefer "git log --reverse -p ORIG_HEAD..",
which would give their changes in chronological order.
If it turns out that you pulled crap from the $other_party, you
can get rid of that away from the history of your branch with:
$ git reset --hard ORIG_HEAD
> I'll add my own deliberate commits if
> and when I decide that I really /would/ like some or all of those
> changes eventually, in which case I would still like the proper
> context to exist in the "database" for me to bring the selective
> remote changes into my local branch in a natural way.
In git managed projects that care about the readability of
global history, this often is done by asking $other_party to
redo the branch, discarding broken/undesirable bits.
But if you do not have the clout to do so over the $other_party,
then you could, after the above sequence, cherry pick good bits
from what the $other_party has and you don't. This however will
make your history and their history to have different commits
that record the result of the same patch application; if you
later pull from the $other_party again, you will end up having
two copies of the (logically) same commit in your history.
^ permalink raw reply
* Re: pull/merge --no-commit
From: Kevin Green @ 2007-06-07 18:59 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: git
In-Reply-To: <46684EFD.1080804@alcatel-lucent.com>
On 06/07/07 14:31:25, kurt_p_lloyd wrote:
> Junio C Hamano wrote:
> >
> >
> > In this case, because you do not have anything new to add to the
> > history (remember, git history is a global DAG -- you and the
> > other repository are building it by pushing and pulling), we
> > move your HEAD to H (the tip of the branch you are pulling).
> > There is no need to create a new merge commit, with or without
> > the --no-commit option. This is called "fast forward".
>
> Except here's the model that I am trying to follow....
> It seems that 'pull' can be partitioned into 3 separate responsibilities:
>
> 1. Retrieve changes from the remote user's replica (without modifying
> any /local/ branches).
> 2. Bring changes from "remote" into a local branch (without commit).
> 3. Commit.
>
I'm new to git and trying to pick it up and learn this week!! :)
I think what you want is:
$ git fetch
$ git merge origin/master
You want to fetch the remote changes into a separate branch and then probably
check the log to see what's changed... Once you're happy, merge the branches.
Git will still fast-forward because you haven't made any local changes.
--Kevin
^ permalink raw reply
* Re: git-cvsimport cannot handle zsh CVS repo
From: Martin Langhoff @ 2007-06-07 19:19 UTC (permalink / raw)
To: git, 426617
In-Reply-To: <20070607073336.26979.qmail@178148a41cee98.315fe32.mid.smarden.org>
On 6/7/07, Gerrit Pape <pape@smarden.org> wrote:
> Hi, I'm stuck tracking down this issue, unfortunately reproducing it
> seems to take ages. Any help would be appreciated.
>
> Please see http://bugs.debian.org/426617
This is probably a problem with cvsps output on that repo. If you run
cvsps against the cvs repo, what does its output look like around/past
patchset 6965
There's a number of things that can confuse cvsps, as the cvs repo
format is horrid.
cheers,
martin
^ permalink raw reply
* Re: pull/merge --no-commit
From: Keith Duthie @ 2007-06-07 19:12 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: Junio C Hamano, git
In-Reply-To: <46684EFD.1080804@alcatel-lucent.com>
On Thu, 7 Jun 2007, kurt_p_lloyd wrote:
> Except here's the model that I am trying to follow....
> It seems that 'pull' can be partitioned into 3 separate responsibilities:
>
> 1. Retrieve changes from the remote user's replica (without modifying
> any /local/ branches).
> 2. Bring changes from "remote" into a local branch (without commit).
> 3. Commit.
I believe you can accomplish step one with a remote tracking branch
("git-remote add localname git://whereever/project.git" to add the branch
to the repository, then "git-remote update localname" to update it to the
current remote state).
--
The universe hates you, but don't worry - it's nothing personal.
^ 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