* [PATCH] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-09-24 18:02 UTC (permalink / raw)
To: gitster; +Cc: git, c, Brandon Casey
In-Reply-To: <7vk4zrt035.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Possibly it is related to the version of MakeMaker? I am using version
>> 6.17 (Revision: 1.133) along with Perl 5.8.4 on Solaris 10 x86. The
>> MakeMaker version should be in the header at the top of the perl.mak
>> file.
>
> I think that is it. DESTDIR support in MakeMaker seems to be lacking in
> medieval versions of Perl. It appears that it started being usable at
> around its 6.11 (and 6.17 you have is fine).
>
> http://kobesearch.cpan.org/htdocs/ExtUtils-MakeMaker/Changes.html
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6131#c7
How about something like this?
Seems to work correctly for me on IRIX 6.5 and Solaris 7 with
ExtUtils::MakeMaker 6.03.
-brandon
perl/Makefile.PL | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 320253e..8974015 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,14 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITELIB)'
+ifneq (,$(DESTDIR))
+ifeq (1,$(shell expr '$(MM_VERSION)' '<' 6.11))
+$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
+ is likely incompatible with the DESTDIR mechanism. Try setting \
+ NO_PERL_MAKEMAKER=1 instead)
+endif
+endif
+
MAKE_FRAG
}
--
1.6.4.3
^ permalink raw reply related
* [PATCH v2] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-09-24 18:21 UTC (permalink / raw)
To: gitster; +Cc: git, c, Brandon Casey
In-Reply-To: <7wQSYSBJPoVtvyGI0lqsDW37w4byCpgpMaHiDKALwW_oJ9nHXddX9OBMnqXGZBVAo2U7Tc1BMxg@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This just reverses the logic in the test on $(MM_VERSION) so that the test
will also fail if MM_VERSION is unset. Who knows if ancient versions set
it. Sorry for the quick v2.
-brandon
perl/Makefile.PL | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 320253e..0b9deca 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,14 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITELIB)'
+ifneq (,$(DESTDIR))
+ifeq (0,$(shell expr '$(MM_VERSION)' '>' 6.10))
+$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
+ is likely incompatible with the DESTDIR mechanism. Try setting \
+ NO_PERL_MAKEMAKER=1 instead)
+endif
+endif
+
MAKE_FRAG
}
--
1.6.4.3
^ permalink raw reply related
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Matthieu Moy @ 2009-09-24 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Li Hong, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.01.0909241021120.3303@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 'git cat-file' is really really low-level plumbing. Humans should
> generally never use it.
... except to understand Git better ;-). I enjoyed being able to to a
'git cat-file' on a tree or commit object when I started with Git.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Matthieu Moy @ 2009-09-24 19:26 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Howard Miller, git
In-Reply-To: <20090924172610.GA31309@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
>> 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 user@host at the end of the public key is mostly a comment. No
serious software would use it for authentication, since you can freely
edit it without changing the rest of the key.
> 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).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Nicolas Pitre @ 2009-09-24 19:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, Li Hong, Junio C Hamano, git
In-Reply-To: <vpqy6o4kv24.fsf@bauges.imag.fr>
On Thu, 24 Sep 2009, Matthieu Moy wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > 'git cat-file' is really really low-level plumbing. Humans should
> > generally never use it.
>
> ... except to understand Git better ;-). I enjoyed being able to to a
> 'git cat-file' on a tree or commit object when I started with Git.
In the context of learning git at that level, the current option
interface for cat-file shouldn't look too strange though.
Nicolas
^ permalink raw reply
* Re: [msysGit] Re: Add MinGW header files to build git with MSVC
From: Frank Li @ 2009-09-25 0:18 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Sebastian Schuberth, msysGit, git, Johannes.Schindelin, gitster,
j6t, raa.lkml, snaury
In-Reply-To: <4ABA0698.7020604@gmail.com>
>
> This was a patch which originated from Frank Li's original series. While we
> might have been able to simply use the MSVC one, I'm sure Frank had a reason
> for overriding it with the small content which you see in this patch. We'll
> have to ask Frank about that. We can always remove it now, if the MSVC
> version works ok and doesn't introduce any compiler errors/warnings.
>
At beginning, I don't want to copy all msys header files to
vcbuilc\include and copy only necessary header file and data
structure.
Many structures have been defined at MSVC standard file. So I use
simple utimer.h and unistd.h and dirent.h.
Best regards
Frank Li
^ permalink raw reply
* git merge conflict resolution?
From: Joe Perches @ 2009-09-25 1:18 UTC (permalink / raw)
To: Linux Kernel Mailing List, git; +Cc: Linus Torvalds, Russell King
In-Reply-To: <200909250101.n8P11HwO030173@hera.kernel.org>
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.
Patch 1: ====================
On Fri, 2009-09-25 at 01:01 +0000, Linux Kernel Mailing List wrote:
> Gitweb: http://git.kernel.org/linus/784546839fd45de485b9e9e4cd072b9d53100aa5
> Commit: 784546839fd45de485b9e9e4cd072b9d53100aa5
> Parent: 07198871dac00e9c250d647e1976d7aee527b805
> ARM: Update mailing list addresses
> The old list has now been closed off; update the now invalid addresses.
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> MAINTAINERS | 106 +++++++++++++++++++++++++++++-----------------------------
> 1 files changed, 53 insertions(+), 53 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 837b598..12be157 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -497,7 +497,7 @@ F: arch/arm/include/asm/floppy.h
>
> ARM PORT
> M: Russell King <linux@arm.linux.org.uk>
> -L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
> +L: linux-arm-kernel@lists.infradead.org
> W: http://www.arm.linux.org.uk/
> S: Maintained
> F: arch/arm/
====================
vs the patch that was applied a bit earlier:
Patch 2: ====================
commit efc03ecb9d674588a13aee27289c2af2afe5e6b4
Author: Joe Perches <joe@perches.com>
Date: Mon Sep 21 17:04:27 2009 -0700
MAINTAINERS: move ARM lists to infradead
====================
Patch 2 was applied before patch 1.
Russell's patch removes the "(moderated for non-subscribers)"
from each entry, yet the final result includes it.
Can someone help me understand why?
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Li Hong @ 2009-09-25 2:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.01.0909241021120.3303@localhost.localdomain>
2009/9/25 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Thu, 24 Sep 2009, Li Hong wrote:
>>
>> When using 'git cat-file' recently, I find its option interface is somewhat
>> inconvenient or mistakenly-designed.
>
> You likely shouldn't use 'cat-file' at all. Have you looked at 'git show'?
> That's the command meant for human beings.
>
> 'git cat-file' is really really low-level plumbing. Humans should
> generally never use it. It's one of the original git commands (it was
> literally in the original git commit), and it does some really low-level
> stuff that is good for scripting but not for any normal use.
>
> Linus
>
Yes, I know 'git show' and use it mostly. I just think the interface
of 'cat-file'
is not well designed even used by other scripts or porcelains. But from another
respect, it doesn't really annoy normal users much and we should retain
backwards compatibility. So I give up.
Thanks for all your feedbacks.
-Li Hong
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-25 6:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Heiko Voigt, git
In-Reply-To: <vpqskeckuto.fsf@bauges.imag.fr>
Hi,
I don't really understand the answers I have been given. Trying
desperately not to "top post" see bellow...
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:
>>> 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 user@host at the end of the public key is mostly a comment. No
> serious software would use it for authentication, since you can freely
> edit it without changing the rest of the key.
>
>> 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? When I create a key it doesn't ask me for the username I want
so I see a disconnect here. Do I put a name, do I put name@hostname,
does it matter and (again) how does it know which is 'my' public key?
Is it the naming convention of the key or something magic? Plus, when
I actually use gitosis, I am logging as the user 'git' so how does it
know who I am? I am thoroughly confused by the whole thing. I'm
probably missing something really obvious but, AFAIK, this is not
covered at all in the docs.
Thanks!
Howard
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-25 6:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Heiko Voigt, git
In-Reply-To: <26ae428a0909242310r259ccf5eya7c95b8f43fc5c23@mail.gmail.com>
2009/9/25 Howard Miller <howard@e-learndesign.co.uk>:
> Hi,
>
> I don't really understand the answers I have been given. Trying
> desperately not to "top post" see bellow...
>
> 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:
>>>> 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 user@host at the end of the public key is mostly a comment. No
>> serious software would use it for authentication, since you can freely
>> edit it without changing the rest of the key.
>>
>>> 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? When I create a key it doesn't ask me for the username I want
> so I see a disconnect here. Do I put a name, do I put name@hostname,
> does it matter and (again) how does it know which is 'my' public key?
> Is it the naming convention of the key or something magic? Plus, when
> I actually use gitosis, I am logging as the user 'git' so how does it
> know who I am? I am thoroughly confused by the whole thing. I'm
> probably missing something really obvious but, AFAIK, this is not
> covered at all in the docs.
>
> Thanks!
>
> Howard
>
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!
^ permalink raw reply
* 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
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