* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: David Soria Parra @ 2009-09-25 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0909250810270.4985@pacific.mpi-cbg.de>
On 2009-09-25, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> as some of you already know, I will be unable to Git Together with other
> Gits in California this year. So the only version of such a Git Together
> I will have this year is the Berlin one.
I'm not able to attend this year, but I would be really great to have a
germany or european based gittogether every year.
David
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Nicolas Pitre @ 2009-09-25 20:47 UTC (permalink / raw)
To: Jason Merrill; +Cc: Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <4ABD25FE.2040902@redhat.com>
On Fri, 25 Sep 2009, Jason Merrill wrote:
> On 09/25/2009 03:53 PM, Nicolas Pitre wrote:
> > I did reproduce the issue with git:// back when this discussion started.
> > I also asked for more information about the remote which didn't come
> > forth.
>
> Looking back, I only see you asking about the git version on the server, which
> is 1.6.4.
>
> So again:
>
> git clone git://gcc.gnu.org/git/gcc.git
> (1399509 objects, ~600MB .git dir)
> git gc --prune=now (988906 objects, ~450MB .git dir)
>
> ...then
>
> git clone git://gcc.gnu.org/git/gcc.git --reference $firstclone
> (573401 objects, ~550MB .git dir)
> git fsck (clean)
> git gc --prune=now (5 objects, ~7MB .git dir)
>
> What's going on here?
Some screw up.
Do you have access to the remote machine? Is it possible to have a
tarball of the gcc.git directory from there?
Nicolas
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Jason Merrill @ 2009-09-25 20:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <alpine.LFD.2.00.0909251551290.4997@xanadu.home>
On 09/25/2009 03:53 PM, Nicolas Pitre wrote:
> I did reproduce the issue with git:// back when this discussion started.
> I also asked for more information about the remote which didn't come
> forth.
Looking back, I only see you asking about the git version on the server,
which is 1.6.4.
So again:
git clone git://gcc.gnu.org/git/gcc.git
(1399509 objects, ~600MB .git dir)
git gc --prune=now (988906 objects, ~450MB .git dir)
...then
git clone git://gcc.gnu.org/git/gcc.git --reference $firstclone
(573401 objects, ~550MB .git dir)
git fsck (clean)
git gc --prune=now (5 objects, ~7MB .git dir)
What's going on here?
Jason
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 20:04 UTC (permalink / raw)
To: alexandrul; +Cc: Git Mailing List
In-Reply-To: <4ABD178E.8000508@gmail.com>
On Fri, Sep 25, 2009 at 20:18, alexandrul <alexandrul.ct@gmail.com> wrote:
>
> then check your PATH and the configuration files from your HOME folder (as
> recommended earlier).
>
I have uninstalled git, verified git folder was removed.
I have removed git/cmd from the PATH in Windows and I have removed the
following files from users/marco
.bash_history
.gitconfig
.gitk
I have reinstalled all and it still does not work. There are other
files in HOME that I need to remove ?
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Nicolas Pitre @ 2009-09-25 19:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jason Merrill, git, Hin-Tak Leung
In-Reply-To: <vpqvdj6izt6.fsf@bauges.imag.fr>
On Fri, 25 Sep 2009, Matthieu Moy wrote:
> Jason Merrill <jason@redhat.com> writes:
>
> > On 08/09/2009 03:43 AM, Andreas Schwab wrote:
> >> Nicolas Pitre<nico@cam.org> writes:
> >>
> >>> If you do a clone using the git:// protocol and the server sends you
> >>> only the ref for the trunk branch,
> >>
> >> A clone will fetch all branches from refs/heads/*.
> >>
> >>> then it should send you only objects reachable from that branch.
> >>
> >> Apparantly this does not work. I'd guess the extra objects are needed
> >> due to the delta compression.
> >
> > I just tried doing a clone of the GCC repository, then git gc
> > --prune=now, and another clone specifying --reference to the first,
> > and it wanted to download all the unreachable objects again. So it
> > doesn't seem to be a compression issue.
> >
> > This is with git 1.6.4 on both ends.
>
> Which protocol did you use?
>
> If you use git:// or ssh://, it's normally a security feature that Git
> sends you only reachable objects. If it doesn't, it's a serious bug.
I did reproduce the issue with git:// back when this discussion started.
I also asked for more information about the remote which didn't come
forth.
Nicolas
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Jason Merrill @ 2009-09-25 19:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Nicolas Pitre, Hin-Tak Leung
In-Reply-To: <vpqvdj6izt6.fsf@bauges.imag.fr>
On 09/25/2009 03:34 PM, Matthieu Moy wrote:
> Which protocol did you use?
git://
Jason
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Matthieu Moy @ 2009-09-25 19:34 UTC (permalink / raw)
To: Jason Merrill; +Cc: git, Nicolas Pitre, Hin-Tak Leung
In-Reply-To: <4ABD0669.7050309@redhat.com>
Jason Merrill <jason@redhat.com> writes:
> On 08/09/2009 03:43 AM, Andreas Schwab wrote:
>> Nicolas Pitre<nico@cam.org> writes:
>>
>>> If you do a clone using the git:// protocol and the server sends you
>>> only the ref for the trunk branch,
>>
>> A clone will fetch all branches from refs/heads/*.
>>
>>> then it should send you only objects reachable from that branch.
>>
>> Apparantly this does not work. I'd guess the extra objects are needed
>> due to the delta compression.
>
> I just tried doing a clone of the GCC repository, then git gc
> --prune=now, and another clone specifying --reference to the first,
> and it wanted to download all the unreachable objects again. So it
> doesn't seem to be a compression issue.
>
> This is with git 1.6.4 on both ends.
Which protocol did you use?
If you use git:// or ssh://, it's normally a security feature that Git
sends you only reachable objects. If it doesn't, it's a serious bug.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: alexandrul @ 2009-09-25 19:18 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909251208v68a561beu2d9f21ae2417fdd6@mail.gmail.com>
Marco Costalba wrote:
>> This is a good idea, thanks. I will copy the git folder to a working
>> PC and we will see....
>>
>
> I have copied the whole Git folder to another PC with windows xp.
>
> I have moved the Git directory and all its subfolders under program
> files instead of the old that I have renamed.
>
> And everything worked as expected ! no problem and from git bash I
> verified that the new copied version was running.
>
> I really don't know what to think....
>
then check your PATH and the configuration files from your HOME folder
(as recommended earlier).
Have a nice day,
A.
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 19:08 UTC (permalink / raw)
To: alexandrul; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909251144ma9e4dccmb54a64f364b820fa@mail.gmail.com>
>
> This is a good idea, thanks. I will copy the git folder to a working
> PC and we will see....
>
I have copied the whole Git folder to another PC with windows xp.
I have moved the Git directory and all its subfolders under program
files instead of the old that I have renamed.
And everything worked as expected ! no problem and from git bash I
verified that the new copied version was running.
I really don't know what to think....
^ permalink raw reply
* Re: 'git branch --no-merge' is ambiguous
From: Andreas Schwab @ 2009-09-25 18:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pierre Habouzit, Git Mailing List
In-Reply-To: <4ABC9B69.5010205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Look here:
>
> $ git branch --merge
> * master
> $ git branch --no-merge
> error: Ambiguous option: no-merge (could be --no-merged or --no-merged)
> usage: ...
> --no-merged <commit> print only not merged branches
> --merged <commit> print only merged branches
>
> I tried to debug it, but parse_long_opt() is such awful spaghetti code
> that I don't grok it. Please help.
parse_long_opt always matches both --opt and --no-opt for any option
"opt", and only get_value checks whether --no-opt is actually valid.
Since the options for git branch contains both "no-merged" and "merged"
there are two matches for --no-merge, but no exact match. With this
patch the negation of a NONEG option is rejected earlier, but it changes
the error message from "option `no-opt' isn't available" to "unknown
option `no-opt'".
diff --git a/parse-options.c b/parse-options.c
index a64a4d6..f559411 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -230,6 +230,9 @@ is_abbreviated:
abbrev_flags = flags;
continue;
}
+ /* negation allowed? */
+ if (options->flags & PARSE_OPT_NONEG)
+ continue;
/* negated and abbreviated very much? */
if (!prefixcmp("no-", arg)) {
flags |= OPT_UNSET;
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 18:44 UTC (permalink / raw)
To: alexandrul; +Cc: Git Mailing List
In-Reply-To: <4ABD0E90.5030301@gmail.com>
On Fri, Sep 25, 2009 at 19:40, alexandrul <alexandrul.ct@gmail.com> wrote:
>> Now path is C:\Program Files\Git\bin
>>
>> I have even deleted the contents of cmd directory to be sure they were
>> not called.
>>
>> But unfortunatly the problem persists.
>
> Could you copy the git installation folder to another PC and see if the
> problem is still present? Or archive it and upload it on some file sharing
> service?
>
This is a good idea, thanks. I will copy the git folder to a working
PC and we will see....
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: alexandrul @ 2009-09-25 18:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909251125t6ed59b1fv953eee597adc4471@mail.gmail.com>
> Now path is C:\Program Files\Git\bin
>
> I have even deleted the contents of cmd directory to be sure they were
> not called.
>
> But unfortunatly the problem persists.
Could you copy the git installation folder to another PC and see if the
problem is still present? Or archive it and upload it on some file
sharing service?
Have a nice day,
A.
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 18:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4ABCE167.7060204@viscovery.net>
On Fri, Sep 25, 2009 at 16:27, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Marco Costalba schrieb:
>> On Fri, Sep 25, 2009 at 15:12, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Does that work?
>>>
>>
>> No it doesn't.
>>
>> I had already C:\Program Files\Git\cmd in path, probably added by
>> msysgit installation.
>
> The point of the exercise is to not use the git.cmd wrapper. I.e. point
> your path not into C:\Program Files\Git\cmd, but into the bin directories
> so that you run git.exe, not git.cmd.
>
Now path is C:\Program Files\Git\bin
I have even deleted the contents of cmd directory to be sure they were
not called.
But unfortunatly the problem persists.
^ permalink raw reply
* Re: git clone sending unneeded objects (was : git gc expanding packed data?)
From: Jason Merrill @ 2009-09-25 18:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nicolas Pitre, Hin-Tak Leung, git
In-Reply-To: <m2k51dzb39.fsf@linux-m68k.org>
On 08/09/2009 03:43 AM, Andreas Schwab wrote:
> Nicolas Pitre<nico@cam.org> writes:
>
>> If you do a clone using the git:// protocol and the server sends you
>> only the ref for the trunk branch,
>
> A clone will fetch all branches from refs/heads/*.
>
>> then it should send you only objects reachable from that branch.
>
> Apparantly this does not work. I'd guess the extra objects are needed
> due to the delta compression.
I just tried doing a clone of the GCC repository, then git gc
--prune=now, and another clone specifying --reference to the first, and
it wanted to download all the unreachable objects again. So it doesn't
seem to be a compression issue.
This is with git 1.6.4 on both ends.
Jason
^ permalink raw reply
* Enhance your intimate response.
From: Louie Allen @ 2009-09-25 17:59 UTC (permalink / raw)
To: git
100% success with chicks http://il.necksister.com/
^ permalink raw reply
* [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-25 16:43 UTC (permalink / raw)
To: git
In-Reply-To: <215cc4f241162377b9249c2b3d74050cc77bac16.1253893253.git.chressie@gmail.com>
According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
We do not rely here on the LC_ALL value we get from the environment.
Signed-off-by: Christian Himpel <chressie@gmail.com>
---
sorry for being so noisy, but forgot to signoff last time
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 0ddd80f..c132f50 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -205,7 +205,7 @@ check_patch_format () {
# and see if it looks like that they all begin with the
# header field names...
sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
- egrep -v '^[!-9;-~]+:' >/dev/null ||
+ LC_ALL=C egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
} < "$1" || clean_abort
--
1.6.4.4
^ permalink raw reply related
* Interim maintainer tree
From: Shawn O. Pearce @ 2009-09-25 16:05 UTC (permalink / raw)
To: git
Junio is on vaction for the next week. In his absence Peff and I
are trying to keep up with current patches in my fork:
git://repo.or.cz/git/spearce.git
http://repo.or.cz/r/git/spearce.git
Right now the tree matches Junio's last push, I'll try to pick up
the patches since then and push later today.
--
Shawn.
^ permalink raw reply
* gitolite update
From: Sitaram Chamarty @ 2009-09-25 15:49 UTC (permalink / raw)
To: git
This is an update on gitolite, the "lite" rewrite of gitosis (in
perl) for a typical "corporate" environment, after a month of
moderately heavy use at my workplace and quite a lot of updates
and improvements (thanks to a lot of people on the list and on
IRC, and colleagues at work). The latest version is at
git://github.com/sitaramc/gitolite.git -- I recommend the
"master" branch for most people.
My original reasons were per-branch permissions, limiting
rewind/non-ff to specific people, and to install on any Unix
with no dependencies and no root access, assuming git itself was
already installed somehow.
Over the past month it acquired some more features/improvements.
There's also oodles of documentation -- this is not one of those
"figure it out yourself" systems :-)
Summary
=======
* simpler, but far more powerful, config file syntax,
including specifying gitweb/daemon access. You'll need this
power if you manage lots of users + repos + combinations of
access
* more comprehensive logging
* "personal namespace" prefix for each dev
* migration guide and simple converter for gitosis conf file
* "exclude" (or "deny" rights in the config file) -- this is
the "rebel" branch in the repository, and always will be ;-)
All these points (and more) are explained in detail at
http://github.com/sitaramc/gitolite/blob/ml/update.mkd (I wasn't
sure if it was OK to post all that to the list; it was a bit
long).
Anyway, if you're looking for features like this, give it a
whirl -- I'd appreciate comments from users or even just people
who read that page and have some thing to say. And needless to
say I'll gladly help anyone having trouble; preferably on #git
but the mailing list or personal email are fine too.
--
Sitaram
sitaramc@gmail.com / sitaram.chamarty@tcs.com
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Michael Gaffney @ 2009-09-25 15:48 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, Shawn Spearce, git
In-Reply-To: <891180.68852.qm@web27805.mail.ukl.yahoo.com>
My only real item is that I'd like to have the .* eclipse projects added
to gitignore so I'm not having to constantly stash mine off to the side
if I make changes.
-Mike
^ permalink raw reply
* [PATCH 2/2 v2] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-25 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <dc8a4205128d65e69587292a42c714792315a9df.1253891124.git.chressie@gmail.com>
According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
We do not rely here on the LC_ALL value we get from the environment.
---
This is probably a saner approach :)
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 0ddd80f..c132f50 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -205,7 +205,7 @@ check_patch_format () {
# and see if it looks like that they all begin with the
# header field names...
sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
- egrep -v '^[!-9;-~]+:' >/dev/null ||
+ LC_ALL=C egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
} < "$1" || clean_abort
--
1.6.4.4
^ permalink raw reply related
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Johannes Sixt @ 2009-09-25 15:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250718y51709692kc8d1e2586017341b@mail.gmail.com>
Marco Costalba schrieb:
> On Fri, Sep 25, 2009 at 15:12, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Does that work?
>>
>
> No it doesn't.
>
> I had already C:\Program Files\Git\cmd in path, probably added by
> msysgit installation.
The point of the exercise is to not use the git.cmd wrapper. I.e. point
your path not into C:\Program Files\Git\cmd, but into the bin directories
so that you run git.exe, not git.cmd.
-- Hannes
^ permalink raw reply
* [PATCH 2/2] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-25 15:17 UTC (permalink / raw)
To: git
In-Reply-To: <d7d039c304614d8d39fd2e7ad8d036a77121cc4f.1253891124.git.chressie@gmail.com>
According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
We do not rely here on the LC_ALL value we get from the environment.
Signed-off-by: Christian Himpel <chressie@gmail.com>
---
I don't know if this kind of patch is desired, but according to egrep(1)
it's not reliable to use the range expression with different character
sets than US-ASCII.
So this patch forces the usage of US-ASCII.
Regards,
chressie
git-am.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 0ddd80f..e4dd49a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -204,9 +204,13 @@ check_patch_format () {
# discarding the indented remainder of folded lines,
# and see if it looks like that they all begin with the
# header field names...
+ _tmp_locale=$LC_ALL
+ export LC_ALL=C
sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
+ export LC_ALL=$_tmp_locale
+ unset $_tmp_locale
fi
} < "$1" || clean_abort
}
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/2] git-am: fixed patch_format detection according to RFC2822
From: Christian Himpel @ 2009-09-25 15:14 UTC (permalink / raw)
To: git
RFC2822 specifies in paragraph 3.6.8, that optional header fields are
made up of any printable US-ASCII character except ' ' (space) and ':'
(colon).
The pattern for the egrep command is changed to match all of these
characters.
Signed-off-by: Christian Himpel <chressie@gmail.com>
---
Hi,
I had a problem with applying a patch with 'git am', because the one
header fields in the patch-e-mail contained numbers. So I read the
RFC2822 what they say about header fields. Unbelievable but any
printable character except space and colon are allowed in header fields.
So I changed the egrep expression according to this rule.
Regards,
chressie
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..0ddd80f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -205,7 +205,7 @@ check_patch_format () {
# and see if it looks like that they all begin with the
# header field names...
sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
- egrep -v '^[A-Za-z]+(-[A-Za-z]+)*:' >/dev/null ||
+ egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
} < "$1" || clean_abort
--
1.6.4.4
^ permalink raw reply related
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 15:13 UTC (permalink / raw)
To: alexandrul; +Cc: Git Mailing List
In-Reply-To: <4ABCD6AF.8080407@gmail.com>
On Fri, Sep 25, 2009 at 15:41, alexandrul <alexandrul.ct@gmail.com> wrote:
>
> If nothing else works, you could try to uninstall your current version of
> git, clean up any traces left, and reinstall.
>
> http://code.google.com/p/msysgit/issues/detail?id=336
>
> Have a nice day,
> A.
>
Thanks, I have tried but with no success.
Another info is that it seems git related, from msysgit bash shell:
$ ls -a
. .. .git
$ ls -A
.git
$ git --version
git version 1.6.4.msysgit.0
$ git --VERSION
git version 1.6.4.msysgit.0
So only the git command seems to treat command line arguments in a
case-insensitive way, while other commands do not.
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: alexandrul @ 2009-09-25 14:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250430x14b0d7f4w5e22467ddd66cc29@mail.gmail.com>
>> What (old) version of msgit do you suggest me to try to verify if it
>> is a new problem ?
>>
>> BTW gitk does not work correctly. It loads the revisions but doesn't
>> show the diffs.
>>
>
> Also installing an old version I have the same wrong behaviour and the
> same version works on another PC and with the same repository I am
> testing with.
If nothing else works, you could try to uninstall your current version
of git, clean up any traces left, and reinstall.
http://code.google.com/p/msysgit/issues/detail?id=336
Have a nice day,
A.
^ 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