* Re: thoughts on a possible "pre-upload" hook
From: Sitaram Chamarty @ 2009-09-25 11:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthieu Moy, Randal L. Schwartz, git
In-Reply-To: <20090922161725.GS14660@spearce.org>
sorry I couldn't reply till now...
On Tue, Sep 22, 2009 at 9:47 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> >>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
>> > Sitaram> As git is used more and more in corporate-type environments, at some
>> > Sitaram> point it becomes convenient to have *branches* (or more accurately,
>> > Sitaram> refs) that are not readable.
>>
>> But that alone would make it rather painfull for the user : "git
>> clone" would fail if any branch in the repository is not readable, for
>> example.
>
> No, what Sitaram is asking for is to have upload-pack not advertise
> the hidden branches. By not advertising them, the client cannot
> send a "want" request for them, and they won't appear in the list
> that clone believes exists when it creates the new local repository.
> Thus, clone would succeed.
yes that would be precisely what I meant. The hook would (somehow) be
able to influence which, among the available ones, get advertised.
>> Also, don't forget that branches are just references, which means that
>> if you prevent reference A from being uploaded, then another reference
>> B may point to the same commits as A, and then you can bypass the
>> safety hook on A by using B.
>
> Yes. But this is no different than having two different git
> repositories, A.git and B.git. Pushing commits from A.git into B.git
> allows someone to bypass A.git's filesystem read access control by
> instead reading those commits from B.git.
yes indeed -- if someone were to foolishly merge a "secret" branch
into a "normal" branch, so that it is now reachable from a "normal"
branch, that's his problem -- that cannot be within the scope of this
check.
It's the user's job to make sure that *only* his "secret" branch can
reach the secret stuff, other branches cannot reach it, and all git
has to do is ensure that no one can "want" that branch if they're not
supposed to see it.
--
Sitaram
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Sitaram Chamarty @ 2009-09-25 12:01 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909240751k3a799750h121935a79439b389@mail.gmail.com>
On Thu, Sep 24, 2009 at 8:21 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> Hi,
>
> This is probably another one of my stupid questions.
>
> Gitosis obviously uses keypairs but the config file addresses the user
> by name/host. How does gitosis connect the two together? Is it any
> more complicated than the user detail at the end of the public key?
>
> The second part of my question then is is it possible to use the same
> private key on more than one host?
Everything you ever wanted to know about how gitosis and ssh work
together: http://sitaramc.github.com/0-installing/9-gitosis-server-install.html
Very verbose. (I've even been told it is too verbose but I chose to
ignore him ;-)
--
Sitaram
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Matthieu Moy @ 2009-09-25 12:29 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Shawn O. Pearce, Randal L. Schwartz, git
In-Reply-To: <2e24e5b90909250454s7ed35b9ch10b954b0b1a40cfe@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> yes indeed -- if someone were to foolishly merge a "secret" branch
> into a "normal" branch, so that it is now reachable from a "normal"
> branch, that's his problem -- that cannot be within the scope of this
> check.
Merging is not the only scenario. Adding a tag could make secret
things become visible too. I'm not saying the approach isn't viable,
but if it gets implemented, it should be done with care to make sure
there's no easy mis-use that would lead to reveal a secret (typically,
I'd do that with a whitelist and not a black-list, so that new
references are secret by default).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Douglas Campos @ 2009-09-25 13:25 UTC (permalink / raw)
To: Mark Struberg; +Cc: MatthiasSohn, git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <212350.78171.qm@web27802.mail.ukl.yahoo.com>
Forwarding to list, as I always forgot to add all recipients (my bad :( )
> and no: currently the very file you mentioned contains a lot more stuff. In fact most of this are only editor settings, preferred formattings etc which has nothing to do with the build per se. Eclipse has the ability to import/export all those settings in a XML file which is version independent. We should go this way and also supply similar setting-files for Idea and NetBeans. But forcing those settings via an internal Eclipse plugin config file is imho bad practice.
The problem lies here. JGit, AFAIK, has very _strict_ rules, this is
the corner case that makes sense to enforce via IDE. It spares time
from everyone here.
I like the maven-generated eclipse projects, but I think that we need
the same level of service provided by the eclipse settings.
IMHO, as always.
--
Douglas Campos (qmx)
+55 11 7626 5959
^ permalink raw reply
* Re: Avoid declaration after statement
From: Erik Faye-Lund @ 2009-09-25 13:34 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: msysGit, Marius Storm-Olsen, git, Johannes.Schindelin, gitster,
j6t, lznuaa, raa.lkml, snaury
In-Reply-To: <05f2bea5-0f74-4c89-9a84-d908a80bea20@h30g2000vbr.googlegroups.com>
On Wed, Sep 23, 2009 at 11:44 AM, Sebastian Schuberth
<sschuberth@gmail.com> wrote:
>
>> From: Frank Li <lznuaa@gmail.com>
>>
>> MSVC does not understand this C99 style
>>
>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
>
> Indeed, even in recent Visual Studio versions the C compiler only
> understands C90, not C99. Would it make sense to just force MSVC to
> compile *.c files with the C++ compiler to fix this, rather than
> patching files (which might be necessary for future files, too)?
I don't think so. There's many other compilers out there that doesn't
support C99 features, and most of the git source code does not depend
on them. IMO, it is better to fix these issues for all those
compilers once and for all, instead of having to find ways of working
around them whenever someone changes compiler.
Besides, C++ isn't a strict superset of C. There might be warnings or
errors introduced by compiling the code as C++. Implicit conversions
from void* springs to mind. Quick tests reveals that MSVC doesn't seem
to warn or error about them, but there might be some other differences
where we do get into issues.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Sitaram Chamarty @ 2009-09-25 13:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Shawn O. Pearce, Randal L. Schwartz, git
In-Reply-To: <vpqab0j1a2s.fsf@bauges.imag.fr>
On Fri, Sep 25, 2009 at 5:59 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> yes indeed -- if someone were to foolishly merge a "secret" branch
>> into a "normal" branch, so that it is now reachable from a "normal"
>> branch, that's his problem -- that cannot be within the scope of this
>> check.
>
> Merging is not the only scenario. Adding a tag could make secret
> things become visible too. I'm not saying the approach isn't viable,
> but if it gets implemented, it should be done with care to make sure
> there's no easy mis-use that would lead to reveal a secret (typically,
> I'd do that with a whitelist and not a black-list, so that new
> references are secret by default).
A whitelist may be better, but I'd be quite happy with a blacklist, if
that's easier to implement, and take on myself/my team the onus of
ensuring that code remains unreachable from any of the non-blacklisted
tags.
In other words, I don't expect this to be idiot-proof and I'll take
what I can get and work with it :-)
--
Sitaram
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-25 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Jeff King, git, Johannes Sixt
In-Reply-To: <7v1vlyrcef.fsf@alter.siamese.dyndns.org>
On Tue, Sep 22, 2009 at 9:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Erik Faye-Lund schrieb:
>>> On Mon, Sep 14, 2009 at 3:19 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>>> "The" warning? Not "the two" warnings? Then I suggest to stop here; MSVC
>>>> is only half-competent with regards to noreturn.
>>>
>>> There was only one warning in this regard on MSVC - the one about
>>> unreachable code. And yes, MSVC is only half-competent, but it seems
>>> it's competence is in the half that matters in our case.
>>>
>>> Do you suggest to stop the patch-series, or to stop the testing?
>>
>> My suggestion was about stopping the patch series.
>>
>> But thinking a bit more about it, I can imagine that there are calls to
>> die() that, if it is not marked noreturn, could trigger other warnings
>> with MSVC. That would be annoying, and it's better to mark it noreturn.
>>
>> So I withdraw my suggestion to stop :-)
>
> Anything happened to this series?
No, I'm sorry for not updating. I'm currently on vacation, and I
didn't get time to fix it up before going, due to my dayjob. I'll pick
it up again as soon as I get back home, in a bit more than a week.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 14:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250430x14b0d7f4w5e22467ddd66cc29@mail.gmail.com>
On Fri, Sep 25, 2009 at 12:30, Marco Costalba <mcostalba@gmail.com> wrote:
>
> So I am thinking to some setup somewhere that makes git to use
> abbreviated commits instead of full names. Does exist something like
> this ?
>
Here it is very strange. The problem is that git shell is no more case
sensitive.
I have tried git commit -F ...
and I got error:unkown switch 'f'
So somehow the problem is that all the commands are lowercased, and
this explains why pretty format %H is interpreted as %h so that sha
abbreviated form is used.
Now the question is: how to restore normal case sensitive command parsing ?
Thanks
Marco
P.S: Please, at least answer this last question ;-)
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Johannes Sixt @ 2009-09-25 14:12 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250704x724fd4c7lebe7184b4557c7a9@mail.gmail.com>
Marco Costalba schrieb:
> So somehow the problem is that all the commands are lowercased, and
> this explains why pretty format %H is interpreted as %h so that sha
> abbreviated form is used.
>
> Now the question is: how to restore normal case sensitive command parsing ?
>
> P.S: Please, at least answer this last question ;-)
I cannot.
Please try calling the commands from CMD. To do that in a regular msysgit
installation where you did not choose the option to set the PATH, it
should be sufficient to point your PATH to
<installdir>\git\bin;<installdir>\bin;%PATH% (although I'm not sure about
the exact paths - as I said, I don't install msysgit). Does that work?
-- Hannes
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 14:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4ABCCFE4.6070202@viscovery.net>
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.
^ 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
* 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
* [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
* [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
* 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 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: [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
* 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
* 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
* [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
* 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
* 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
* 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 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: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
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