* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: Jan Hudec @ 2008-09-15 17:12 UTC (permalink / raw)
To: David Miller; +Cc: gitster, peterz, git, linux-kernel
In-Reply-To: <20080913.013330.29519747.davem@davemloft.net>
On Sat, Sep 13, 2008 at 01:33:30 -0700, David Miller wrote:
> As a followup this turned out to be the classic "PATH when doing GIT over
> SSH" problem.
>
> I have to say this is very unfun to debug, and even less fun to "fix"
> even once you know this is the problem. And what's more I know this is
> the second time I've had to spend a night debugging this very problem.
>
> I ended up having to make a ~/.ssh/environment file and then restart my
> SSH server with "PermitUserEnvironment yes" added to sshd_config.
>
> But I can't believe this is what I have to do just to pull from a machine
> where I have GIT only installed in my home directory. What if I were just
> a normal user and couldn't change the SSHD config? What hoops would I
> need to jump through to get my PATH setup correctly? :)
>
> It doesn't even work to put ~/bin into the PATH listed in the system wide
> /etc/environment, because that does not do tilde expansion, SSHD just takes
> it as-is.
>
> Wouldn't it make sense to put the bindir into PATH when we try to do
> execv_git_cmd()? The code has already put the gitexecdir into the
> PATH at this point.
I don't think it gets to execv_git_cmd(). Git on local side will run
ssh <host> git upload-pack
and it's ssh that can't find git in ~/bin (or maybe it's still using the
dashed form for backward compatibility; the argument stands either way).
There are two possible solutions (besides the .ssh/environment one):
1. Without hacking git: Use a separate key pair for git access and configure
that key on the server with 'command="/home/you/bin/git-shell"' option in
.ssh/authorized_keys. Git shell should run the command from exec-dir
properly.
2. Hack git to support some variable to set the remote command for ssh
protocol.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-15 16:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080915075740.GB14452@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
2008/9/15 Karl Hasselström <kha@treskal.com>:
> On 2008-09-14 22:19:41 +0100, Catalin Marinas wrote:
>
>> I wasn't used to reading documentation in StGit files :-). Thanks
>> for the info, I'll repost.
>
> It was you who asked for in-code docs. :-) The new-infrastructure code
> actually looks half decent in epydoc nowadays.
Since we are talking about this, the transactions documentation
doesn't explain when to use a iw and when to pass allow_conflicts. I
kind of figured out but I'm not convinced. At a first look, passing
allow_conflicts = True would seem that it may allow conflicts and not
revert the changes, however, this only works if I pass an "iw". But
passing it doesn't allow the default case where I want the changes
reverted.
Please have a look at the attached patch which is my last version of
the sink command rewriting. I'm not that happy (or maybe I don't
understand the reasons) with setting iw = None if not options.conflict
but that's the way I could get it to work.
>> I'll make the default behaviour to cancel the transaction and revert
>> to the original state unless an option is given to allow conflicts.
>
> What I've always wanted is "sink this patch as far as it will go
> without conflicting". This comes awfully close.
But this means that sink would try several consecutive sinks until it
can't find one. Not that it is try to implement but I wouldn't
complicate "sink" for this. I would rather add support for patch
dependency tracking (which used to be on the long term wish list). It
might be useful for other things as well like mailing a patch together
with those on which it depends (like darcs).
> BTW, this kind of flag might potentially be useful in many commands
> (with default value on or off depending on the command). Maybe
>
> --conflicts=roll-back|stop-before|allow
ATM, I only added a --conflict option which has the "allow" meaning.
--
Catalin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: convert-sink-to-the-new-infras.patch --]
[-- Type: text/x-diff; name=convert-sink-to-the-new-infras.patch, Size: 7706 bytes --]
Convert "sink" to the new infrastructure
From: Catalin Marinas <catalin.marinas@gmail.com>
This patch converts the sink command to use stgit.lib. By default, the
command doesn't allow conflicts and it cancels the operations if patches
cannot be reordered cleanly. With the --conflict options, the command
stops after the first conflict during the push operations.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/sink.py | 90 +++++++++++++++++++++++++++++++-----------------
t/t1501-sink.sh | 65 +++++++++++++++++++++++++++++------
2 files changed, 112 insertions(+), 43 deletions(-)
diff --git a/stgit/commands/sink.py b/stgit/commands/sink.py
index d8f79b4..a799433 100644
--- a/stgit/commands/sink.py
+++ b/stgit/commands/sink.py
@@ -1,6 +1,6 @@
__copyright__ = """
-Copyright (C) 2007, Yann Dirson <ydirson@altern.org>
+Copyright (C) 2008, Catalin Marinas <catalin.marinas@gmail.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
@@ -16,13 +16,10 @@ along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
-import sys, os
-from optparse import OptionParser, make_option
-
-from stgit.commands.common import *
-from stgit.utils import *
-from stgit import stack, git
+from optparse import make_option
+from stgit.commands import common
+from stgit.lib import transaction
help = 'send patches deeper down the stack'
usage = """%prog [-t <target patch>] [-n] [<patches>]
@@ -32,43 +29,72 @@ push the specified <patches> (the current patch by default), and
then push back into place the formerly-applied patches (unless -n
is also given)."""
-directory = DirectoryGotoToplevel()
+directory = common.DirectoryHasRepositoryLib()
options = [make_option('-n', '--nopush',
help = 'do not push the patches back after sinking',
action = 'store_true'),
make_option('-t', '--to', metavar = 'TARGET',
- help = 'sink patches below TARGET patch')]
+ help = 'sink patches below TARGET patch'),
+ make_option('-c', '--conflict',
+ help = 'allow conflicts during the push operations',
+ action = 'store_true')]
def func(parser, options, args):
"""Sink patches down the stack.
"""
+ stack = directory.repository.current_stack
- check_local_changes()
- check_conflicts()
- check_head_top_equal(crt_series)
-
- oldapplied = crt_series.get_applied()
- unapplied = crt_series.get_unapplied()
- all = unapplied + oldapplied
-
- if options.to and not options.to in oldapplied:
- raise CmdException('Cannot sink below %s, since it is not applied'
- % options.to)
+ if options.to and not options.to in stack.patchorder.applied:
+ raise common.CmdException('Cannot sink below %s since it is not applied'
+ % options.to)
if len(args) > 0:
- patches = parse_patches(args, all)
+ patches = common.parse_patches(args, stack.patchorder.all)
else:
- current = crt_series.get_current()
- if not current:
- raise CmdException('No patch applied')
- patches = [current]
+ # current patch
+ patches = list(stack.patchorder.applied[-1:])
- if oldapplied:
- crt_series.pop_patch(options.to or oldapplied[0])
- push_patches(crt_series, patches)
+ if not patches:
+ raise common.CmdException('No patches to sink')
+ if options.to and options.to in patches:
+ raise common.CmdException('Cannot have a sinked patch as target')
+
+ if options.conflict:
+ iw = stack.repository.default_iw
+ else:
+ iw = None
+ trans = transaction.StackTransaction(stack, 'sink')
+
+ # pop any patches to be sinked in case they are applied
+ to_push = trans.pop_patches(lambda pn: pn in patches)
+
+ if options.to:
+ if options.to in to_push:
+ # this is the case where sinking actually brings some
+ # patches forward
+ for p in to_push:
+ if p == options.to:
+ del to_push[:to_push.index(p)]
+ break
+ trans.push_patch(p, iw)
+ else:
+ # target patch below patches to be sinked
+ to_pop = trans.applied[trans.applied.index(options.to):]
+ to_push = to_pop + to_push
+ trans.pop_patches(lambda pn: pn in to_pop)
+ else:
+ # pop all the remaining patches
+ to_push = trans.applied + to_push
+ trans.pop_patches(lambda pn: True)
+ # push the sinked and other popped patches
if not options.nopush:
- newapplied = crt_series.get_applied()
- def not_reapplied_yet(p):
- return not p in newapplied
- push_patches(crt_series, filter(not_reapplied_yet, oldapplied))
+ patches.extend(to_push)
+ try:
+ for p in patches:
+ trans.push_patch(p, iw)
+ except transaction.TransactionHalted:
+ if not options.conflict:
+ raise
+
+ return trans.run(iw)
diff --git a/t/t1501-sink.sh b/t/t1501-sink.sh
index 32931cd..b3e2eb3 100755
--- a/t/t1501-sink.sh
+++ b/t/t1501-sink.sh
@@ -5,24 +5,67 @@ test_description='Test "stg sink"'
. ./test-lib.sh
test_expect_success 'Initialize StGit stack' '
- echo 000 >> x &&
- git add x &&
+ echo 0 >> f0 &&
+ git add f0 &&
git commit -m initial &&
- echo 000 >> y &&
- git add y &&
- git commit -m y &&
+ echo 1 >> f1 &&
+ git add f1 &&
+ git commit -m p1 &&
+ echo 2 >> f2 &&
+ git add f2 &&
+ git commit -m p2 &&
+ echo 3 >> f3 &&
+ git add f3 &&
+ git commit -m p3 &&
+ echo 4 >> f4 &&
+ git add f4 &&
+ git commit -m p4 &&
+ echo 22 >> f2 &&
+ git add f2 &&
+ git commit -m p22 &&
stg init &&
- stg uncommit &&
- stg pop
+ stg uncommit p22 p4 p3 p2 p1 &&
+ stg pop -a
'
-test_expect_success 'sink without applied patches' '
+test_expect_success 'sink default without applied patches' '
command_error stg sink
'
-test_expect_success 'sink a specific patch without applied patches' '
- stg sink y &&
- test $(echo $(stg series --applied --noprefix)) = "y"
+test_expect_success 'sink and reorder specified without applied patches' '
+ stg sink p2 p1 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p2 p1"
+'
+
+test_expect_success 'sink patches to the bottom of the stack' '
+ stg sink p4 p3 p2 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p4 p3 p2 p1"
+'
+
+test_expect_success 'sink current below a target' '
+ stg sink --to=p2 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p4 p3 p1 p2"
+'
+
+test_expect_success 'bring patches forward' '
+ stg sink --to=p2 p3 p4 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p1 p3 p4 p2"
+'
+
+test_expect_success 'sink specified patch below a target' '
+ stg sink --to=p3 p2 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p1 p2 p3 p4"
+'
+
+test_expect_success 'sink with conflict and restore the stack' '
+ command_error stg sink --to=p2 p22 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p1 p2 p3 p4"
+'
+
+test_expect_success 'sink with conflict and do not restore the stack' '
+ conflict stg sink --conflict --to=p2 p22 &&
+ test "$(echo $(stg series --applied --noprefix))" = "p1 p22" &&
+ test "$(echo $(stg status --conflict))" = "f2"
'
test_done
^ permalink raw reply related
* Re: How to replace a single corrupt, packed object?
From: Johannes Schindelin @ 2008-09-15 16:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0809151223570.6279@xanadu.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1569 bytes --]
Hi,
On Mon, 15 Sep 2008, Nicolas Pitre wrote:
> On Mon, 15 Sep 2008, Johannes Schindelin wrote:
>
> > On Sun, 10 Aug 2008, Nicolas Pitre wrote:
> >
> > > On Fri, 8 Aug 2008, Johannes Schindelin wrote:
> > >
> > > > my auto gc kicked in, and shows this:
> > > >
> > > > fatal: corrupt packed object for 2c1e128aa51e3a64bd61556c0cd488628b423ccf
> > > > error: failed to run repack
> > > >
> > > > Fortunately, I have the uncorrupted object somewhere else. So I copy the
> > > > single object as a loose one, and all is fine. Right?
> > > >
> > > > Wrong.
> > >
> > > Well, to be sure things are then right or wrong, just do a
> > >
> > > git show 2c1e128aa51e3a64bd61556c0cd488628b423ccf
> > >
> > > If you can't see the object before, and are able to see it once it has
> > > been copied over, then things are "right".
> > >
> > > > Repack still picks up the corrupt object instead of the good one.
> > > > What's the best way out?
> > >
> > > How do you repack? The only way to get rid of a corrupted object in
> > > that case is to 'git repack -a -f'.
> >
> > Turns out I am a complete, utter moron. And I am sure René will quote me
> > on that.
> >
> > Git would probably have taken the copied-over object, and now took the
> > copied-over pack (finally!).
> >
> > My mistake was to keep the .keep file. And the corrupt object was -- you
> > guessed it -- in the corresponding .pack file.
>
> OK. Then I'll dig my patch out and write a test for it before
> submitting it to Junio.
Thank you very much & sorry for the trouble,
Dscho
^ permalink raw reply
* [PATCH] help git-upload-pack find git
From: Michael J Gruber @ 2008-09-15 16:24 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <d3a045300809150130w6f78edd8xf599d1c7f639b77d@mail.gmail.com>
The --upload-pack option to clone raises the expectation that finding
git-upload-pack on the server side is enough. But git-upload-pack needs
to find git (for forking "git pack-objects") which fails if git is not
in $PATH.
This patch makes git-upload-pack use git_set_argv0_path() so that an
explicitely specified path for git-upload-pack is added to the path
which is used when fork()ing.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
upload-pack.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
The corresponding bug was reported by Paul Johnston who wondered why "git clone"
failed when specifying --upload-pack for an out-of-$PATH installation of git.
I'm not sure whether we should encourage this, but the --upload-pack option
clearly gives the impression that git-upload-pack is all that is needed.
I haven't looked at other server side programmes yet regarding this issue,
but "git clone" works fine with this patch in the situation where it
would not without.
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..1fb59de 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -615,6 +615,21 @@ int main(int argc, char **argv)
char *dir;
int i;
int strict = 0;
+ const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-upload-pack";
+ char *slash = (char *)cmd + strlen(cmd);
+
+ /*
+ * Take the basename of argv[0] as the command
+ * name, and the dirname as the default exec_path
+ * if we don't have anything better.
+ */
+ do
+ --slash;
+ while (cmd <= slash && !is_dir_sep(*slash));
+ if (cmd <= slash) {
+ *slash++ = 0;
+ git_set_argv0_path(cmd);
+ }
for (i = 1; i < argc; i++) {
char *arg = argv[i];
--
1.6.0.1.308.gede4c
^ permalink raw reply related
* Re: [PATCH FYI] t9700/test.pl: backwards compatibility improvements
From: Brandon Casey @ 2008-09-15 16:32 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: Git Mailing List
In-Reply-To: <ryvGcG_Sg9kftPIp7uWA1JVCd0inSiqB61VnfUuxRUZJg6W7SWhmOQ@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Tom G. Christensen wrote:
>> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
> Here is an alternative which _removes_ the File::Temp requirement.
A Tested-by for this new series would be appreciated.
-brandon
^ permalink raw reply
* Re: git-clone: path or ssh problem with git-upload-pack in 1.6.0?
From: Michael J Gruber @ 2008-09-15 16:25 UTC (permalink / raw)
To: Paul Johnston; +Cc: git
In-Reply-To: <d3a045300809150130w6f78edd8xf599d1c7f639b77d@mail.gmail.com>
Paul Johnston venit, vidit, dixit 15.09.2008 10:30:
> I'm having trouble with git-clone and I'm wondering if there's
> something I'm doing wrong or something wrong with git. Probably the
> former, hopefully someone can set me straight.
>
> I'm an admittedly novice git user. I'm trying to clone a repository
> over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0
> installed from a macports package. This installs into /opt/local/bin.
> I also cloned git from HEAD and 'make; make install'ed into ~/bin,
> this is the version shown below. Either way, these are
> nonstandard/non-system-wide installation locations, and it requires
> that my shell PATH reflect this, obviously.
>
> ----------------------------------------------
>
> # About my installation
> imac:~ paul$ which git
> /Users/paul/bin/git
>
> imac:~ paul$ git --version
> git version 1.6.0.1.285.g1070
>
> imac:~ paul$ ls /opt/local/bin/git*
> /opt/local/bin/git
> /opt/local/bin/git-upload-archive /opt/local/bin/gitk
> /opt/local/bin/git-receive-pack /opt/local/bin/git-upload-pack
>
> imac:~ paul$ ls ~/bin/git*
> /Users/paul/bin/git
> /Users/paul/bin/git-shell
> /Users/paul/bin/git-upload-pack
> /Users/paul/bin/git-receive-pack
> /Users/paul/bin/git-upload-archive
>
> # Make a simple reposirtory /tmp/test/.git
> imac:~ paul$ cd /tmp
> imac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git
> init; git add README; git commit -a -m'Initial import'; cd ..
> Initialized empty Git repository in /private/tmp/test/.git/
> Created initial commit 49c10e6: Initial import
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 README
>
> # OK, this fails expectedly
> imac:/tmp paul$ cd ~
> imac:~ paul$ git clone ssh://localhost/tmp/test/.git
> Initialized empty Git repository in /Users/paul/test/.git/
> Password:
> bash: line 1: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
>
> # This has been killing me... Have tried numerous variants of the
> same with similar results...
> imac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack
> ssh://localhost/tmp/test/.git
> Initialized empty Git repository in /Users/paul/test/.git/
> Password:
> remote: fatal: exec pack-objects failed.
> error: git-upload-pack: git-pack-objects died with error.
> fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
>
> # Fix it with symlinks in /usr/bin
> imac:~ paul$ cd /usr/bin/
> imac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .
> imac:/usr/bin paul$ ls -al git*
> lrwxr-xr-x 1 root wheel 18 Sep 9 19:18 git -> /opt/local/bin/git
> lrwxr-xr-x 1 root wheel 31 Sep 9 19:18 git-receive-pack ->
> /opt/local/bin/git-receive-pack
> lrwxr-xr-x 1 root wheel 33 Sep 9 19:18 git-upload-archive ->
> /opt/local/bin/git-upload-archive
> lrwxr-xr-x 1 root wheel 30 Sep 9 19:18 git-upload-pack ->
> /opt/local/bin/git-upload-pack
> lrwxr-xr-x 1 root wheel 19 Sep 9 19:18 gitk -> /opt/local/bin/gitk
>
> # And now git-clone works as expected...
> imac:/usr/bin paul$ cd
> imac:~ paul$ git clone ssh://localhost/tmp/test/.git
> Initialized empty Git repository in /Users/paul/test/.git/
> Password:
> remote: Counting objects: 3, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Receiving objects: 100% (3/3), done.
>
> imac:~ paul$ find test/
> test/
> test//.git
> { file listing removed for brevity... }
> test//README
>
> -------------------------------------------
>
> OK, great, now it works. I suspect I'm not using the --upload-pack
> option correctly or my ssh installation is suboptimal, but as I could
> find no existing documentation on the subject, I am posting this
> message. Any thoughts?
re ssh: I'm surprised your PATH doesn't include $HOME/bin when sshing.
That should make everything work.
re upload-pack: That indeed sounds as if upload-pack can't execute
pack-objects. I checked by moving my bin away, and clone failed. Seems
everyone is using proper PATHS ;)
In fact, upload-pack tries to call "git pack-objects" and fails if it
can't find git. Patch upcoming...
Michael
^ permalink raw reply
* Re: How to replace a single corrupt, packed object?
From: Nicolas Pitre @ 2008-09-15 16:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0809151603390.13830@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1399 bytes --]
On Mon, 15 Sep 2008, Johannes Schindelin wrote:
> On Sun, 10 Aug 2008, Nicolas Pitre wrote:
>
> > On Fri, 8 Aug 2008, Johannes Schindelin wrote:
> >
> > > my auto gc kicked in, and shows this:
> > >
> > > fatal: corrupt packed object for 2c1e128aa51e3a64bd61556c0cd488628b423ccf
> > > error: failed to run repack
> > >
> > > Fortunately, I have the uncorrupted object somewhere else. So I copy the
> > > single object as a loose one, and all is fine. Right?
> > >
> > > Wrong.
> >
> > Well, to be sure things are then right or wrong, just do a
> >
> > git show 2c1e128aa51e3a64bd61556c0cd488628b423ccf
> >
> > If you can't see the object before, and are able to see it once it has
> > been copied over, then things are "right".
> >
> > > Repack still picks up the corrupt object instead of the good one.
> > > What's the best way out?
> >
> > How do you repack? The only way to get rid of a corrupted object in
> > that case is to 'git repack -a -f'.
>
> Turns out I am a complete, utter moron. And I am sure René will quote me
> on that.
>
> Git would probably have taken the copied-over object, and now took the
> copied-over pack (finally!).
>
> My mistake was to keep the .keep file. And the corrupt object was -- you
> guessed it -- in the corresponding .pack file.
OK. Then I'll dig my patch out and write a test for it before
submitting it to Junio.
Nicolas
^ permalink raw reply
* [PATCH 3/3] t9700/test.pl: remove File::Temp requirement
From: Brandon Casey @ 2008-09-15 16:25 UTC (permalink / raw)
To: Tom G. Christensen, Git Mailing List
In-Reply-To: <uWiPWIPu6IKkVafz9wdZ-sRK84QZuJQNOZM80bkfw24NxsVT-Z3J9g@cipher.nrlssc.navy.mil>
The object oriented version of File::Temp is a rather new incarnation it
seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
the 'Objects' section. Instead of creating a file with a unique name in
the system TMPDIR, we can create our own temporary file with a static
name and use that instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t9700/test.pl | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index f777b08..9908109 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -8,7 +8,6 @@ use strict;
use Test::More qw(no_plan);
use Cwd;
-use File::Temp;
BEGIN { use_ok('Git') }
@@ -65,21 +64,25 @@ is($r->ident_person("Name", "email", "123 +0000"), "Name <email>",
# objects and hashes
ok(our $file1hash = $r->command_oneline('rev-parse', "HEAD:file1"), "(get file hash)");
-our $tmpfile = File::Temp->new;
-is($r->cat_blob($file1hash, $tmpfile), 15, "cat_blob: size");
+my $tmpfile = "file.tmp";
+open TEMPFILE, "+>$tmpfile" or die "Can't open $tmpfile: $!";
+is($r->cat_blob($file1hash, \*TEMPFILE), 15, "cat_blob: size");
our $blobcontents;
-{ local $/; seek $tmpfile, 0, 0; $blobcontents = <$tmpfile>; }
+{ local $/; seek TEMPFILE, 0, 0; $blobcontents = <TEMPFILE>; }
is($blobcontents, "changed file 1\n", "cat_blob: data");
-seek $tmpfile, 0, 0;
+close TEMPFILE or die "Failed writing to $tmpfile: $!";
is(Git::hash_object("blob", $tmpfile), $file1hash, "hash_object: roundtrip");
-$tmpfile = File::Temp->new();
-print $tmpfile my $test_text = "test blob, to be inserted\n";
+open TEMPFILE, ">$tmpfile" or die "Can't open $tmpfile: $!";
+print TEMPFILE my $test_text = "test blob, to be inserted\n";
+close TEMPFILE or die "Failed writing to $tmpfile: $!";
like(our $newhash = $r->hash_and_insert_object($tmpfile), qr/[0-9a-fA-F]{40}/,
"hash_and_insert_object: returns hash");
-$tmpfile = File::Temp->new;
-is($r->cat_blob($newhash, $tmpfile), length $test_text, "cat_blob: roundtrip size");
-{ local $/; seek $tmpfile, 0, 0; $blobcontents = <$tmpfile>; }
+open TEMPFILE, "+>$tmpfile" or die "Can't open $tmpfile: $!";
+is($r->cat_blob($newhash, \*TEMPFILE), length $test_text, "cat_blob: roundtrip size");
+{ local $/; seek TEMPFILE, 0, 0; $blobcontents = <TEMPFILE>; }
is($blobcontents, $test_text, "cat_blob: roundtrip data");
+close TEMPFILE;
+unlink $tmpfile;
# paths
is($r->repo_path, "./.git", "repo_path");
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* [PATCH 2/3] t9700/test.pl: avoid bareword 'STDERR' in 3-argument open()
From: Brandon Casey @ 2008-09-15 16:23 UTC (permalink / raw)
To: Tom G. Christensen, Git Mailing List
In-Reply-To: <T5Id5zYBlKyKEhZkMsE3QTI2aU3XMiwpfpsPq89cvXrakbyGShLtQw@cipher.nrlssc.navy.mil>
Some versions of perl complain when 'STDERR' is used as the third argument
in the 3-argument form of open(). Convert to the 2-argument form which is
described for duping STDERR in my second edition camel book.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t9700/test.pl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 732133e..f777b08 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -34,7 +34,7 @@ is($r->get_color("color.test.slot1", "red"), $ansi_green, "get_color");
# Failure cases for config:
# Save and restore STDERR; we will probably extract this into a
# "dies_ok" method and possibly move the STDERR handling to Git.pm.
-open our $tmpstderr, ">&", STDERR or die "cannot save STDERR"; close STDERR;
+open our $tmpstderr, ">&STDERR" or die "cannot save STDERR"; close STDERR;
eval { $r->config("test.dupstring") };
ok($@, "config: duplicate entry in scalar context fails");
eval { $r->config_bool("test.boolother") };
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* [PATCH 1/3] t9700/test.pl: no longer requires File::Basename
From: Brandon Casey @ 2008-09-15 16:20 UTC (permalink / raw)
To: Git Mailing List, Tom G. Christensen
In-Reply-To: <48CE4CFE.1010106@statsbiblioteket.dk>
Since ff30fff3 removed the call to basename(), we don't need to
'use File::Basename'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t9700/test.pl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 851cea4..732133e 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -8,7 +8,6 @@ use strict;
use Test::More qw(no_plan);
use Cwd;
-use File::Basename;
use File::Temp;
BEGIN { use_ok('Git') }
--
1.6.0.1.244.gdc19
^ permalink raw reply related
* Re: [PATCH FYI] t9700/test.pl: backwards compatibility improvements
From: Brandon Casey @ 2008-09-15 16:20 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: Git Mailing List
In-Reply-To: <48CE4CFE.1010106@statsbiblioteket.dk>
Tom G. Christensen wrote:
> Brandon Casey wrote:
>> Some versions of perl complain when 'STDERR' is used as the third
>> argument
>> in the 3-argument form of open(). Convert to the 2-argument form which is
>> described for duping STDERR in my second edition camel book.
>>
>> The object oriented version of File::Temp is a rather new incarnation it
>> seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
>> the 'Objects' section. These can be converted to use
>> File::Temp::tempfile().
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>>
> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
>
> Without this patch the testsuite will fail with perl 5.8.0:
> t9700$ ./test.pl
> ok 1 - use Git;
> Bareword "STDERR" not allowed while "strict subs" in use at ./test.pl
> line 41.
> Execution of ./test.pl aborted due to compilation errors.
> 1..1
> # Looks like your test died just after 1.
>
>
> Could we please get this patch in?
Junio had asked me to follow up on that patch at a later time, so
thanks for prodding.
Here is an alternative which _removes_ the File::Temp requirement.
-brandon
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Tor Arvid Lund @ 2008-09-15 15:27 UTC (permalink / raw)
To: dhruva; +Cc: Junio C Hamano, David Brown, GIT SCM, Simon Hausmann
In-Reply-To: <263224.61965.qm@web95002.mail.in2.yahoo.com>
On Mon, Sep 15, 2008 at 1:46 PM, dhruva <dhruva@ymail.com> wrote:
> ----- Original Message ----
>> From: Tor Arvid Lund <torarvid@gmail.com>
------ >8 ------
>> Hmm.. I thought this was not a p4 problem. I think however, that
>> "git-p4 submit" tries to do git format-patch and then git apply that
>> patch to the p4 directory. In other words, I believe that git apply
>> fails since the file in the p4 dir has the keywords expanded, while
>> the patch does not. I haven't done any careful investigation, but If
>> my assumption is true, it sounds like dhruvas patch should work...
>
> Your assumption is true (from my understanding of the code). My doubt is, even the files in p4 folder will be from git with no RCS keyword expanded. The patch application must ideally be clean! I am confused here.
Hmm, regarding the p4 folder - I'm pretty sure git-p4 calls "p4 sync
<depotpath>/..." in that folder before applying the patch. So those
files are whatever p4 says they are - which is with keywords
expanded...
-TAL-
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Michael J Gruber @ 2008-09-15 15:12 UTC (permalink / raw)
To: Pico Geyer; +Cc: git
In-Reply-To: <aa2b76740809150550q724ab0f4x99a27fa21d90c0fb@mail.gmail.com>
Pico Geyer venit, vidit, dixit 15.09.2008 14:50:
> Hi all.
>
> I'd like to start using Git within our company. I'm still trying to
> determine if Git can work in our scenario.
> May be someone can offer some advice.
> Our scenario is as follows:
> We have a handful of developers which work at a branch office. This
> office has a rather slow internet connection.
> At the head office, we are (still) using a Subversion server to host
> our source code.
> At the branch office, we would like to do the following:
> * Fetch the latest code from the subversion server.
> * Push changes that we have made at the remote office back to upstream
> SVN server.
> * Be able to share source code changes locally (at the branch office)
> between developers.
>
> The solution that I imagined is that we would setup a server (lets
> call it A) at the branch office with a Git repository, that all the
> developers can access.
> Developers would then clone the server repository A, make mods and
> then push changes back to A.
> It would be nice if git users could commit to a subversion branch.
> A merge master would then (as necessary) use svn dcommit to push the
> changes up to the svn server.
> Is this scenario possible?
>
> From the git-svn man page: "git-clone does not clone branches under
> the refs/remotes/ hierarchy or any git-svn metadata, or config. So
> repositories created and managed with using git-svn should use rsync
> for cloning, if cloning is to be done at all."
That is true if you mean by "clone" a complete copy.
> Does that mean that one should not push changes to a repository that
> was created with "git svn clone ..."?
What matters is which branches you push into.
Your developers don't need to push/commit to svn, only into A, if I
understood correctly. Do they need svn-metadata (besides svn revision
numbers)?
If not then the interaction between A and the developers can be a normal
git workflow between git managed branches, and "git clone" will do fine.
Merge master at A could do the following:
- use git svn to keep the svn (remote) branches at A in sync with the
central subversion server
- push them to proper git branches in A, which get picked up by
developers' " git clone"
- maintain integration branches for integrating the changes coming fro
the developers
- dcommit the svn tracking branches back to the central svn server
Disadvantage:
If changes are dcommitted to svn, synced back with git svn fetch, and
then fetched/pull by the developers their commit will look different
(addition git svn info in the commit message). This is similar to a
workflow where you submit by e-mail and your integrated patches get a
different sha1.
Advantage:
For all developers, everything is just git. Only megre master needs to
know git svn.
Cheers,
Michael
^ permalink raw reply
* Re: Git Gui does not want to work on chunk level
From: Shawn O. Pearce @ 2008-09-15 14:24 UTC (permalink / raw)
To: Alexander Gladysh
Cc: git-users-/JYPxA39Uh5TLH3MbocFFw, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c6c947f60809150721m1ec11f10xc68ce39559398659-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Alexander Gladysh <agladysh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Sep 5, 2008 at 8:53 AM, Shawn O. Pearce <spearce-o8xcbExO1WpAfugRpC6u6w@public.gmane.org> wrote:
>
> > git-gui: Fix diff parsing for lines starting with "--" or "++"
>
> Somewhat related bug, but reproduceable event without "--". If I set
> diff context to none in git gui (by repeatedly clicking "show less
> context") I'm sometimes not able to stage hunk or line.
git-apply refuses to apply a patch with 0 context lines. Latest
git-gui in maint (and in Git 1.6.0.2?) won't let you reduce the
number of context lines below 1, so you never can see this error.
> Reduce context to none, then do stage hunk. It fails with message:
>
> error: patch failed: file.ext:3
> error: file.ext: patch does not apply
> OK
--
Shawn.
^ permalink raw reply
* Re: Git Gui does not want to work on chunk level
From: Alexander Gladysh @ 2008-09-15 14:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git-users, git
In-Reply-To: <20080905045327.GA31166@spearce.org>
Hi, list!
On Fri, Sep 5, 2008 at 8:53 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> git-gui: Fix diff parsing for lines starting with "--" or "++"
Somewhat related bug, but reproduceable event without "--". If I set
diff context to none in git gui (by repeatedly clicking "show less
context") I'm sometimes not able to stage hunk or line.
git version 1.6.0.GIT
git-gui version 0.11.GITGUI
Steps to reproduce:
agladysh@agladysh-desktop:~$ mkdir test
agladysh@agladysh-desktop:~$ cd test
agladysh@agladysh-desktop:~/test$ git init
Initialized empty Git repository in /home/agladysh/test/.git/
agladysh@agladysh-desktop:~/test$ cat >file.ext
-- 1
-- 2
-- 3
-- 4
-- 5
agladysh@agladysh-desktop:~/test$ git add file.ext
agladysh@agladysh-desktop:~/test$ git commit -m "one"
Created initial commit aa4da16: one
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file.ext
agladysh@agladysh-desktop:~/test$ cat >file.ext
-- 1
-- 2
-- 33
-- 4
-- 5
agladysh@agladysh-desktop:~/test$ git gui
Reduce context to none, then do stage hunk. It fails with message:
error: patch failed: file.ext:3
error: file.ext: patch does not apply
OK
Dump (by your debuging dumper patch from the same tread):
diff --git a/file.ext b/file.ext
--- a/file.ext
+++ b/file.ext
@@ -1,5 +1,5 @@
-- 1
-- 2
--- 3
+-- 33
-- 4
-- 5
Do stage line. It fails with message:
fatal: corrupt patch at line 5
Dump:
diff --git a/file.ext b/file.ext
--- a/file.ext
+++ b/file.ext
@@ -3 +3 @@
--- 3
+-- 33
HTH,
Alexander.
^ permalink raw reply
* Re: [GSoC] Git projects for Google Summer of Code 2008 final evaluation
From: Shawn O. Pearce @ 2008-09-15 14:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, git, Sam Vilain, Joshua Roys, Sverre Rabbelier,
Sverre Rabbelier, David Symonds, Lea Wiemann, John Hawley,
Marek Zawirski, Miklos Vajna, Stephan Beyer, Christian Couder,
Daniel Barkalow, Junio Hamano
In-Reply-To: <alpine.DEB.1.00.0809151434280.13830@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 15 Sep 2008, Jakub Narebski wrote:
> > On Thu, 4 Sep 2008, Jakub Narebski wrote:
> >
> > > Mentors, could you tell us your side about how it was working as a
> > > mentor for Google Summer of Code? Perhaps some tricks of trade?
> >
> > By the way, I have found via LWN that Perl has written nice summary of
> > theirs Google Summer of Code projects[1]. Among other they very much
> > praise that students did blogging about their progress:
...
> > What do you think about it (for example about doing it in a future
> > if our informal Git Development Community would participate in next
> > Google Summer of Code programs)?
>
> I think that it is better to require frequent interaction on the mailing
> list, or at least on IRC.
I agree with Dscho completely. We are an email based community.
Students should be involved by email, not by blogs. If we were
the Ruby community (which near as I can tell is blog based) then
blogging might make more sense. We're not. We're an offshoot of
the Linux community, which is very much email-centric.
> Blogging is nice for those who want to follow the progress of a project,
> but do not want to get involved. In this case, it is even better than
> having the people discuss the issues of the project openly, as reading a
> blog does not require constant monitoring like the list does.
>
> However, blogging costs time.
Exactly. Email also costs time, but typically we don't see
traffic on the list that is just broadcasting something pointless.
In general people only start a topic if there is going to be
worthwhile discussion attached to it, and often that results in a
useful patch being applied at some point in the future. IOW that
time for email is just necessary in the course of development,
so it isn't wasted.
If the community of semi-interested people really wants blogs to
read, RSS scrape a news feed like Gmane. Ohloh already has an
RSS feed defined around the emails sent to git ML with the subject
"[ANNOUNCE]".
I however prefer email, and dislike blogging, so I'll continue
to use the git ML in the future, and so will any student I mentor
in any potential future GSoC program. FWIW I blogged here at new
day-job on company internal blog for about a half day before I gave
up and said "damn, that really is stupid".
--
Shawn.
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-15 14:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809151240.54495.jnareb@gmail.com>
On 9/15/08, Jakub Narebski <jnareb@gmail.com> wrote:
> [I don't see mails I am replying to on GMane interface to git mailing
> list, so threads might be broken. Strange... Perhaps too long lines
> were cause of rejection by anti-SPAM vger filter?]
It was because I used zenbe.com (limited choices at work) to send
mails and did not realize until too late that zenbe.com did not encode
UTF-8 properly in mail headers. It made vger.k.o nervous and refuse to
accept my mails.
> On Mon, 15 Sep 2008, Duy Nguyen wrote:
> > On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>
>
> > > > +Narrow works by applying your rules to the index, marking which
> > > > +file you need and which file you need not. Modified/Unmerged
> > > > +files cannot be marked unneeded. Unnecessary files will be
> > > > +removed from working directory. Note that after this step,
> > > > +removed files can still be added to working directory when they
> > > > +are needed by any git command. For example, when you have a merge
> > > > +conflict, conflicted files will be checked out on working
> > > > +directory and will no longer be marked "unneeded".
> > >
> > > This paragraph I think need some more love...
> > >
> > > So the "checkout rules" are meant to mark which paths are "wanted"
> > > or "needed", and we would like to have in the checkout, and which
> > > files are "unwanted" or "not needed" ("unneeded"?) and we want to
> > > not have them present in working directory; something akin to accept
> > > and deny rules, isn't it?
> >
> > Yes. But rules will be gone, only the results remain. I don't
> > save/reuse rules.
>
>
> Ah. I understand. The options are only to select which files to check-out
> (which are "wanted"), and which we do not want and mark with "no-checkout"
> bit ("unwanted").
>
>
> > > What are the rules, does all files except those marked explicitely
> > > as needed are unneeded, or do you have to first mark all files as
> > > unneeded?
> > >
> > > How would the following table look like:
> > >
> > > working directory || needed | not needed |
> > > ----------------------------------------------------
> > > file is absent || checkout | no change |
> > > file is present || no change | removed |
> > > file is modified || conflict | conflict? |
> >
> > Looks better than my description. Though it would be "no change" for
> > "file is modified/needed" case. There should be another line for
> > unmerged entries.
>
>
> Now I am not sure about the line with 'file is modified', because even
> in simple full checkout case there are different situations dealing with
> checking out of index (and '-f' option), and switching to other branch
> (and '-m' option).
>
> Doesn't unmerged simply mean ignore "no-checkout" bit?
Yes.
> > > > +Narrow spec will be used to specify how you want to narrow your
> > > > +checkout. It is a list of pathspecs separated by colons. Each
> > > > +patchspec specifies what files should be checked out on working
> > > > +directory. Pathspec can contain wildcards and is relative to
> > > > +current working directory. Usually asterisk (*) does not match
> > > > +slashes. If a pathspec is prefixed by a plus sign (+), then
> > > > +any asterisk will match anything, even slashes.
> > >
> > > First, does this mean that you can specify paths containing colons
> > > (':') only using --add-path and --remove-path, or does it mean that
> > > you cannot specify paths containg colon ':' (which should be rare)
> > > at all as checkout limiter / checkout narrowing rule?
> >
> > You cannot do othat explicitly unfortunately. You can work-around using
> > wildcard though.
>
>
> Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
> or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
> kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
> Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
> can escape other special characters, for example wildcard characters
> like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
>
Sure. Somehow I forgot that.
> > > Second, wouldn't it be better to use '**' to match also '/'?
> > > Changing meaning of '*' using per-path flag seems a bit bad.
> >
> > It would be better. But I don't see any way but duplicating fnmatch()
> > implementation and modify it to support '**' so I made a compromise.
> > Will make another patch for '**' support and see how bloat the code
> > will be.
>
>
> Well, the alternative would be to tell in commit message _why_ you
> choose that (for implementation reasons), and perhaps give an example.
>
> BTW. does '+' prefixed pathspec means that '?' can match '/', directory
> separator?
No it only affects '*'.
So how about this? Note that document changes that also require code
change like narrow spec escape or '**' do not get in. I will change it
when I update code.
--<--
Narrow checkout
---------------
Normally when you do checkout a branch, your working directory
will be fully populated. In some situations, you just need to
work on certain files, no full checkout is needed. Narrow
checkout is a mode that limits checkout area according to your
needs.
Because narrow checkout uses new index format, it will be
incompatible with git prior to 1.6.0 regarding worktree operations.
Repository-only operations such as clone, push, pull... should not be
affected by narrow checkout. In order to make your working directory
work again with those versions, you can use `git checkout --full` to
return to normal mode (and compatible index format).
In narrow checkout mode, checkout status of every files in your
working directory will be recorded in index. If a file is marked
"no-checkout", it means that file is not needed to be present in
working directory by user or any git command. When a new file is added
to index, it will be marked "checkout" unless narrow spec is applied.
Unmerged files are always "checkout". linkgit:git-update-index[1] can
be used to update "checkout/no-checkout" status in index. When you
checkout new files using "git checkout <file>" they will be
automatically marked "checkout". Other commands such as "git apply"
can also checkout new files if they are needed.
"No-checkout" status is very similar to "assume-unchanged bit"
(see linkgit:git-update-index[1]). The main difference between them
is "assume unchanged" bit just ignores corresponding files in working
directory while narrow checkout goes a bit farther, remove those files
when it is safe to do so.
Narrow spec
-----------
Narrow spec is used to easily specify how do you want to form your
checkout area. It is a list of pathspecs separated by colons. Each
patchspec specifies what files should or should not be checked out on
working directory. Pathspec can contain wildcards and is relative to
current working directory. Usually asterisk (*) does not match
slashes. If a pathspec is prefixed by a plus sign (+), then any
asterisk will match anything, even slashes.
When you apply new narrow spec to your working directory using either
--path, --add-path or --remove-path, it will update "checkout" status
in index accordingly. Moreover, if a file is marked "no-checkout" and
is present in working directory, it will be removed. If a file is
turned from "no-checkout" to "checkout", then it will be added again
to working directory. Modified and unmerged entries can't bear
"no-checkout" status, if narrow spec applies to them, "git checkout"
will refuse to update working directory.
Narrow spec is not saved by "git checkout". You can form your checkout
area on one go with --path option, or do it incrementally
with --add-path and --remove-path.
--<--
--
Duy
^ permalink raw reply
* Re: How to replace a single corrupt, packed object?
From: Johannes Schindelin @ 2008-09-15 14:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808102139050.22892@xanadu.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1311 bytes --]
Hi,
On Sun, 10 Aug 2008, Nicolas Pitre wrote:
> [ sorry for the delay -- I just returned from vacation ]
No need to be sorry; my delay is even worse...
> On Fri, 8 Aug 2008, Johannes Schindelin wrote:
>
> > my auto gc kicked in, and shows this:
> >
> > fatal: corrupt packed object for 2c1e128aa51e3a64bd61556c0cd488628b423ccf
> > error: failed to run repack
> >
> > Fortunately, I have the uncorrupted object somewhere else. So I copy the
> > single object as a loose one, and all is fine. Right?
> >
> > Wrong.
>
> Well, to be sure things are then right or wrong, just do a
>
> git show 2c1e128aa51e3a64bd61556c0cd488628b423ccf
>
> If you can't see the object before, and are able to see it once it has
> been copied over, then things are "right".
>
> > Repack still picks up the corrupt object instead of the good one.
> > What's the best way out?
>
> How do you repack? The only way to get rid of a corrupted object in
> that case is to 'git repack -a -f'.
Turns out I am a complete, utter moron. And I am sure René will quote me
on that.
Git would probably have taken the copied-over object, and now took the
copied-over pack (finally!).
My mistake was to keep the .keep file. And the corrupt object was -- you
guessed it -- in the corresponding .pack file.
Aaaaargh,
Dscho
^ permalink raw reply
* Re: git+ssh using 'plink' on windows
From: Peter Krefting @ 2008-09-15 13:41 UTC (permalink / raw)
To: dhruva; +Cc: GIT SCM
In-Reply-To: <262032.88533.qm@web95003.mail.in2.yahoo.com>
dhruva:
> Since I use git on windows (without cygwin), I am keen to know if
> 'git+ssh' protocol work with Putty's plink? plink is a ssh like
> client on windows with almost similar features.
As long as you actually remember to add the keys to Plink, it works
perfectly fine. I've been using it in the last few releases, which do
ask you whether you want to use OpenSSH or PuTTY already in the
installation program.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Help using Git(-svn) for specific use case
From: Pico Geyer @ 2008-09-15 12:50 UTC (permalink / raw)
To: git
Hi all.
I'd like to start using Git within our company. I'm still trying to
determine if Git can work in our scenario.
May be someone can offer some advice.
Our scenario is as follows:
We have a handful of developers which work at a branch office. This
office has a rather slow internet connection.
At the head office, we are (still) using a Subversion server to host
our source code.
At the branch office, we would like to do the following:
* Fetch the latest code from the subversion server.
* Push changes that we have made at the remote office back to upstream
SVN server.
* Be able to share source code changes locally (at the branch office)
between developers.
The solution that I imagined is that we would setup a server (lets
call it A) at the branch office with a Git repository, that all the
developers can access.
Developers would then clone the server repository A, make mods and
then push changes back to A.
It would be nice if git users could commit to a subversion branch.
A merge master would then (as necessary) use svn dcommit to push the
changes up to the svn server.
Is this scenario possible?
>From the git-svn man page: "git-clone does not clone branches under
the refs/remotes/ hierarchy or any git-svn metadata, or config. So
repositories created and managed with using git-svn should use rsync
for cloning, if cloning is to be done at all."
Does that mean that one should not push changes to a repository that
was created with "git svn clone ..."?
Thanks in advance for any advice.
Pico Geyer
^ permalink raw reply
* Re: [GSoC] Git projects for Google Summer of Code 2008 final evaluation
From: Johannes Schindelin @ 2008-09-15 12:40 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Stephan Beyer, Christian Couder,
Daniel Barkalow, Junio Hamano
In-Reply-To: <200809151413.37628.jnareb@gmail.com>
Hi,
On Mon, 15 Sep 2008, Jakub Narebski wrote:
> On Thu, 4 Sep 2008, Jakub Narebski wrote:
>
> > Mentors, could you tell us your side about how it was working as a
> > mentor for Google Summer of Code? Perhaps some tricks of trade?
>
> By the way, I have found via LWN that Perl has written nice summary of
> theirs Google Summer of Code projects[1]. Among other they very much
> praise that students did blogging about their progress:
>
> "use Perl | Summer of Code recap"
> http://use.perl.org/articles/08/08/29/1224242.shtml
>
> Most of the students did a great job of blogging their progress, which
> I think is an important part of Summer of Code for the rest of the
> community.
>
> What do you think about it (for example about doing it in a future
> if our informal Git Development Community would participate in next
> Google Summer of Code programs)?
I think that it is better to require frequent interaction on the mailing
list, or at least on IRC.
Blogging is nice for those who want to follow the progress of a project,
but do not want to get involved. In this case, it is even better than
having the people discuss the issues of the project openly, as reading a
blog does not require constant monitoring like the list does.
However, blogging costs time.
I think that in the case of Git, those who are interested are those that
will work on (as opposed to "with") those projects, too. So I think the
time is better spent on the mailing list.
Especially given the fact that the interested parties can guide the course
of the project early, i.e. before a blog entry would be written (just
think about the Git.pm thing; both Lea's and Joshua's project could have
benefitted from enhancing the existing Git.pm according to their needs).
My cent,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Mark Brown @ 2008-09-15 11:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Lang, git
In-Reply-To: <200809121244.59067.jnareb@gmail.com>
On Fri, Sep 12, 2008 at 12:44:58PM +0200, Jakub Narebski wrote:
> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
> > If you do commercial development with Windows you are almsot going to be
> > required to use MS VSS.
> I hope not. Even Microsoft themselves supposedly doesn't recommend
> Source(Un)Safe, but MS Visual Studio Team System.
Yes, it's strongly deprecated by Microsoft these days and has some known
limitations that aren't going to be addressed.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: bad links on git homepage
From: Fredrik Skolmli @ 2008-09-15 11:36 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0809142132270.19489@asgard.lang.hm>
On Sun, Sep 14, 2008 at 09:33:08PM -0700, david@lang.hm wrote:
> the links on the git homepage to download the 1.6.0.2 tarballs link to
> kernel.org/... when they need to link to www.kernel.org
Maybe I'm missing something, but why? They seem to work?
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Sam Vilain @ 2008-09-15 12:21 UTC (permalink / raw)
To: Stephen R. van den Berg
Cc: Theodore Tso, Linus Torvalds, Jakub Narebski, Paolo Bonzini, git
In-Reply-To: <20080912155427.GB2915@cuci.nl>
On Fri, 2008-09-12 at 17:54 +0200, Stephen R. van den Berg wrote:
> Theodore Tso wrote:
> >Nope, as Sam suggested in his original message (but which got clipped
> >by Linus when he was replying) all you have to do is to have a
> >separate local database which ties commits and patch-id's together as
> >a cache/index.
>
> True. But repopulating this cache after cloning means that you have to
> calculate the patch-id of *every* commit in the repository. It sounds
> like something to avoid, but maybe I'm overly concerned, I have only a
> vague idea on how computationally intensive this is.
You don't necessarily need to do that. If the tool decides that the
sha1 it finds in the message is a patch-id reference, well it can just
start hunting around, caching the patch-ids it calculates as it finds
them, until it either finds one that matches, or determines you don't
have it. You can probably find it first try just based on the author
name and date 90% of the time anyway.
Maybe the machinery could be adequately tilted such that if someone is
really desperate to make sure they are found quickly they can put the
information at refs/patches/PATCHID/COMMITID, but that sounds a bit
abusive.
Sam.
^ permalink raw reply
* Re: [GSoC] Git projects for Google Summer of Code 2008 final evaluation
From: Jakub Narebski @ 2008-09-15 12:13 UTC (permalink / raw)
To: git
Cc: Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow, Junio Hamano
In-Reply-To: <200809042315.58898.jnareb@gmail.com>
On Thu, 4 Sep 2008, Jakub Narebski wrote:
> Mentors, could you tell us your side about how it was working as a
> mentor for Google Summer of Code? Perhaps some tricks of trade?
By the way, I have found via LWN that Perl has written nice summary
of theirs Google Summer of Code projects[1]. Among other they very much
praise that students did blogging about their progress:
"use Perl | Summer of Code recap"
http://use.perl.org/articles/08/08/29/1224242.shtml
Most of the students did a great job of blogging their progress, which
I think is an important part of Summer of Code for the rest of the
community.
What do you think about it (for example about doing it in a future
if our informal Git Development Community would participate in next
Google Summer of Code programs)?
[1] I plan to add quick summary of final results to GSoC2008 wiki page,
http://git.or.cz/gitwiki/SoC2008Projects, of course if GSoC manager(s),
mentors, or students don't do it first...
--
Jakub Narebski
Poland
^ 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