* Alles wird Git, Berlin, Oct 3rd, 2009
From: Johannes Schindelin @ 2009-09-25 6:19 UTC (permalink / raw)
To: git
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.
Details: it will take place on October 3rd, 2009, at the Zuse-Institut
Berlin: http://www.zib.de/besucher/index.en.html (graciously offered by
Steffen Prohaska).
We will have a room with fast internet connection and a beamer.
As for the schedule: I had something like this in mind:
10:00 Saying hello to everybody
10:30 Dscho says something about the history of msysGit
11:00 Somebody else talks about something else
11:30 ...
...
After the talks, maybe a little hackathon-style coding (I know what I
would like to implement, but let's just see what happens).
In the evening, we probably order pizza or go to a restaurant nearby.
See also http://git.or.cz/gitwiki/GitTogether
Ciao,
Dscho
^ permalink raw reply
* Re: Re: How does gitosis know who the key belongs to
From: Heiko Voigt @ 2009-09-25 6:33 UTC (permalink / raw)
To: Howard Miller; +Cc: Matthieu Moy, git
In-Reply-To: <26ae428a0909242310r259ccf5eya7c95b8f43fc5c23@mail.gmail.com>
On Fri, Sep 25, 2009 at 07:10:07AM +0100, Howard Miller wrote:
> 2009/9/24 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> > Heiko Voigt <hvoigt@hvoigt.net> writes:
> >
> >> On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
> >> Not much different. It uses the command feature of the authorized_keys
> >> file of ssh to limit access to the 'gitosis-serve' command which is
> >> given the username from the gitosis.conf as argument.
> >
> > ... the username -> key association being done in gitosis's
> > configuration itself (the key held in keydir/foobar is the one of user
> > foobar).
>
>
> Yes, I realise that the association is done im gitosis' config file,
> but that is exactly my question - how does that association work?
>
> To take a step back - I have to put a name (or a name@hostname) in the
> configuration file. How do I know what that should be in the general
> sense?
Anything you like. The username is deducted from the filename in the
keydir file as Matthieu alredy pointed out. e.g:
keydir/hvoigt.pub <--- file contains my public key
gitosis.conf contents:
[group hvoigt-projects]
members = hvoigt
writable = myproject
That would give access to git@yourserver:myproject.git to the key in
hvoigt.pub. Technically its done using a update hook on the server which
is run when you push the configuration repository. It scans the config
and installs the keys in the authorized_keys file of the git user. The
above would look something like this in the git's users home dir:
.ssh/auhtorized_keys:
command="gitosis-serve hvoigt",no-port-forwarding,no-X11-forwarding,\
no-agent-forwarding,no-pty ssh-dss AAAA... hvoigt@localhost
Because ssh can match the key you are using to one of such lines the
gitosis-serve command is given the according username.
Does this make it a little bit clearer ?
cheers Heiko
^ permalink raw reply
* is smarter bisect possible?
From: Arkadiusz Miśkiewicz @ 2009-09-25 9:37 UTC (permalink / raw)
To: git
Hi,
I have such problem. Linus kernel tree merged some feature
(94e0fb086fc5663c38bbc0fe86d698be8314f82f) that was developed in .31rc9 era.
Current Linus kernel tree with that feature merged shows some regression.
Tree just before that merge doesn't show regression.
Now if I start to bisect just that feature (good
b7f21bb2e23b4fec16b448a34889f467465be659, bad
94e0fb086fc5663c38bbc0fe86d698be8314f82f) then git gets me whole tree back
to .31rc9 era which... doesn't show any problems.
This means that only combined current Linus tree and that feature shows a
problem.
Is it possible to make git bisect test current tree + parts of that merge
instead going back to .31rc9 era with the whole tree?
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: is smarter bisect possible?
From: Johannes Sixt @ 2009-09-25 7:59 UTC (permalink / raw)
To: Arkadiusz Miśkiewicz; +Cc: git
In-Reply-To: <h9hrv3$cao$1@ger.gmane.org>
Arkadiusz Miśkiewicz schrieb:
> I have such problem. Linus kernel tree merged some feature
> (94e0fb086fc5663c38bbc0fe86d698be8314f82f) that was developed in .31rc9 era.
>
> Current Linus kernel tree with that feature merged shows some regression.
> Tree just before that merge doesn't show regression.
>
> Now if I start to bisect just that feature (good
> b7f21bb2e23b4fec16b448a34889f467465be659, bad
> 94e0fb086fc5663c38bbc0fe86d698be8314f82f) then git gets me whole tree back
> to .31rc9 era which... doesn't show any problems.
>
> This means that only combined current Linus tree and that feature shows a
> problem.
Try this:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] print_wrapped_text(): allow hard newlines
From: Johannes Schindelin @ 2009-09-25 8:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Johannes Gilger, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0909231659010.3303@localhost.localdomain>
Hi,
On Wed, 23 Sep 2009, Linus Torvalds wrote:
> On Wed, 23 Sep 2009, Johannes Schindelin wrote:
> >
> > print_wrapped_text() will insert its own newlines. Up until now, if
> > the text passed to it contained newlines, they would not be handled
> > properly (the wrapping got confused after that).
> >
> > The strategy is to replace a single new-line with a space, but keep
> > double new-lines so that already-wrapped text with empty lines between
> > paragraphs will be handled properly.
>
> May I suggest doing this _only_ if the newline is followed by an
> alphanumeric characer?
>
> If the thing is indented ("newline + space") or quoted ("newline + ">"
> or whatever) then reflowing it is likely wrong and will result in an
> unholy mess.
After further consideration, I decided to heed your advice; it is an
obvious improvement when comparing the output with and without the
isalnum().
So I updated my log-rewrap branch:
http://repo.or.cz/w/git/dscho.git?a=shortlog;h=refs/heads/log-rewrap
Thanks,
Dscho
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Matthieu Moy @ 2009-09-25 8:20 UTC (permalink / raw)
To: Howard Miller; +Cc: Heiko Voigt, git
In-Reply-To: <26ae428a0909242315x3cf1aafcue004a73f5c471450@mail.gmail.com>
Howard Miller <howard@e-learndesign.co.uk> writes:
> Ahh... just read Heiko's post properly and actually looked at the
> authorized_keys file. This is now starting to make some sense. So the
> name in config has to match that sent to gitosis-server presumably. I
> still don't quite see the cause and effect. If I don't like being
> howard@x.y.z and would rather be just 'howard' what can I change? It
> tells me not to edit that file!
If you're confused with "name", then just think about "filename
holding the key".
If you want to name yourself "howard", then put your key in
keydir/howard and then use "howard" in the config file. gitosis will
add the relevant
command="gitosis-server howard" ssh-whatever <your-key-here> <irrelevant-comment>
to the ~git/.ssh/auhtorized_keys file.
You chose your "name" by chosing the filename, then you use this name
in the config file, and then gitosis does the job.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-25 8:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Heiko Voigt, git
In-Reply-To: <vpqhburigfs.fsf@olympe.imag.fr>
>
> If you're confused with "name", then just think about "filename
> holding the key".
>
> If you want to name yourself "howard", then put your key in
> keydir/howard and then use "howard" in the config file. gitosis will
> add the relevant
>
> command="gitosis-server howard" ssh-whatever <your-key-here> <irrelevant-comment>
>
> to the ~git/.ssh/auhtorized_keys file.
>
> You chose your "name" by chosing the filename, then you use this name
> in the config file, and then gitosis does the job.
Ok... so is it completely ignoring the @host bit then? None of my
public key files are called howard@host1.pub (for example).
Just so you don't think I'm completely crazy, I actually use three
different machines for development and (of course) I'm 'howard' on all
of them. I was trying to get my head around the best way to set it up.
I wasn't clear if I could simply recycle the same public key or if I
needed to be three different users in gitosis.
Cheers.... Howard
^ permalink raw reply
* git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 9:40 UTC (permalink / raw)
To: Git Mailing List
Perhaps is a dumb question, but for me is very new.
I have download and installed msysgit:
git version 1.6.4.msysgit.0
and now
git log --pretty=format:%h
prints a list of abbreviated (7 chars) SHA instead of the full 40
chars as I want.
I didn't change anything in git config and I am not able to restore
the original (correct) behaviour.
Could someone please help me on this ?
Thanks
Marco
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 9:46 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <e5bfff550909250240q3351d39evbcf507af422fde43@mail.gmail.com>
On Fri, Sep 25, 2009 at 10:40, Marco Costalba <mcostalba@gmail.com> wrote:
>
> and now
>
> git log --pretty=format:%h
>
Sorry, the correct command is:
git log --pretty=format:%H
but output is still abbreviated.
^ permalink raw reply
* Re: git merge conflict resolution?
From: Björn Steinbrink @ 2009-09-25 9:58 UTC (permalink / raw)
To: Joe Perches; +Cc: Linux Kernel Mailing List, git, Linus Torvalds, Russell King
In-Reply-To: <1253841510.18126.10.camel@Joe-Laptop.home>
On 2009.09.24 18:18:30 -0700, Joe Perches wrote:
> Question about how git does merge conflict resolution.
>
> This patch doesn't really apply, and the results after the
> patch aren't what at least I expect.
[...]
> Russell's patch removes the "(moderated for non-subscribers)"
> from each entry, yet the final result includes it.
>
> Can someone help me understand why?
If you look at baea7b946f00a291b166ccae7fcfed6c01530cc6, you see:
Merge branch 'origin' into for-linus
Conflicts:
MAINTAINERS
Git was unable to automatically merge that file, as there were
conflicting changes. That merge was done by Russel King, and _he_
decided that the result should include the "(moderated for ...)" part.
Björn
^ permalink raw reply
* 'git branch --no-merge' is ambiguous
From: Johannes Sixt @ 2009-09-25 10:28 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git Mailing List
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.
-- Hannes
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Johannes Sixt @ 2009-09-25 10:33 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250246qed6f2ci4237bdaefd8a18a@mail.gmail.com>
Marco Costalba schrieb:
> On Fri, Sep 25, 2009 at 10:40, Marco Costalba <mcostalba@gmail.com> wrote:
>> and now
>>
>> git log --pretty=format:%h
>>
>
> Sorry, the correct command is:
>
> git log --pretty=format:%H
>
> but output is still abbreviated.
Doesn't happen here. %h produces abbreviated SHA1s and %H full SHA1s.
However, I don't run msysgit, but compile git myself. I run the commands
from CMD.
-- Hannes
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 10:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4ABC9C5D.5030202@viscovery.net>
On Fri, Sep 25, 2009 at 11:33, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Marco Costalba schrieb:
>> On Fri, Sep 25, 2009 at 10:40, Marco Costalba <mcostalba@gmail.com> wrote:
>>> and now
>>>
>>> git log --pretty=format:%h
>>>
>>
>> Sorry, the correct command is:
>>
>> git log --pretty=format:%H
>>
>> but output is still abbreviated.
>
> Doesn't happen here. %h produces abbreviated SHA1s and %H full SHA1s.
> However, I don't run msysgit, but compile git myself. I run the commands
> from CMD.
>
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.
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: Marco Costalba @ 2009-09-25 11:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <e5bfff550909250344y535a05edx7d30ad7e48a5f036@mail.gmail.com>
On Fri, Sep 25, 2009 at 11:44, Marco Costalba <mcostalba@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 11:33, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Marco Costalba schrieb:
>>> On Fri, Sep 25, 2009 at 10:40, Marco Costalba <mcostalba@gmail.com> wrote:
>>>> and now
>>>>
>>>> git log --pretty=format:%h
>>>>
>>>
>>> Sorry, the correct command is:
>>>
>>> git log --pretty=format:%H
>>>
>>> but output is still abbreviated.
>>
>> Doesn't happen here. %h produces abbreviated SHA1s and %H full SHA1s.
>> However, I don't run msysgit, but compile git myself. I run the commands
>> from CMD.
>>
>
> 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.
So I am thinking to some setup somewhere that makes git to use
abbreviated commits instead of full names. Does exist something like
this ?
Thanks
^ permalink raw reply
* 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
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