* Re: [PATCH] http-push: refactor lock-related headers creation for curl requests
From: Johannes Schindelin @ 2009-01-24 4:11 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901231800t6943b01dwbca976d5e9f3397@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Ray Chuan wrote:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make that an Acked-by:
> + if(options & DAV_HEADER_IF) {
> + strbuf_addf(&buf, "If: (<%s>)", lock->token);
> + dav_headers = curl_slist_append(dav_headers, buf.buf);
> + strbuf_reset(&buf);
BTW in case anyone is puzzled (like I was): curl_slist_append() takes a
"char *" as second parameter, but does not take custody of the buffer;
instead, it strdup()s it. See
http://cool.haxx.se/cvs.cgi/curl/lib/sendf.c?rev=1.155&content-type=text/vnd.viewcvs-markup
for details.
BTNW this should be mentioned in the commit message, too, to spare other
people the puzzlement.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Change octal literals to be XEmacs friendly
From: Junio C Hamano @ 2009-01-24 5:16 UTC (permalink / raw)
To: malc; +Cc: git
In-Reply-To: <878wp1mphq.fsf@linmac.oyster.ru>
malc@pulsesoft.com writes:
> Kalle Olavi Niemitalo <kon@iki.fi> writes:
>
>> Vassili Karpov <av1474@comtv.ru> writes:
>>
>>> #ooctal syntax on the other hand produces integers everywhere.
>>
>> GNU Emacs 20.7 doesn't support #o, but neither does it include
>
> Bummer
To be portable you could certainly spell them in decimal integers, no?
^ permalink raw reply
* Re: [PATCH] http-push: refactor lock-related headers creation for curl requests
From: Junio C Hamano @ 2009-01-24 5:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ray Chuan, git
In-Reply-To: <alpine.DEB.1.00.0901240507070.13232@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 24 Jan 2009, Ray Chuan wrote:
>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Make that an Acked-by:
>
>> + if(options & DAV_HEADER_IF) {
>> + strbuf_addf(&buf, "If: (<%s>)", lock->token);
>> + dav_headers = curl_slist_append(dav_headers, buf.buf);
>> + strbuf_reset(&buf);
>
> BTW in case anyone is puzzled (like I was): curl_slist_append() takes a
> "char *" as second parameter, but does not take custody of the buffer;
> instead, it strdup()s it. See
> http://cool.haxx.se/cvs.cgi/curl/lib/sendf.c?rev=1.155&content-type=text/vnd.viewcvs-markup
> for details.
>
> BTNW this should be mentioned in the commit message, too, to spare other
> people the puzzlement.
Yeah, but your advice is too late --- I already lost a few minutes solving
my puzzlement with manpages.
Thanks, both.
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Markus Heidelberg @ 2009-01-24 5:22 UTC (permalink / raw)
To: Tim Henigan; +Cc: git, gitster
In-Reply-To: <1232665622-5110-1-git-send-email-tim.henigan@gmail.com>
Tim Henigan, 23.01.2009:
> Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
> ---
> mode change 100644 => 100755 builtin-gc.c
> mode change 100644 => 100755 builtin-reflog.c
> mode change 100644 => 100755 builtin-show-branch.c
> mode change 100644 => 100755 cache.h
> mode change 100644 => 100755 date.c
> mode change 100644 => 100755 parse-options.c
> mode change 100644 => 100755 reflog-walk.c
> mode change 100644 => 100755 refs.c
> mode change 100644 => 100755 refs.h
> mode change 100644 => 100755 revision.c
> mode change 100644 => 100755 revision.h
> mode change 100644 => 100755 sha1_name.c
Oops
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Johannes Schindelin @ 2009-01-24 6:27 UTC (permalink / raw)
To: Tim Henigan; +Cc: git, gitster
In-Reply-To: <1232665622-5110-1-git-send-email-tim.henigan@gmail.com>
Hi,
On Thu, 22 Jan 2009, Tim Henigan wrote:
> Use time_t for timestamps returned by approxidate() instead of unsigned
> long. All references to approxidate were checked as well as references
> to OPT_DATE.
Hmm. I vaguely remember Linus mentioning recently that unsigned long is
the appropriate data type for the Unix Epoch...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (GIT-GUI BUG)] git-gui: Fix post-commit status with subject in non-locale encoding.
From: Robin Rosenberg @ 2009-01-24 6:37 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce
In-Reply-To: <200901240018.13457.angavrilov@gmail.com>
fredag 23 januari 2009 22:18:13 skrev Alexander Gavrilov:
> As pointed out in msysgit bug #181, when a non-locale encoding
> is used for commits, post-commit status messages display the
> subject incorrectly. It happens because the file handle is
> not properly configured before the subject is read back.
>
> This patch fixes it by factoring out the code that is
> used to setup the output handle into a separate function,
> and calling it from the reading code.
Ack. Works fine now.
Thanks.
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-24 8:21 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <83wscndv57.fsf@kalahari.s2.org>
On Thu, Jan 22, 2009 at 8:59 PM, Hannu Koivisto <azure@iki.fi> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> This brings back my previous question: where is the home directory in
>>>> a Windows system?
>>>
>>> It's where %HOMEDRIVE%%HOMEPATH% points to.
>>
>> I thought it was something like that. Do we want something like that
>> in the manual, or should we assume Windows users know that?
>
> I should have added that Unix programs (i.e. Cygwin programs and
> even some native ports) probably use %HOME% which may be different
> from %HOMEDRIVE%%HOMEPATH%. I recall that if you haven't
> explicitly set up HOME in Windows environment, Cygwin sets it up
> magically from passwd or falls back to %HOMEDRIVE%%HOMEPATH%. I
> have no idea if msysgit respects %HOME% if it is set or always uses
> %HOMEDRIVE%%HOMEPATH% or something completely different (user
> profile, most likely).
>
> It certainly may be that "home directory" is a foreign concept to
> some Windows users. Some might know it as a user profile or a
> personal folder (just guessing, I'm pretty isolated from less
> experienced Windows users), even though user profile is a separate
> concept from "home directory" (note that there is %USERPROFILE%
> which by default is the same as %HOMEDRIVE%%HOMEPATH% at least in
> XP).
>
> In any case, what Cygwin git does should be expected by Cygwin
> users. If msysgit wanted to be a really native Windows application
> and store the configuration where Microsoft thinks it should be
> stored, it probably shouldn't store the config under "home
> directory" to begin with (I'm guessing that's what it does) but
> under %USERPROFILE\Application Data\Git (...FILE\Local
> Settings\... in case non-roaming storage is wanted). And in that
> case the manual might be misleading for msysgit users. See
> e.g. <http://msdn.microsoft.com/en-us/library/ms995853.aspx>.
Isn't that enough argument to stop assuming the user knows where is
the "home directory"?
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-24 8:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901232054360.21467@intel-tinevez-2-302>
On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> On Fri, 23 Jan 2009, Lars Hjemli wrote:
>>
>> That's too bad, I hoped on some feedback from you on the part of the
>> commit message which you didn't quote:
>
> Well, you ignored my comments,
I might have misunderstood your comments, but I certainly didn't
ignore them. I actually tried to come up with a solution that would
solve your concerns about which submodules to include in the archive
(which is why I hoped for some feedback on that proposal).
> so what do you expect me to do? Be happy?
>
> There are two issues there:
>
> - presence of a specific commit object being present in the repository
> does not necessarily mean that it is reachable by any ref, and therefore
> can mean that the tree/blob objects are not reachable, because it could
> be an interrupted fetch;
This part I agree with.
> in all of Git, we try to assume that only
> reachable objects are valid objects.
I don't think this is true (most git commands accepts their arguments
as valid objects without verifying if they are reachable from a ref).
Do you feel it is necessary to perform a reachability check of the
gitlink'd commit before traversing into a submodule tree?
> - presence of a specific commit in the supermodule is a _lousy_ indicator
> that the user wants to include that submodule in the archive.
This is the issue I tried to address with my
`--submodules=[a|c|r][g:<name>]` proposal in the commit message for
this patch. I hoped you would find it interesting, given your comments
in http://thread.gmane.org/gmane.comp.version-control.git/106167/focus=106235
(i.e. my 'a' flag would match your 'look-in-superprojects-odb', while
the 'c', 'r' and 'g' options would address your issues about how to
select the correct set of submodules).
--
larsh
^ permalink raw reply
* read-only working copies using links
From: Chad Dombrova @ 2009-01-24 9:17 UTC (permalink / raw)
To: git
hi all,
there's a major feature for working with large binaries that has not
yet been addressed by git: the ability to check out a file as a
symbolic/hard link to a blob in the repository, instead of duplicating
the file into the working copy.
imagine a scenario where one user is putting large binary files into a
git repo on a networked server. 100 other users on the server need
read-only access to this repo. they clone the repo using --shared or
--local, which saves disk space for the object files, but each of
these 100 working copies also creates copies of all the binary files
at the HEAD revision. it would be 100x as efficient in both disk space
and checkout speeds if, in place of these files, symbolic or hard
links were made to the blob files in .git/objects.
the crux of the issue is that the blob objects would have to be stored
as exact copies of the original files. it would seem there are two
things that currently prevent this from happening. 1) blobs are
stored with compression and 2) they include a small header.
compression can be disabled by setting core.loosecompression to 0, so
that seems like less of an issue. as for the header, wouldn't it be
possible to store it separately? in other words, store two files per
blob directory, a small stub file with the header info and the
unaltered file data.
what are the caveats to a system like this? has anyone looked into
this before?
-chad
p.s.
i tried submitting a post through nabble a few days and it said that
it was still pending, so i thought i'd try submitting directly to the
mailing list. sorry, if i end up double-posting
^ permalink raw reply
* Re: http fixes, was Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-24 9:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Hommey, git
In-Reply-To: <alpine.DEB.1.00.0901240125190.3586@pacific.mpi-cbg.de>
On Sat, Jan 24, 2009 at 01:26, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 23 Jan 2009, Mike Hommey wrote:
>> As I said when posting my patch batch, I don't have much time nor
>> motivation to work on this series. But let's make a deal: if someone
>> writes a good enough http test suite, I'll polish the http code.
>
> I already said in my replied to your patch that I will add the http test
> suite if you fix your patches.
I think Mike meant that he wants a working test suite before
continuing work on it? As in, what's the point in working on something
if you don't have a working test-suite to test your solution against
;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: read-only working copies using links
From: Sverre Rabbelier @ 2009-01-24 11:02 UTC (permalink / raw)
To: Chad Dombrova, Tim 'Mithro' Ansell; +Cc: git
In-Reply-To: <3EE64C92-CB4C-47BD-9C48-E369AED4B82F@gmail.com>
Heya,
On Sat, Jan 24, 2009 at 10:17, Chad Dombrova <chadrik@gmail.com> wrote:
> the crux of the issue is that the blob objects would have to be stored as
> exact copies of the original files. it would seem there are two things that
> currently prevent this from happening. 1) blobs are stored with compression
> and 2) they include a small header. compression can be disabled by setting
> core.loosecompression to 0, so that seems like less of an issue. as for the
> header, wouldn't it be possible to store it separately? in other words,
> store two files per blob directory, a small stub file with the header info
> and the unaltered file data.
I think Tim Ansell (cced) was talking about this at the gittogether
(storing the metadata seperately), as it would benefit sparse/narrow
checkout, another advantage supporting his case?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-24 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, René Scharfe, git
In-Reply-To: <7vmydi4kiz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 23.01.2009:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > Jeff King, 22.01.2009:
> > ...
> >> > ...
> >> > That would probably be better.
> >>
> >> Do you want to work on it, or should it go into the "yeah, right, one
> >> day" section of my todo list?
> >
> > Yes, feel free to enlarge your todo list :)
> > There are some other things that I want to work on before, so better
> > don't count on me for this. But maybe I'll come up to it, before your
> > todo list pointer reaches this item, who knows.
>
> Whatever.
>
> I merged and pushed out these two patches but they seem to break
> format-patch big time if you have ui.color set to auto.
>
> I will be reverting them out of 'next'. Grumble.
Damn, sorry for this.
I looked at the code and found this in git_format_config():
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
return 0;
Which of course didn't handle color.ui, but that wasn't necessary before
the central color.ui handling from my patch.
So with the following diff it works:
- if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
+ if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")
+ || !strcmp(var, "color.ui")) {
Compared to f3aafa4 (Disable color detection during format-patch,
2006-07-09) and a159ca0 (Allow subcommand.color and color.subcommand
color configuration, 2006-12-13), which introduced !strcmp(var,
"diff.color") resp. !strcmp(var, "color.diff") at this place.
Or with this, which however would be a similar thing to what I tried to
remove from the code.
git_config(git_format_config, NULL);
+ diff_use_color_default = 0;
format-patch is perhaps the only place where the commit has broken
things, because I didn't find other places, where color config options
were set, but not the corresponding variables. So it seems as if only
format-patch needed code like this to turn off the colors.
Markus
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Johannes Schindelin @ 2009-01-24 13:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Hannu Koivisto, Junio C Hamano, git
In-Reply-To: <94a0d4530901240021u65adeff8pb6995ef707bc1f68@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Felipe Contreras wrote:
> On Thu, Jan 22, 2009 at 8:59 PM, Hannu Koivisto <azure@iki.fi> wrote:
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
> >>> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >>>
> >>>> This brings back my previous question: where is the home directory in
> >>>> a Windows system?
> >>>
> >>> It's where %HOMEDRIVE%%HOMEPATH% points to.
> >>
> >> I thought it was something like that. Do we want something like that
> >> in the manual, or should we assume Windows users know that?
> >
> > I should have added that Unix programs (i.e. Cygwin programs and
> > even some native ports) probably use %HOME% which may be different
> > from %HOMEDRIVE%%HOMEPATH%. I recall that if you haven't
> > explicitly set up HOME in Windows environment, Cygwin sets it up
> > magically from passwd or falls back to %HOMEDRIVE%%HOMEPATH%. I
> > have no idea if msysgit respects %HOME% if it is set or always uses
> > %HOMEDRIVE%%HOMEPATH% or something completely different (user
> > profile, most likely).
> >
> > It certainly may be that "home directory" is a foreign concept to
> > some Windows users. Some might know it as a user profile or a
> > personal folder (just guessing, I'm pretty isolated from less
> > experienced Windows users), even though user profile is a separate
> > concept from "home directory" (note that there is %USERPROFILE%
> > which by default is the same as %HOMEDRIVE%%HOMEPATH% at least in
> > XP).
> >
> > In any case, what Cygwin git does should be expected by Cygwin
> > users. If msysgit wanted to be a really native Windows application
> > and store the configuration where Microsoft thinks it should be
> > stored, it probably shouldn't store the config under "home
> > directory" to begin with (I'm guessing that's what it does) but
> > under %USERPROFILE\Application Data\Git (...FILE\Local
> > Settings\... in case non-roaming storage is wanted). And in that
> > case the manual might be misleading for msysgit users. See
> > e.g. <http://msdn.microsoft.com/en-us/library/ms995853.aspx>.
>
> Isn't that enough argument to stop assuming the user knows where is
> the "home directory"?
Why does it appear as if we always have to bend over for Windows? That is
really frustrating.
In any case, the only thing the user would need to know the location of
$HOME for is for .gitconfig. And for Windows users I suggest using the
dialog in git gui (for the variables that are editable there), which
should cover most of what the user needs. For everything else, they
should use "git config".
Because if you really start with explaining where the home can be on
Windows, you would also have to cover why "%USERPROFILE%" does not work in
Git bash. And before you know what is happening, you have a big ass
Windows chapter in the user manual that revolves around anything except
Git.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Johannes Schindelin @ 2009-01-24 13:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901240044y452b465fj94df82fc2b8f7ee9@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Lars Hjemli wrote:
> On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > in all of Git, we try to assume that only reachable objects are valid
> > objects.
>
> I don't think this is true (most git commands accepts their arguments
> as valid objects without verifying if they are reachable from a ref).
The fact that a user can ask for some object directly, and that we do not
try to validate it in that case has nothing to do with said assumption.
If something is pushed to a remote, and the connection fails, some commit
could be pushed already, but some of its reachable objects lacking.
The user on the remote side can still try to salvage parts by accessing
the objects directly, by their name.
But the only guarantee that the objects are reachable is to start from a
ref.
Concretely, if your patch is applied as-is, such a half-pushed state could
affect git-archive in a nasty way: even if the user started from a ref,
there could be missing objects!
> Do you feel it is necessary to perform a reachability check of the
> gitlink'd commit before traversing into a submodule tree?
No. Because HEAD is a ref, too.
Now, there is still a problem when your submodule is missing the objects
for the commit your superproject is referring to.
IMO that is a serious issue, as it just asks for confused users.
> > - presence of a specific commit in the supermodule is a _lousy_
> > indicator that the user wants to include that submodule in the
> > archive.
>
> This is the issue I tried to address with my
> `--submodules=[a|c|r][g:<name>]` proposal in the commit message for
> this patch.
Nope, doing this "in the future" does not please me one bit.
Besides, I find the semantics, uhm, "interesting". (The other word would
be "unintuitive". Why do you have to be so cryptic that I have to read
the proposal to understand what the heck "c" is about?)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-24 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Hannu Koivisto, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901241438370.13232@racer>
On Sat, Jan 24, 2009 at 3:42 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Jan 2009, Felipe Contreras wrote:
>
>> On Thu, Jan 22, 2009 at 8:59 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> > Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >
>> >> On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> >>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >>>
>> >>>> This brings back my previous question: where is the home directory in
>> >>>> a Windows system?
>> >>>
>> >>> It's where %HOMEDRIVE%%HOMEPATH% points to.
>> >>
>> >> I thought it was something like that. Do we want something like that
>> >> in the manual, or should we assume Windows users know that?
>> >
>> > I should have added that Unix programs (i.e. Cygwin programs and
>> > even some native ports) probably use %HOME% which may be different
>> > from %HOMEDRIVE%%HOMEPATH%. I recall that if you haven't
>> > explicitly set up HOME in Windows environment, Cygwin sets it up
>> > magically from passwd or falls back to %HOMEDRIVE%%HOMEPATH%. I
>> > have no idea if msysgit respects %HOME% if it is set or always uses
>> > %HOMEDRIVE%%HOMEPATH% or something completely different (user
>> > profile, most likely).
>> >
>> > It certainly may be that "home directory" is a foreign concept to
>> > some Windows users. Some might know it as a user profile or a
>> > personal folder (just guessing, I'm pretty isolated from less
>> > experienced Windows users), even though user profile is a separate
>> > concept from "home directory" (note that there is %USERPROFILE%
>> > which by default is the same as %HOMEDRIVE%%HOMEPATH% at least in
>> > XP).
>> >
>> > In any case, what Cygwin git does should be expected by Cygwin
>> > users. If msysgit wanted to be a really native Windows application
>> > and store the configuration where Microsoft thinks it should be
>> > stored, it probably shouldn't store the config under "home
>> > directory" to begin with (I'm guessing that's what it does) but
>> > under %USERPROFILE\Application Data\Git (...FILE\Local
>> > Settings\... in case non-roaming storage is wanted). And in that
>> > case the manual might be misleading for msysgit users. See
>> > e.g. <http://msdn.microsoft.com/en-us/library/ms995853.aspx>.
>>
>> Isn't that enough argument to stop assuming the user knows where is
>> the "home directory"?
>
> Why does it appear as if we always have to bend over for Windows? That is
> really frustrating.
>
> In any case, the only thing the user would need to know the location of
> $HOME for is for .gitconfig. And for Windows users I suggest using the
> dialog in git gui (for the variables that are editable there), which
> should cover most of what the user needs. For everything else, they
> should use "git config".
>
> Because if you really start with explaining where the home can be on
> Windows, you would also have to cover why "%USERPROFILE%" does not work in
> Git bash. And before you know what is happening, you have a big ass
> Windows chapter in the user manual that revolves around anything except
> Git.
Huh? That was exactly my point.
It's much easier for everyone to just use git config --global than
explain how create and edit the .gitconfig file. If this is explained
it shouldn't be in the "Telling git your name" section.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Johannes Schindelin @ 2009-01-24 14:14 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Junio C Hamano, Jeff King, René Scharfe, git
In-Reply-To: <200901241228.33690.markus.heidelberg@web.de>
Hi,
On Sat, 24 Jan 2009, Markus Heidelberg wrote:
> format-patch is perhaps the only place where the commit has broken
> things, because I didn't find other places, where color config options
> were set, but not the corresponding variables. So it seems as if only
> format-patch needed code like this to turn off the colors.
So you want to add a test case when you resubmit your patch...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Change octal literals to be XEmacs friendly
From: malc @ 2009-01-24 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <7v3af9p9lq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> malc@pulsesoft.com writes:
>
>> Kalle Olavi Niemitalo <kon@iki.fi> writes:
>>
>>> Vassili Karpov <av1474@comtv.ru> writes:
>>>
>>>> #ooctal syntax on the other hand produces integers everywhere.
>>>
>>> GNU Emacs 20.7 doesn't support #o, but neither does it include
>>
>> Bummer
>
> To be portable you could certainly spell them in decimal integers, no?
Sure.
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-24 14:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, René Scharfe, git
In-Reply-To: <alpine.DEB.1.00.0901241513460.13232@racer>
Johannes Schindelin, 24.01.2009:
> Hi,
>
> On Sat, 24 Jan 2009, Markus Heidelberg wrote:
>
> > format-patch is perhaps the only place where the commit has broken
> > things, because I didn't find other places, where color config options
> > were set
(and evaluated)
> > , but not the corresponding variables. So it seems as if only
> > format-patch needed code like this to turn off the colors.
>
> So you want to add a test case when you resubmit your patch...
I'm not sure, whether it should be resubmitted at all. As Jeff pointed
out, there should be a better way to clean up the color (and color.ui)
handling.
Markus
^ permalink raw reply
* [PATCH] Makefile: Use libc strlcpy on OSX
From: Benjamin Kramer @ 2009-01-24 15:41 UTC (permalink / raw)
To: git; +Cc: gitster
OSX supports strlcpy(3) since 10.2 so we don't need
to use our own.
Signed-off-by: Benjamin Kramer <benny.kra@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..4c9aab5 100644
--- a/Makefile
+++ b/Makefile
@@ -643,7 +643,6 @@ ifeq ($(uname_S),Darwin)
ifneq ($(shell expr "$(uname_R)" : '9\.'),2)
OLD_ICONV = UnfortunatelyYes
endif
- NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
--
1.6.1.285.g3454
^ permalink raw reply related
* Re: [PATCH 0/4] gitweb feed metadata tuneups
From: Jakub Narebski @ 2009-01-24 16:02 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1232686121-1800-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 23 Jan 2009, Giuseppe Bilotta wrote:
> The next four patches add some metadata to gitweb generated feeds:
> channel image, managing editor and last-update dates are added to RSS
> feeds, and the feed generator (gitweb, with version specification) is
> added to both RSS and Atom feeds.
>
> Giuseppe Bilotta (4):
> gitweb: channel image in rss feed
> gitweb: feed generator metadata
> gitweb: rss feed managingEditor
> gitweb: rss channel date
>
> gitweb/gitweb.perl | 20 +++++++++++++++++++-
> 1 files changed, 19 insertions(+), 1 deletions(-)
I like this series; however I do not use gitweb feeds (Atom or RSS),
so I cannot say anything on their validity and usefullness.
P.S. I tried to look up who is responsible (who have added) RSS code,
but unfortunately it looks like it dates back to Kay Sievers.
Unfortunately because IIRC he is not active on the list...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Tim Henigan @ 2009-01-24 16:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901240726070.13232@racer>
On Sat, Jan 24, 2009 at 1:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi,
>
> On Thu, 22 Jan 2009, Tim Henigan wrote:
>
> > Use time_t for timestamps returned by approxidate() instead of unsigned
> > long. All references to approxidate were checked as well as references
> > to OPT_DATE.
>
> Hmm. I vaguely remember Linus mentioning recently that unsigned long is
> the appropriate data type for the Unix Epoch...
You are correct. I just found a post on this list where Linus
specifically rejected a similar patch from another contributor. A
quote from https://kerneltrap.org/mailarchive/git/2008/11/6/4014124:
" "time_t" is one of those totally broken unix types. The
standards say that
it's an "arithmetic" type, but leaves it open to be just about anything.
Traditionally, it's a signed integer (bad), and in theory it could even be
a floating point value, I think.
And in _all_ such cases, it's actually better to cast it to "unsigned
long" than keep time in a system-dependent format that is most likely
either _already_ "unsigned long", or alternatively broken."
Should I update the GitWiki page to remove this Janitor task or do you
keep it as a test to see if people are properly searching the mail
archives?
Sorry to waste your time on the patch review.
Thanks,
Tim
^ permalink raw reply
* PATCH] http-push: refactor request url creation
From: Ray Chuan @ 2009-01-24 16:16 UTC (permalink / raw)
To: git, Johannes Schindelin
Currently, functions that deal with objects on the remote repository
have to allocate and do strcpys to generate the URL.
This patch saves them this trouble, by providing a function that
returns a URL: either the object's 2-digit hex directory (eg.
/objects/a1/) or the complete object location (eg. /objects/a1/b2).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http-push.c | 58 +++++++++++++++++++---------------------------------------
1 files changed, 19 insertions(+), 39 deletions(-)
diff --git a/http-push.c b/http-push.c
index cb5bf95..715954e 100644
--- a/http-push.c
+++ b/http-push.c
@@ -177,6 +177,16 @@ struct remote_ls_ctx
struct remote_ls_ctx *parent;
};
+static char *get_remote_object_url(const char *url, const char *hex,
int only_two_digit_postfix) {
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "%sobjects/%.*s/", url, 2, hex);
+ if(!only_two_digit_postfix)
+ strbuf_addf(&buf, "%s", hex+2);
+
+ return strbuf_detach(&buf, NULL);
+}
+
static void finish_request(struct transfer_request *request);
static void release_request(struct transfer_request *request);
@@ -222,8 +232,6 @@ static void start_fetch_loose(struct
transfer_request *request)
char *hex = sha1_to_hex(request->obj->sha1);
char *filename;
char prevfile[PATH_MAX];
- char *url;
- char *posn;
int prevlocal;
unsigned char prev_buf[PREV_BUF_SIZE];
ssize_t prev_read = 0;
@@ -273,17 +281,7 @@ static void start_fetch_loose(struct
transfer_request *request)
git_SHA1_Init(&request->c);
- url = xmalloc(strlen(remote->url) + 50);
- request->url = xmalloc(strlen(remote->url) + 50);
- strcpy(url, remote->url);
- posn = url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- strcpy(request->url, url);
+ request->url = get_remote_object_url(remote->url, hex, 0);
/* If a previous temp file is present, process what was already
fetched. */
@@ -327,7 +325,7 @@ static void start_fetch_loose(struct
transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_FILE, request);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, request->errorstr);
- curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_pragma_header);
/* If we have successfully processed data from a previous fetch
@@ -356,16 +354,8 @@ static void start_mkcol(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
- request->url = xmalloc(strlen(remote->url) + 13);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- strcpy(posn, "/");
+ request->url = get_remote_object_url(remote->url, hex, 1);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -480,7 +470,7 @@ static void start_put(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
+ struct strbuf url_buf = STRBUF_INIT;
enum object_type type;
char hdr[50];
void *unpacked;
@@ -519,21 +509,11 @@ static void start_put(struct transfer_request *request)
request->buffer.buf.len = stream.total_out;
- request->url = xmalloc(strlen(remote->url) +
- strlen(request->lock->token) + 51);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
+ strbuf_addf(&url_buf, "Destination: %s",
get_remote_object_url(remote->url, hex, 0));
+ request->dest = strbuf_detach(&url_buf, NULL);
+
+ strbuf_addf(&url_buf, "%s_%s", get_remote_object_url(remote->url,
hex, 0), request->lock->token);
+ request->url = strbuf_detach(&url_buf, NULL);
slot = get_active_slot();
slot->callback_func = process_response;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Wincent Colaiuta @ 2009-01-24 16:37 UTC (permalink / raw)
To: Tim Henigan; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <32c343770901240813k2eeb19b0q65b533f829cb44d4@mail.gmail.com>
El 24/1/2009, a las 17:13, Tim Henigan escribió:
> Should I update the GitWiki page to remove this Janitor task or do you
> keep it as a test to see if people are properly searching the mail
> archives?
I don't know of too many projects which intentionally publish
misleading information to "test" would-be contributors. I think
editing the wiki would be a good idea.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Johannes Schindelin @ 2009-01-24 16:58 UTC (permalink / raw)
To: Tim Henigan; +Cc: git, gitster
In-Reply-To: <32c343770901240813k2eeb19b0q65b533f829cb44d4@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Tim Henigan wrote:
> On Sat, Jan 24, 2009 at 1:27 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Thu, 22 Jan 2009, Tim Henigan wrote:
> >
> > > Use time_t for timestamps returned by approxidate() instead of
> > > unsigned long. All references to approxidate were checked as well
> > > as references to OPT_DATE.
> >
> > Hmm. I vaguely remember Linus mentioning recently that unsigned long
> > is the appropriate data type for the Unix Epoch...
>
> You are correct. I just found a post on this list where Linus
> specifically rejected a similar patch from another contributor. A quote
> from https://kerneltrap.org/mailarchive/git/2008/11/6/4014124:
>
> " "time_t" is one of those totally broken unix types. The standards
> say that it's an "arithmetic" type, but leaves it open to be just
> about anything. Traditionally, it's a signed integer (bad), and in
> theory it could even be a floating point value, I think.
>
> And in _all_ such cases, it's actually better to cast it to
> "unsigned long" than keep time in a system-dependent format that is
> most likely either _already_ "unsigned long", or alternatively
> broken."
Thanks. I should have searched that post myself, but I was too tired...
> Should I update the GitWiki page to remove this Janitor task or do you
> keep it as a test to see if people are properly searching the mail
> archives?
Yes, please!
> Sorry to waste your time on the patch review.
Sorry that we wasted your time by letting that page go stale...
Ciao,
Dscho
^ permalink raw reply
* Re: PATCH] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-24 17:03 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901240816r25e6a9c9q2d437d413a524362@mail.gmail.com>
Hi,
On Sun, 25 Jan 2009, Ray Chuan wrote:
> Currently, functions that deal with objects on the remote repository
> have to allocate and do strcpys to generate the URL.
>
> This patch saves them this trouble, by providing a function that
> returns a URL: either the object's 2-digit hex directory (eg.
> /objects/a1/) or the complete object location (eg. /objects/a1/b2).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make that an Acked-by: okay?
> diff --git a/http-push.c b/http-push.c
> index cb5bf95..715954e 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -177,6 +177,16 @@ struct remote_ls_ctx
> struct remote_ls_ctx *parent;
> };
>
> +static char *get_remote_object_url(const char *url, const char *hex,
> int only_two_digit_postfix) {
It is actually a prefix.
Ciao,
Dscho
^ 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