* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-19 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Jakub Narebski
In-Reply-To: <7v645kyba8.fsf@assigned-by-dhcp.pobox.com>
On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Another possibility, though, is to say:
>
> core.some\0where\0core.over\0\0core.the\0core.rainbow\0
How do you denote empty values then?
[section]
key=
key
this are two very different statements atm (e.g. the one is false and
the other one is true).
I still think using two different delimiters is the simplest choice.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Junio C Hamano @ 2007-06-19 1:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0706190151160.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As for the FIXME: If you have a config like this:
>
> [core]
> Some = where
> over
> the = core.rainbow
>
> git-config -z would output something like this:
>
> core.some\0where\0core.over\0core.the\0core.rainbow\0
>
> Right?
>
> As you can see, it is quite hard for a parser to find out what is key, and
> what is value. That FIXME is _exactly_ about this dilemma.
>
> IIRC I stated once that -z should output a value of "true" for these
> cases, since they only make sense as booleans. But AFAIR nothing
> conclusive came out of that thread.
I do not remember the thread, but I think that may make sense.
"over = 1", "over = true" etc. cannot be canonicalized to "true"
without knowing core.over is boolean, but core.over by itself
without any assignment cannot be anything but a boolean.
Another possibility, though, is to say:
core.some\0where\0core.over\0\0core.the\0core.rainbow\0
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Sam Vilain @ 2007-06-19 1:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90706181810p716f914al4d9abba5bfe7eb5@mail.gmail.com>
Martin Langhoff wrote:
> And I kind of hate having to reply to things like these
>
> http://www.markshuttleworth.com/archives/125
I think that there should be clear conventions for how to place such
breadcrumbs in the commit log, that can be suitably ignored or honoured.
At least these two things fit into this category:
1. renaming. A comment on a changelog entry saying "I moved this file
from A to B in this commit". With all of the user friendliness and
limitations this implies (oh, you got the information wrong or
didn't put it in? oh well, now history is b0rked forever, HAND)
2. cherry picking. bzr uses patch UUIDs, with all of the user
friendliness and limitations this implies (oh, you merged that
patch and accidentally didn't pick any changes? whoops, it's
in your history anyway so never try to merge that again).
Perhaps also there should be other conventions for how to encode other
strange data out of the namespace of the filesystem ("in a different
dimension", perhaps) like "file attributes".
Sam.
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Johannes Schindelin @ 2007-06-19 1:32 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano, Jakub Narebski
In-Reply-To: <20070619011734.GD19725@planck.djpig.de>
Hi,
On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
> Instead we output something like
>
> core.some\nwhere\0core.over\0core.the\ncore.rainbow\0
Ah, I missed that. Maybe because I expected "--null" not to be
"--newline-and-null" ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-19 1:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0706190151160.4059@racer.site>
On Tue, Jun 19, 2007 at 01:55:24AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 18 Jun 2007, Frank Lichtenheld wrote:
>
> > Note the FIXME. Does anyone remember the reason why --get-regexp
> > and --list use different output format?
>
> AFAIK --list was meant as a replacement to git-var --list. Thus, it had to
> behave exactly the same.
>
> As for the FIXME: If you have a config like this:
>
> [core]
> Some = where
> over
> the = core.rainbow
>
> git-config -z would output something like this:
>
> core.some\0where\0core.over\0core.the\0core.rainbow\0
>
> Right?
No. At least not with my patch. As you noted that would be
incredibly stupid and worthless. Instead we output something like
core.some\nwhere\0core.over\0core.the\ncore.rainbow\0
So you just can split on \0 and then split on \n. If there is
no \n between two \0, you have a key without value.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Jakub Narebski @ 2007-06-19 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706190151160.4059@racer.site>
Johannes Schindelin wrote:
> As for the FIXME: [...]
Please read original message carefully:
>> Note the FIXME. Does anyone remember the reason why --get-regexp
>> and --list use different output format?
I think the FIXME is for --get-regexp. And was added by the patch.
> If you have a config like this:
>
> [core]
> Some = where
> over
> the = core.rainbow
>
> git-config -z would output something like this:
>
> core.some\0where\0core.over\0core.the\0core.rainbow\0
>
> Right?
False. Delim is different from term. You would get
core.some\nwhere\0core.over\0core.the\ncore.rainbow\0
> As you can see, it is quite hard for a parser to find out what is
> key, and what is value.
local $/ = "\0";
while (my $line = <$fd>) {
chomp $line;
my ($key, $value) = split(/\n/, $line, 2);
push @{$config{$key}}, $value if defined $key;
}
--
Jakub Narebski
Poland
^ permalink raw reply
* blame follows renames, but log doesn't
From: Martin Langhoff @ 2007-06-19 1:10 UTC (permalink / raw)
To: Git Mailing List
Hi all,
when I show git to newbies or demo it to people using other SCMs, and
we get to the rename part of the conversation, I discuss and show how
GIT's approach is significantly better than explicit recording of
renames.
One great example is git-blame -- actually more spectacular with the
recent git gui blame improvements. But git-log still doesn't do it.
If I say
git blame git-cvsimport.perl # goes to the true origin like a champ
git log git-cvsimport.perl # stops at the Big Tool Rename
In thread in May Linus posted a PoC patch to get git-blame to do it
http://marc.info/?l=git&m=117347893211567&w=2 , and outlined the
reasons why it'd be wrong to try to do that in git-log -- but it
didn't come to happen :-/
cg-log used to have some Perl logic that could do this -- it didn't
always work, but I'm sometimes tempted to go back to it, and review
it.
Linus said:
> But it's an example of the fact that yes, git can do this, but we're so
> stupid that we don't really accept it.
And I'm sure people can cope with git blame --log path/to/file and we
can add a note to git-log manpage about renames being reported by
blame instead.
And I kind of hate having to reply to things like these
http://www.markshuttleworth.com/archives/125
cheers
martin
^ permalink raw reply
* Re: [PATCH] make dist: include configure script in tarball
From: Johannes Schindelin @ 2007-06-19 1:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f578a4$6mm$1@sea.gmane.org>
Hi,
On Tue, 19 Jun 2007, Jakub Narebski wrote:
> Matthias Lederhofer wrote:
>
> > +dist: git.spec git-archive configure
>
> Ack. This way you don't need autoconf to ./configure install.
... but you force our good maintainer to have it installed...
Ciao,
Dscho
^ permalink raw reply
* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-19 1:00 UTC (permalink / raw)
To: David Kastrup; +Cc: git, Jakub Narebski
In-Reply-To: <86ir9l1ylc.fsf@lola.quinscape.zz>
Hi,
On Mon, 18 Jun 2007, David Kastrup wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > David Kastrup wrote:
> >
> >> what is the point in quoting file names and their characters in
> >> git-diff's output?
> >
> > 7-bit email.
>
> I think it can be reasonably safely assumed that people using 8-bit
> characters in file names will not refrain from using them in the files
> themselves: [...]
However, please realise that chances are very good that none of these
8-bit unclean things show in the diff.
Besides, the proper fix would probably involve making none-8-bit-clean
diffs binary diffs (for FORMAT_EMAIL only, of course).
> So I don't see what quoting such characters in file names is supposed to
> buy with regard to diff output in 7-bit email.
But isn't that obvious? Even if the diffs are not 7-bit clean, which I
consider as an error, quoting the file names is already half what is
required.
Don't just throw away backwards compatibility, only because it does not
fit your wishes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Johannes Schindelin @ 2007-06-19 0:55 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano, Jakub Narebski
In-Reply-To: <11821227322913-git-send-email-frank@lichtenheld.de>
Hi,
On Mon, 18 Jun 2007, Frank Lichtenheld wrote:
> Note the FIXME. Does anyone remember the reason why --get-regexp
> and --list use different output format?
AFAIK --list was meant as a replacement to git-var --list. Thus, it had to
behave exactly the same.
As for the FIXME: If you have a config like this:
[core]
Some = where
over
the = core.rainbow
git-config -z would output something like this:
core.some\0where\0core.over\0core.the\0core.rainbow\0
Right?
As you can see, it is quite hard for a parser to find out what is key, and
what is value. That FIXME is _exactly_ about this dilemma.
IIRC I stated once that -z should output a value of "true" for these
cases, since they only make sense as booleans. But AFAIR nothing
conclusive came out of that thread.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] make dist: include configure script in tarball
From: Jakub Narebski @ 2007-06-19 0:39 UTC (permalink / raw)
To: git
In-Reply-To: <20070618213036.GA7222@moooo.ath.cx>
Matthias Lederhofer wrote:
> +dist: git.spec git-archive configure
Ack. This way you don't need autoconf to ./configure install.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFH] pp_header(): work around possible memory corruption
From: Johannes Schindelin @ 2007-06-19 0:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps3w4g9x.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Fri, 15 Jun 2007, Junio C Hamano wrote:
> At least the older humongous pretty_print_commit() got separated into
> manageable chunks, and I was happy. I was just too lazy when
> refactoring the code and stopped there.
That's perfectly okay. This is why you parked it in 'next', I guess.
> The right fix is to propagate the "realloc as needed" callchain into
> add_user_info(), instead of having "this should be enough" there.
> These two you touched are the only two callsite of that static function.
Right. As I said, I was in a hurry, and could not research it properly.
Besides, now that you gave me the proper pointer, I can take care about it
tomorrow, unless somebody else is faster.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Johannes Schindelin @ 2007-06-19 0:16 UTC (permalink / raw)
To: Kevin Green; +Cc: Julian Phillips, git
In-Reply-To: <20070615154000.GK14677@menevado.ms.com>
Hi,
On Fri, 15 Jun 2007, Kevin Green wrote:
> I'm thinking I like the env var idea much more though. I can just
> export it in my shell and it works in both cases.
And it completely breaks down when you have more than one remotes. Or when
you cd to another project with another remote. Or etc. IOW it is fragile.
Clearly, the config approach is the only one which makes sense. This
information is so closely coupled to a specific remote that you should
store it right where you store all the other remote information, too.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Roland Dreier @ 2007-06-18 23:36 UTC (permalink / raw)
To: Christoph Lameter
Cc: Thomas Glanzmann, carlo, Linus Torvalds, LKML, Michael Gernoth,
GIT
In-Reply-To: <Pine.LNX.4.64.0706181617060.18601@schroedinger.engr.sgi.com>
> Is there some way you can feed that into Debian please? Why the go around
> through a separate repository? The maintainer of git-core is not actively
> maintaining the package?
No. The current version of git in Debian is 1.5.2.1, a little out of
date from the current 1.5.2.2 but not too bad. However, Debian Etch
was already released with an older version of git. Debian
testing/Lenny (the next release, which is still being developed) does
not have the latest version of git yet because it is blocked waiting
for the next version of curl as well as a few other problems.
- R.
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Christoph Lameter @ 2007-06-18 23:18 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: carlo, Linus Torvalds, LKML, Michael Gernoth, GIT
In-Reply-To: <20070618212524.GC16393@cip.informatik.uni-erlangen.de>
On Mon, 18 Jun 2007, Thomas Glanzmann wrote:
> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
>
> deb http://rmdir.de/~michael/git/ ./
>
> apt-get update; apt-get dist-upgrade
>
> and you're up2speed.
>
> If you don't trust that packages it is very easy to build them yourself:
Is there some way you can feed that into Debian please? Why the go around
through a separate repository? The maintainer of git-core is not actively
maintaining the package?
^ permalink raw reply
* Re: merging git-p4 into git/fastimport.git (second try)
From: Shawn O. Pearce @ 2007-06-18 23:00 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706190036.01950.simon@lst.de>
Simon Hausmann <simon@lst.de> wrote:
> after reworking most of the really short commit logs and adding the missing
> SOB lines I'd like to ask for consideration of merging git-p4 as part of
> contrib/fastimport/ from
>
> git://repo.or.cz/fast-export.git git-p4
Most of the commits look pretty good. The effort you have put into
cleaning them up shows.
However, many of the oneline descriptions from Han-Wen Nienhuys
are still really short and not very descriptive. They won't look
very good in Junio's "What's in git.git". A few of yours are
also pretty long winded for a typical oneline in git.git, but I'd
rather have a descriptive-but-long oneline anytime over a short
and undescriptive one.
So I'm seriously considering merging this at this point. I'm heading
out to dinner and will look at it more again when I get back, but
I think we should just bite the bullet and bring it into core Git.
--
Shawn.
^ permalink raw reply
* merging git-p4 into git/fastimport.git (second try)
From: Simon Hausmann @ 2007-06-18 22:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
Hi,
after reworking most of the really short commit logs and adding the missing
SOB lines I'd like to ask for consideration of merging git-p4 as part of
contrib/fastimport/ from
git://repo.or.cz/fast-export.git git-p4
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 22:08 UTC (permalink / raw)
To: Carlo Wood, LKML, GIT
In-Reply-To: <20070618220441.GC13538@alinoe.com>
Hello,
> after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
> just fine immediately.
good point, that makes sense. I have to keep that in mind. Last time I
looked at the failed tests, saw the missing dependency and tried again.
:-)
Thomas
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Carlo Wood @ 2007-06-18 22:04 UTC (permalink / raw)
To: Thomas Glanzmann, LKML, GIT
In-Reply-To: <20070618215610.GG16393@cip.informatik.uni-erlangen.de>
On Mon, Jun 18, 2007 at 11:56:10PM +0200, Thomas Glanzmann wrote:
> true. But when you run sid you get a newer version of git automatically.
> Sooner or later. And you can always build it yourself. It's a pain in
> the ass until you have all build dependencies installed and all the
> tests pass.
Oh, I already build it before my previous post :p
I just did:
sudo apt-get install libz-dev asciidoc xmlto libexpat1-dev subversion unzip tcl8.4 libsvn-perl libcurl3-dev
after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
just fine immediately.
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 22:03 UTC (permalink / raw)
To: Carlo Wood, LKML, GIT
In-Reply-To: <20070618215610.GG16393@cip.informatik.uni-erlangen.de>
Hello,
* Thomas Glanzmann <thomas@glanzmann.de> [070618 23:56]:
> > It seems that this is only for etch (and sarge). I run a mixed
> > Lenny/sid machine here. It doesn't necessarily work when I start to
> > install things for etch. Certainly not once testing upgrades its libc.
> > Or?
> true.
I guess not so true. Because debian had always compatibility libs. So I
guess when they bump the libc revision on sid, they provide a compat
library at the same time so that you're able to run the old binaries.
But don't nail me down on this one. But for the mean time you should be
good with the packages I provided in the previous e-mail for sure.
Thomas
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 21:56 UTC (permalink / raw)
To: Carlo Wood, LKML, GIT
In-Reply-To: <20070618214852.GA13538@alinoe.com>
Hello,
> It seems that this is only for etch (and sarge). I run a mixed
> Lenny/sid machine here. It doesn't necessarily work when I start to
> install things for etch. Certainly not once testing upgrades its libc.
> Or?
true. But when you run sid you get a newer version of git automatically.
Sooner or later. And you can always build it yourself. It's a pain in
the ass until you have all build dependencies installed and all the
tests pass. Most of them you can get by typing:
apt-get build-dep git-core
But after that it is very straight forward.
Thomas
^ permalink raw reply
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Brandon Casey @ 2007-06-18 21:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <20070618213749.GB16397@steel.home>
Alex Riesen wrote:
> Brandon Casey, Mon, Jun 18, 2007 23:28:10 +0200:
>> Alex Riesen wrote:
>>> The function converts the value of h_errno (last error of name
>>> resolver library, see netdb.h). One of systems which supposedly do
>>> not have the function is SunOS. POSIX does not mandate its presence.
>> I saw a comment on another mailing list that hstrerror() is in the
>> resolv library.
>>
>> So adding -lresolv should do it.
>>
>> A quick compile works for my test program.
>>
>
> Ah-ha. Good to know, thanks!
>
> Still, the patch is correct: no need for hstrerror there.
I see, right, just the NO_IPV6 case.
-brandon
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Carlo Wood @ 2007-06-18 21:48 UTC (permalink / raw)
To: Thomas Glanzmann, LKML, Michael Gernoth, GIT
In-Reply-To: <20070618212741.GA5938@artemis.internal.dc7.debconf.org>
On Mon, Jun 18, 2007 at 10:27:41PM +0100, Pierre Habouzit wrote:
> FWIW there is even simpler: I maintain a backport on
> www.backports.org. Which is a semi-official service driven by Debian
> Developers.
It seems that this is only for etch (and sarge).
I run a mixed Lenny/sid machine here. It doesn't necessarily
work when I start to install things for etch. Certainly not
once testing upgrades its libc. Or?
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Alex Riesen @ 2007-06-18 21:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <4676F8EA.1030305@nrlssc.navy.mil>
Brandon Casey, Mon, Jun 18, 2007 23:28:10 +0200:
> Alex Riesen wrote:
> >The function converts the value of h_errno (last error of name
> >resolver library, see netdb.h). One of systems which supposedly do
> >not have the function is SunOS. POSIX does not mandate its presence.
>
> I saw a comment on another mailing list that hstrerror() is in the
> resolv library.
>
> So adding -lresolv should do it.
>
> A quick compile works for my test program.
>
Ah-ha. Good to know, thanks!
Still, the patch is correct: no need for hstrerror there.
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 21:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: GIT, LKML
In-Reply-To: <20070618212741.GA5938@artemis.internal.dc7.debconf.org>
Hello Pierre,
> FWIW there is even simpler: I maintain a backport on
> www.backports.org. Which is a semi-official service driven by Debian
> Developers.
good to know, maybe I am going to use backports in the future.
Thomas
^ 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