* clong an empty repo over ssh causes (harmless) fatal
From: Sitaram Chamarty @ 2009-08-31 11:14 UTC (permalink / raw)
To: git
Hello,
Cloning an empty repo seems to produce a spurious error.
The repo still seems fine though.
Any thoughts?
$ git clone ssh://sitaram@localhost/home/sitaram/t/a b
Initialized empty Git repository in /home/sitaram/t/b/.git/
sitaram@localhost's password:
warning: You appear to have cloned an empty repository.
fatal: The remote end hung up unexpectedly
Thanks,
Sitaram
^ permalink raw reply
* [PATCH] fast-import.c: Silence build warning
From: Michael Wookey @ 2009-08-31 11:21 UTC (permalink / raw)
To: git
gcc 4.3.3 (Ubuntu 9.04) warns that the return value of strtoul() was not
checked by issuing the following notice:
warning: ignoring return value of ‘strtoul’, declared with attribute
warn_unused_result
Provide a dummy variable to keep the compiler happy.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
fast-import.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..1386e75 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1744,10 +1744,11 @@ static int validate_raw_date(const char *src,
char *result, int maxlen)
{
const char *orig_src = src;
char *endp;
+ unsigned long int unused;
errno = 0;
- strtoul(src, &endp, 10);
+ unused = strtoul(src, &endp, 10);
if (errno || endp == src || *endp != ' ')
return -1;
@@ -1755,7 +1756,7 @@ static int validate_raw_date(const char *src,
char *result, int maxlen)
if (*src != '-' && *src != '+')
return -1;
- strtoul(src + 1, &endp, 10);
+ unused = strtoul(src + 1, &endp, 10);
if (errno || endp == src || *endp || (endp - orig_src) >= maxlen)
return -1;
--
1.6.4.2.236.gf324c
^ permalink raw reply related
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Matthieu Moy @ 2009-08-31 11:22 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrnh9nc4e.6bn.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Hello,
>
> Cloning an empty repo seems to produce a spurious error.
> The repo still seems fine though.
Can't reproduce here:
$ git clone ssh://.../tmp/empty cloned
Initialized empty Git repository in /tmp/cloned/.git/
warning: You appear to have cloned an empty repository.
$ git --version
git version 1.6.4.187.gd399.dirty
Maybe you have an older version of Git?
--
Matthieu
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Rustom Mody @ 2009-08-31 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <1251655664.31273.4.camel@localhost>
On Sun, Aug 30, 2009 at 11:37 PM, Daniele Segato
<daniele.bilug@gmail.com> wrote:
>
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
> > 2009/8/25 Frank Münnich <git@frank-muennich.com>:
> > > One thing I would like to ask you: what, if any, IDEs are you working with?
> >
> > I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
>
> Cheers,
> Daniele
How much mouse do you use and how much keyboard?
And now read http://steve.yegge.googlepages.com/effective-emacs.
Note: vi is ergonomically superior to emacs (shortest keystrokes, no
mouse at all) but emacs can do more than vi
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Sverre Rabbelier @ 2009-08-31 12:29 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800908310421u7de8ae58o361bd64a026384bf@mail.gmail.com>
Heya,
On Mon, Aug 31, 2009 at 04:21, Michael Wookey<michaelwookey@gmail.com> wrote:
> Provide a dummy variable to keep the compiler happy.
Should we not instead check the value?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Question about git-svn
From: martin liste larsson @ 2009-08-31 13:01 UTC (permalink / raw)
To: git
I have a problem using git-svn. Is this the right place to ask then?
I have followed Andy Delcambre's
http://herebeforeatreplies.com/2008/03/04/git-svn-workflow.html, but
it seems that not all my tags and branches are being imported from svn
to (local) git. That is, 'git branch -a' gives much less output (about
half) of the combination 'svn list http://repos/branches' and 'svn
list http://repos/tags'. What's missing seems to be the newest
branches and tags.
M.
^ permalink raw reply
* Re: [script] find largest pack objects
From: Antony Stubbs @ 2009-08-31 13:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0907092332030.21547@xanadu.home>
Sorry Nicolas,
Completely missed your message amongst the torrent of the git mailing
list - which I'm now unsubscribed from.. But sure, I'll ad this to my
todo list :)
Cheers,
Antony Stubbs,
sharca.com
On 10/07/2009, at 5:34 AM, Nicolas Pitre wrote:
> On Fri, 10 Jul 2009, Antony Stubbs wrote:
>
>> Blog post about git pruning history and finding large objects in
>> your repo:
>> http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
>>
>> This is a script I put together after migrating the Spring Modules
>> project
>> from CVS, using git-cvsimport (which I also had to patch, to get to
>> work on OS
>> X / MacPorts). I wrote it because I wanted to get rid of all the
>> large jar
>> files, and documentation etc, that had been put into source
>> control. However,
>> if _large files_ are deleted in the latest revision, then they can
>> be hard to
>> track down.
>>
>> #!/bin/bash
>> #set -x
>>
>> # Shows you the largest objects in your repo's pack file.
>> # Written for osx.
>> #
>> # @see
>> http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
>> # @author Antony Stubbs
>>
>> # set the internal field spereator to line break, so that we can
>> iterate
>> easily over the verify-pack output
>> IFS=$'\n';
>>
>> # list all objects including their size, sort by size, take top 10
>> objects=`git verify-pack -v .git/objects/pack/pack-*.idx | grep -v
>> chain |
>> sort -k3nr | head`
>>
>> echo "All sizes are in kB's. The pack column is the size of the
>> object,
>> compressed, inside the pack file."
>>
>> output="size,pack,SHA,location"
>> for y in $objects
>> do
>> # extract the size in bytes
>> size=$((`echo $y | cut -f 5 -d ' '`/1024))
>> # extract the compressed size in bytes
>> compressedSize=$((`echo $y | cut -f 6 -d ' '`/1024))
>> # extract the SHA
>> sha=`echo $y | cut -f 1 -d ' '`
>> # find the objects location in the repository tree
>> other=`git rev-list --all --objects | grep $sha`
>> #lineBreak=`echo -e "\n"`
>> output="${output}\n${size},${compressedSize},${other}"
>> done
>>
>> echo -e $output | column -t -s ', '
>
> This is certainly useful. Mind submitting a patch adding this
> script to
> contrib/stats/ ?
>
>
> Nicolas
^ permalink raw reply
* [PATCH] git-submodule and --upload-pack
From: Giulio Eulisse @ 2009-08-31 13:52 UTC (permalink / raw)
To: git
Ciao,
There was a thread a while ago aboyt having --upload-pack support for
git-submodule.
Given that there was no followup (as far as I can tell) and I needed
pretty much
the same functionality I ported Jason's patch to work on top of 1.6.4.2.
Comments?
Ciao,
Giulio
--
diff --git a/Documentation/git-submodule.txt b/Documentation/git-
submodule.txt
index 683ba1a..50aa930 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch]
- [--reference <repository>] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch]
+ [-u <git-upload-pack>] [--receive-pack <git-receive-
pack>] [--reference <repository>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -164,6 +164,19 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-upload-pack' program on the remote end. See
+ linkgit:git-fetch-pack[1].
+
+--receive-pack <receive-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-receive-pack' program on the remote end. See
+ linkgit:git-push[1].
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 5daf750..bf982a6 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,6 +30,14 @@ submodule.<name>.path::
submodule.<name>.url::
Defines an url from where the submodule repository can be cloned.
+submodule.<name>.receivepack::
+ The default program to execute on the remote side when pushing. See
+ option \--receive-pack of linkgit:git-push[1].
+
+submodule.<name>.uploadpack::
+ The default program to execute on the remote side when fetching. See
+ option \--upload-pack of linkgit:git-fetch-pack[1].
+
submodule.<name>.update::
Defines what to do when the submodule is updated by the superproject.
If 'checkout' (the default), the new commit specified in the
@@ -41,7 +49,6 @@ submodule.<name>.update::
This config option is overridden if 'git submodule update' is given
the '--merge' or '--rebase' options.
-
EXAMPLES
--------
@@ -53,12 +60,16 @@ Consider the following .gitmodules file:
[submodule "libbar"]
path = include/bar
- url = git://bar.com/git/lib.git
+ url = ssh://bar.com/~/git/lib.git
+ uploadpack = /home/you/bin/git-upload-pack-wrapper
+ receivepack = /home/you/bin/git-receive-pack-wrapper
This defines two submodules, `libfoo` and `libbar`. These are
expected to
be checked out in the paths 'include/foo' and 'include/bar', and for
both
submodules an url is specified which can be used for cloning the
submodules.
+For `libbar`, packs are retrieved and stored via the upload and receive
+wrappers, respectively.
SEE ALSO
--------
diff --git a/git-submodule.sh b/git-submodule.sh
index ebed711..25edd59 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -82,6 +82,8 @@ module_clone()
path=$1
url=$2
reference="$3"
+ uploadpack=$4
+ receivepack=$5
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -97,13 +99,30 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
+ uploadpackCmd=""
+
+ if test "$uploadpack"
+ then
+ uploadpackCmd="--upload-pack $uploadpack"
+ fi
+
if test -n "$reference"
then
- git-clone "$reference" -n "$url" "$path"
+ git-clone $uploadpackCmd "$reference" -n "$url" "$path"
else
- git-clone -n "$url" "$path"
+ git-clone $uploadpackCmd -n "$url" "$path"
fi ||
die "Clone of '$url' into submodule path '$path' failed"
+ if test "$uploadpack"
+ then
+ git config -f "${path}/.git/config" remote.origin.uploadpack
"$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config -f "${path}/.git/config" remote.origin.receivepack
"$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule
path '$path'."
+ fi
}
#
@@ -136,6 +155,16 @@ cmd_add()
reference="$1"
shift
;;
+ -u|--upload-pack)
+ case "$2" in '') usage ;; esac
+ uploadpack=$2
+ shift
+ ;;
+ --receive-pack)
+ case "$2" in '') usage ;; esac
+ receivepack=$2
+ shift
+ ;;
--)
shift
break
@@ -206,9 +235,17 @@ cmd_add()
;;
esac
git config submodule."$path".url "$url"
+ if test "$uploadpack"
+ then
+ git config submodule."$path".uploadpack "$uploadpack"
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$path".receivepack "$receivepack"
+ fi
else
- module_clone "$path" "$realrepo" "$reference" || exit
+ module_clone "$path" "$realrepo" "$reference" "$uploadpack"
"$receivepack" || exit
(
unset GIT_DIR
cd "$path" &&
@@ -224,7 +261,19 @@ cmd_add()
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
- git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".url "$repo" ||
+ die "Failed to register submodule '$path'"
+
+ if test "$uploadpack"
+ then
+ git config -f .gitmodules submodule."$path".uploadpack
"$uploadpack" ||
+ die "Failed to register submodule '$path'"
+ fi
+ if test "$receivepack"
+ then
+ git config -f .gitmodules submodule."$path".receivepack
"$receivepack" ||
+ die "Failed to register submodule '$path'"
+ fi
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -299,6 +348,19 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules
submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule
path '$path'."
+ fi
+
upd="$(git config -f .gitmodules submodule."$name".update)"
test -z "$upd" ||
git config submodule."$name".update "$upd" ||
@@ -384,7 +446,8 @@ cmd_update()
if ! test -d "$path"/.git -o -f "$path"/.git
then
- module_clone "$path" "$url" "$reference"|| exit
+ module_clone "$path" "$url" "$reference" "$(git config
submodule."$name".uploadpack)" \
+ "$(git config
submodule."$name".receivepack)" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -738,6 +801,18 @@ cmd_sync()
remote=$(get_default_remote)
say "Synchronizing submodule url for '$name'"
git config remote."$remote".url "$url"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules
submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$name'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in
submodule path '$name'."
+ fi
)
fi
done
^ permalink raw reply related
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Sitaram Chamarty @ 2009-08-31 14:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqskf8z0rj.fsf@bauges.imag.fr>
[apologies if you get this twice]
On Mon, Aug 31, 2009 at 4:52 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
> > Hello,
> >
> > Cloning an empty repo seems to produce a spurious error.
> > The repo still seems fine though.
>
> Can't reproduce here:
>
> $ git clone ssh://.../tmp/empty cloned
> Initialized empty Git repository in /tmp/cloned/.git/
> warning: You appear to have cloned an empty repository.
> $ git --version
> git version 1.6.4.187.gd399.dirty
>
> Maybe you have an older version of Git?
Had 1.6.4, just tried with 1.6.4.2 -- the error is still there, exactly so.
Anything I can do to provide more info?
To start with, this is Mandriva 2009.1, kernel 2.6.29, git built from
scratch locally (not an RPM or something). Should I try some other
things like strace? It's too minor to bother, if that's all it is,
assuming it's not a symptom of something larger :)
>
> --
> Matthieu
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Matthieu Moy @ 2009-08-31 14:47 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90908310730u53ee27d3nd2b66c1f58202e7@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> To start with, this is Mandriva 2009.1, kernel 2.6.29, git built from
> scratch locally (not an RPM or something). Should I try some other
> things like strace?
Setting $GIT_TRACE to 2 can help, too. The problem is that the git
instance you want to debug is the remote one, I don't know if there's
a better way to do that than putting a wrapper script for
git-upload-pack ...
--
Matthieu
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-08-31 16:41 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Matthieu Moy, git
In-Reply-To: <2e24e5b90908310730u53ee27d3nd2b66c1f58202e7@mail.gmail.com>
On Mon, Aug 31, 2009 at 08:00:41PM +0530, Sitaram Chamarty wrote:
> > Maybe you have an older version of Git?
>
> Had 1.6.4, just tried with 1.6.4.2 -- the error is still there, exactly so.
>
> Anything I can do to provide more info?
IIRC, the message you are seeing comes when the _server_ is an older
version of git. It is harmless, though.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Daniel Barkalow @ 2009-08-31 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskfat07h.fsf@alter.siamese.dyndns.org>
On Sat, 29 Aug 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> There was a discussion that suggests that the use of colon ':' before vcs
> >> helper name needs to be corrected. Nothing happened since.
> >
> > I believe the outcome of that discussion was:
> >
> > - We want to keep supporting using regular location URLs that are URLs of
> > git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
> > and we probably want to do it with a helper which runs when
> > run_command() is given "remote-<scheme>". I think installing hardlinks
> > in EXECPATH ended up being the best implementation here.
>
> That is different from what I recall.
>
> I think you said <scheme> in the above to mean that in the general URL
> syntax, <scheme> refers to the token before the colon, and you would be
> feeding the rest (i.e. after the colon, and for many <scheme>'s it
> typically begins with //) to the scheme.
>
> A flaw with this that was pointed out was that this conflicts with the
> scp-like syntax. A remote.$name.url of foo:bar/baz could name
> $HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
> source "foo" helper recognizes with the name bar/baz.
>
> If I recall correctly, suggestions made later in the discussion were to
> use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
> use it to choose remote-<helper> (and I think I probably would vote for
> double-colon, if only to avoid confusion with our own earlier misdesigned
> syntax git+ssh://), so the canonical syntax would be:
(with the syntax <helper>+, "git+ssh://" would specify the helper "git",
which is as good an explicit identifier of the internal handling as any)
>
> <helper>::<whatever is fed to the helper, typicall a URL>
>
> while we would support obvious short-hands for transports we traditionally
> supported without explicit "<helper>::" prefix when we choose to eject it
> from "built-in" set of transports.
>
> E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
> based walker, so if you spell it in the very canonical form, the url would
> be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
> use it. Instead, the transport dispatcher internally recognizes http://
> and picks the curl based walker helper, which is remote-curl without any
> extra hardlinks.
If the policy is that we're going to have "traditionally supported"
schemes, where the internal code knows what helper supports them, I can
fix up the series so that the curl-based helper is named "curl", and we
can say that the check for "http://", "ftp://", and "https://" is
recognizing traditionally-supported schemes, and we can defer coming up
with what the syntax for the explicit handler selection is. (For that
matter, if there's a // after the colon, it's obviously not a
handy ssh-style location, since the second slash would do nothing)
I think you're right that we decided that things we used to support
internally are a special case, and there's no need to try to generalize
them to be the general mechanism (even though I think we simultaneously
worked out how to implement the design we were abandoning, which confused
my memory).
> > - We want to support a separate "vcs" option for cases where repositories
> > in the foreign system need to be addressed through the combination of a
> > bunch of options, which will be read from the configuration by the
> > helper. The helper which gets run is "remote-<value of vcs option>".
> > This is in pu.
>
> After you explained this in the thread (I think for the second time), I
> see no problem with this, except that I think to support this we should
> notice and raise an error when we see a remote has both vcs and url,
> because the only reason we would want to say "vcs", if I recall your
> explanation correctly, is that such a transport does not have the concept
> of URL, i.e. a well defined single string that identifies the repository.
A user who mostly uses Perforce as a foreign repositories but is using a
SVN repo on occasion might want to use "vcs" regardless, but I agree with
forcing the helper to use a different option for the case of a URL that
git isn't going to look at. That is, you ought to be able to use:
[remote "origin"]
vcs = svn
(something) = http://svn.savannah.gnu.org/...
But "(something)" shouldn't be "url".
So my changes will be:
- name the curl-based helper executable "git-remote-curl", and run it for
traditionally supported schemes by special-case.
- prohibit using both "vcs" and "url" in a remote.
Agreed?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Sverre Rabbelier @ 2009-08-31 17:12 UTC (permalink / raw)
To: Jeff King; +Cc: Sitaram Chamarty, Matthieu Moy, git
In-Reply-To: <20090831164146.GA23245@coredump.intra.peff.net>
Heya,
On Mon, Aug 31, 2009 at 18:41, Jeff King<peff@peff.net> wrote:
> IIRC, the message you are seeing comes when the _server_ is an older
> version of git. It is harmless, though.
Mhhhh, is it some weird interaction between 'empty repository' patch
and old server versions, or did this happen too before my patch was
applied?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Matthieu Moy @ 2009-08-31 17:25 UTC (permalink / raw)
To: Jeff King; +Cc: Sitaram Chamarty, git
In-Reply-To: <20090831164146.GA23245@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Aug 31, 2009 at 08:00:41PM +0530, Sitaram Chamarty wrote:
>
>> > Maybe you have an older version of Git?
>>
>> Had 1.6.4, just tried with 1.6.4.2 -- the error is still there, exactly so.
>>
>> Anything I can do to provide more info?
>
> IIRC, the message you are seeing comes when the _server_ is an older
> version of git. It is harmless, though.
Since the client and server are the same machine:
$ git clone ssh://sitaram@localhost/home/sitaram/t/a b
I'd bet Sitaram has two installations of git, and plain ssh to the
machine points to the old one (like a $PATH set in ~/.login and not
~/.profile or something like that).
--
Matthieu
^ permalink raw reply
* Re: [PATCH 3/3] transport: don't show push status if --quiet is given
From: Sebastian Pipping @ 2009-08-31 18:33 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Albert Astals Cid,
Pau Garcia i Quiles, git
In-Reply-To: <20090805211700.GA24697@coredump.intra.peff.net>
Hello!
I run git push in a cron job, too. I want mails in error cases only
so I need git push to print errors but _only_ errors to stderr. That
seems impossible with 1.6.4.* and related to what you're discussing here.
Does the patch you're building address that case already? has it been
applied to any branch already? I got a bit lost in this thread, sorry.
Sebastian
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Tom Werner @ 2009-08-31 18:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Johan Sorensen, Jeff King, Tom Preston-Werner,
git
In-Reply-To: <7vljl3p2iw.fsf@alter.siamese.dyndns.org>
On Fri, Aug 28, 2009 at 11:17 PM, Junio C Hamano<gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> I'd like to suggest the following line from the original patch:
>>>
>>> full-pack integer::
>>> 1 if the request was considered a full clone, 0 if it was a
>>> partial update (fetch)
>>
>> If it is all "want" and no "have", it is clone or fetch into empty
>> repository. If additionaly "want"s cover all refs, it is a clone.
>> No need to pass this information: it can be derived.
>
> Well, not exactly.
>
> Here is an iffy RFC patch. Iffy not in the sense that its implementation
> is questionable, but in the sense that I am not really convinced if the
> distinction between fetching some (or in the worst case, most) but not all
> refs, and fetching full set of refs, into an empty repository is something
> worth making.
>
> Does anybody from GitHub have any input? Is there something that can
> still improved to suit GitHub's needs?
From GitHub's perspective, we'd treat any clone or fetch into an empty
repo as a clone operation, whether or not that included all of the
refs that were available. For us, the distinction between full and
partial clones is too nuanced to warrant additional code. I'd be happy
with the previous incarnation of the post-upload-pack that simply
sends the HAVEs and WANTs.
Tom
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-08-31 19:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Sitaram Chamarty, Matthieu Moy, git
In-Reply-To: <fabb9a1e0908311012q4cea2d51i2c2f0cbceac0cab@mail.gmail.com>
On Mon, Aug 31, 2009 at 07:12:44PM +0200, Sverre Rabbelier wrote:
> On Mon, Aug 31, 2009 at 18:41, Jeff King<peff@peff.net> wrote:
> > IIRC, the message you are seeing comes when the _server_ is an older
> > version of git. It is harmless, though.
>
> Mhhhh, is it some weird interaction between 'empty repository' patch
> and old server versions, or did this happen too before my patch was
> applied?
I think the former. I thought it was discussed before, but the only
reference I can find is this (see the end of the email):
http://article.gmane.org/gmane.comp.version-control.git/107626
and I don't see any followup for that specific part of the mail.
-Peff
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Sverre Rabbelier @ 2009-08-31 19:09 UTC (permalink / raw)
To: Jeff King; +Cc: Sitaram Chamarty, Matthieu Moy, git
In-Reply-To: <20090831190827.GA4876@sigill.intra.peff.net>
Heya,
On Mon, Aug 31, 2009 at 21:08, Jeff King<peff@peff.net> wrote:
> I think the former. I thought it was discussed before, but the only
> reference I can find is this (see the end of the email):
>
> http://article.gmane.org/gmane.comp.version-control.git/107626
Ah, yeup, I see.
> and I don't see any followup for that specific part of the mail.
I don't remember any follow up to that either, shame on me :(.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-08-31 19:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sitaram Chamarty, git
In-Reply-To: <vpqocpvevzx.fsf@bauges.imag.fr>
On Mon, Aug 31, 2009 at 07:25:22PM +0200, Matthieu Moy wrote:
> Since the client and server are the same machine:
>
> $ git clone ssh://sitaram@localhost/home/sitaram/t/a b
>
> I'd bet Sitaram has two installations of git, and plain ssh to the
> machine points to the old one (like a $PATH set in ~/.login and not
> ~/.profile or something like that).
Oh, indeed. I didn't notice that his host was @localhost. :)
But yes, that would be my guess, as well. Trying "ssh sitaram@localhost
git version" would be a good clue.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] transport: don't show push status if --quiet is given
From: Jeff King @ 2009-08-31 19:28 UTC (permalink / raw)
To: Sebastian Pipping
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Albert Astals Cid,
Pau Garcia i Quiles, git
In-Reply-To: <4A9C175E.6020905@hartwork.org>
On Mon, Aug 31, 2009 at 08:33:02PM +0200, Sebastian Pipping wrote:
> I run git push in a cron job, too. I want mails in error cases only
> so I need git push to print errors but _only_ errors to stderr. That
> seems impossible with 1.6.4.* and related to what you're discussing here.
>
> Does the patch you're building address that case already? has it been
> applied to any branch already? I got a bit lost in this thread, sorry.
Junio applied the series, and it is in 'master' right now (and so should
be part of the upcoming 1.6.5).
Using "git push -q" will do what you want, but playing with it a bit, I
think there is one bit missing from the original series:
-- >8 --
Subject: [PATCH] push: teach --quiet to suppress "Everything up-to-date"
This should have been part of 481c7a6, whose goal was to
make "git push -q" silent unless there is an error.
Signed-off-by: Jeff King <peff@peff.net>
---
transport.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index ce91387..f2bd998 100644
--- a/transport.c
+++ b/transport.c
@@ -908,7 +908,7 @@ int transport_push(struct transport *transport,
update_tracking_ref(transport->remote, ref, verbose);
}
- if (!ret && !refs_pushed(remote_refs))
+ if (!quiet && !ret && !refs_pushed(remote_refs))
fprintf(stderr, "Everything up-to-date\n");
return ret;
}
--
1.6.4.2.372.gf7961.dirty
^ permalink raw reply related
* Re: [PATCH 3/3] transport: don't show push status if --quiet is given
From: Sebastian Pipping @ 2009-08-31 19:39 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Albert Astals Cid,
Pau Garcia i Quiles, git
In-Reply-To: <20090831192834.GC4876@sigill.intra.peff.net>
Jeff King wrote:
> Junio applied the series, and it is in 'master' right now (and so should
> be part of the upcoming 1.6.5).
>
> Using "git push -q" will do what you want,
That's great news. Thanks for the quick reply.
> but playing with it a bit, I
> think there is one bit missing from the original series:
>
> -- >8 --
> Subject: [PATCH] push: teach --quiet to suppress "Everything up-to-date"
>
> This should have been part of 481c7a6, whose goal was to
> make "git push -q" silent unless there is an error.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> transport.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/transport.c b/transport.c
> index ce91387..f2bd998 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -908,7 +908,7 @@ int transport_push(struct transport *transport,
> update_tracking_ref(transport->remote, ref, verbose);
> }
>
> - if (!ret && !refs_pushed(remote_refs))
> + if (!quiet && !ret && !refs_pushed(remote_refs))
> fprintf(stderr, "Everything up-to-date\n");
> return ret;
> }
Would be great to have that patch in too.
Sebastian
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Björn Steinbrink @ 2009-08-31 20:19 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Sitaram Chamarty, git
In-Reply-To: <20090831191032.GB4876@sigill.intra.peff.net>
On 2009.08.31 15:10:32 -0400, Jeff King wrote:
> On Mon, Aug 31, 2009 at 07:25:22PM +0200, Matthieu Moy wrote:
>
> > Since the client and server are the same machine:
> >
> > $ git clone ssh://sitaram@localhost/home/sitaram/t/a b
> >
> > I'd bet Sitaram has two installations of git, and plain ssh to the
> > machine points to the old one (like a $PATH set in ~/.login and not
> > ~/.profile or something like that).
>
> Oh, indeed. I didn't notice that his host was @localhost. :)
>
> But yes, that would be my guess, as well. Trying "ssh sitaram@localhost
> git version" would be a good clue.
I see the problem here, too.
doener@atjola:~ $ (mkdir a; cd a; git init)
Initialized empty Git repository in /home/doener/a/.git/
doener@atjola:~ $ git clone localhost:a b
Initialized empty Git repository in /home/doener/b/.git/
warning: You appear to have cloned an empty repository.
fatal: The remote end hung up unexpectedly
doener@atjola:~ $ ssh localhost git --version
git version 1.6.4.2.236.gf324c
Björn
^ permalink raw reply
* `Git Status`-like output for two local branches
From: Tim Visher @ 2009-08-31 20:20 UTC (permalink / raw)
To: Git Mailing List
Hello Everyone,
I'm interested in being able to get a message such as 'dev and master
have diverged, having 1 and 2 commits different respectively' or 'dev
is behind master by 3 commits and can be fast-forwarded', etc. I'm
sure this is simple, but I can't figure out how to do it in the docs.
Sorry for the noobness of the question.
Thanks!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* from local to github
From: sigbackup @ 2009-08-31 20:46 UTC (permalink / raw)
To: git
Hello guys,
I'm a git newbie and I'm looking for some good references about using
git locally (on Mac) and synchronize my repositories to my github
account and from there to a Win2003 production server.
Can anyone help me with this?
Thanks and have a great day.
Sig
^ permalink raw reply
* from local to github
From: sigbackup @ 2009-08-31 20:46 UTC (permalink / raw)
To: git
Hello guys,
I'm a git newbie and I'm looking for some good references about using
git locally (on Mac) and synchronize my repositories to my github
account and from there to a Win2003 production server.
Can anyone help me with this?
Thanks and have a great day.
Sig
^ 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