* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 18:43 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612120641.52556.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> The colour parameter is "color.branch" rather than "branch.color" to
> avoid clashing with the default namespace for default branch merge
> definitions.
Very nice.
> c = ' ';
> if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
> - !strcmp(ref_list.list[i].name, head))
> + !strcmp(ref_list.list[i].name, head)) {
> c = '*';
> + color = COLOR_BRANCH_CURRENT;
> + }
>
> if (verbose) {
> - printf("%c %-*s", c, ref_list.maxwidth,
> - ref_list.list[i].name);
> + printf("%c %s%-*s%s", c,
> + branch_get_color(color),
> + ref_list.maxwidth,
> + ref_list.list[i].name,
> + branch_get_color(COLOR_BRANCH_RESET));
> print_ref_info(ref_list.list[i].sha1, abbrev);
> }
> else
> - printf("%c %s\n", c, ref_list.list[i].name);
> + printf("%c %s%s%s\n", c,
> + branch_get_color(color),
> + ref_list.list[i].name,
> + branch_get_color(COLOR_BRANCH_RESET));
> }
Now this makes me wonder if under output coloring we would still
want the two-space indent and '*' prefix.
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 18:43 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612121103.31110.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> + "", /* LOCAL (normal) */
>> + "\033[32m", /* CURRENT (green) */
>
> In keeping with the "don't use green" idea - can I suggest just bold normal
> for the CURRENT? That way there is the most minimal use of colour for the
> default git-branch output, but still retaining a visual indicator.
I do not have strong preference either way.
The CURRENT is highlighted with '*' so I think we certainly can
lose green and even go vanilla. I only tried to avoid bold
because no built-in default coloring currently use it, and in
the past I've worked with terminals that do not have enough
contrast between normal and bold and for some people that might
become an issue.
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Nicolas Pitre @ 2006-12-12 18:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612120949230.3535@woody.osdl.org>
On Tue, 12 Dec 2006, Linus Torvalds wrote:
> If the public sites used git itself to synchronize git repositories,
> they'd never see anything like this (because git itself will only write
> the new refs after it has actually updated the data). But since the thing
> needs mirroring for non-git uses too, and since rsync generally _works_
> apart from the slight race-condition issue, that's what it just uses.
Wouldn't it be a worthy goal to exclude git repos from the rsync
mirroring and use git instead? The current arrangement doesn't put git
in good light for the general public not reading this mailing list wrt
git reliability, even if we know it is just a minor and temporary
annoyance.
A failure always makes you look bad regardless of its severity.
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Nicolas Pitre @ 2006-12-12 18:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612121908100.2807@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 12 Dec 2006, Linus Torvalds wrote:
>
> > But since the thing needs mirroring for non-git uses too, and since
> > rsync generally _works_ apart from the slight race-condition issue,
>
> ... and git would probably change the pack structure (i.e. which objects
> are in which packs, or even loose) which would be too bad for all those
> HTTP leechers ...
I don't see how that would be more of a concern than the current
situation with occasional repacks.
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Johannes Schindelin @ 2006-12-12 18:55 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
In-Reply-To: <457E979F.9060307@xs4all.nl>
Hi,
On Tue, 12 Dec 2006, Han-Wen Nienhuys wrote:
> I still don't understand the problem with autoconf; there are already
> plenty of baroque shell scripts in GIT. I hate writing m4 macros as
> well, but that's not a problem for GIT users (ie. people who compile
> GIT).
That, together with the complexity of GIT_EXEC_DIR and path mangling
problems, makes me take every opportunity to suggest we should build in
most if not all of Git into the "git wrapper".
Granted, without completion scripts, the "git-" convention was nice.
Granted, with bash, Perl and even Python, you can rapidly prototype your
thoughts (even if I often miss the power of C there).
But in the end, I'd say it makes lots of sense to have everything in one
executable.
Ciao,
Dscho
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Linus Torvalds @ 2006-12-12 19:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121345180.18171@xanadu.home>
On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>
> Wouldn't it be a worthy goal to exclude git repos from the rsync
> mirroring and use git instead?
Well, one of the problems is simply maintenance of kernel.org.
It's just _simpler_ to use rsync for everything.
Look at the current gitweb caching discussion. Did anybody actually step
up to be a gitweb maintainer on kernel.org?
Same deal. Simplicity and lack of maintenance is sometimes not just a good
idea, it's a requirement.
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Johannes Schindelin @ 2006-12-12 19:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121352520.18171@xanadu.home>
Hi,
On Tue, 12 Dec 2006, Nicolas Pitre wrote:
> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
>
> > On Tue, 12 Dec 2006, Linus Torvalds wrote:
> >
> > > But since the thing needs mirroring for non-git uses too, and since
> > > rsync generally _works_ apart from the slight race-condition issue,
> >
> > ... and git would probably change the pack structure (i.e. which objects
> > are in which packs, or even loose) which would be too bad for all those
> > HTTP leechers ...
>
> I don't see how that would be more of a concern than the current
> situation with occasional repacks.
Oh well. I did not want to get bashed for something which is probably no
problem, but I suspected that the two mirror machines could get out of
sync, which could well mean that the new packs would have to be downloaded
_twice_. As I said, probably no problem.
But it would become a non-problem when the HTTP transport would learn to
read and interpret the .idx files, basically constructing thin packs from
parts of the .pack files ("Content-Range:" comes to mind)...
Ciao,
Dscho
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Nicolas Pitre @ 2006-12-12 19:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121021270.3535@woody.osdl.org>
On Tue, 12 Dec 2006, Linus Torvalds wrote:
> And kernel.org will probably start doing automatic repacking, since the
> current situation just means that some people don't repack on their own,
> and have tens of thousands of loose objects.
Maybe object sharing between repos could be a good idea too? All kernel
repos are likely to contain a large subset of your own so they could
have a reference on it by default. That would certainly allow for
better caching and less IO on the server.
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Linus Torvalds @ 2006-12-12 19:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121400530.18171@xanadu.home>
On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>
> Maybe object sharing between repos could be a good idea too?
We often do. Many people have used "git clone -s -l", and as long as you
repack with the "-l" flag too, the object sharing actually increases over
time as the base repo gets repacked and the cloned repo keeps using the
growing base pack..
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Jakub Narebski @ 2006-12-12 19:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612121956470.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> But it would become a non-problem when the HTTP transport would learn to
> read and interpret the .idx files, basically constructing thin packs from
> parts of the .pack files ("Content-Range:" comes to mind)...
cURL the CLI can do this with -r/--range option, so I think that curl
the library can do this too. Mind you, this is HTTP/1.1 extension
(hmmm... I wonder if many sites run HTTP/1.0 only).
See also: http://www.linux.com/article.pl?sid=06/10/10/1824245
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Jakub Narebski @ 2006-12-12 19:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612121021270.3535@woody.osdl.org>
Linus Torvalds wrote:
> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
>> > rsync generally _works_ apart from the slight race-condition issue,
>>
>> ... and git would probably change the pack structure (i.e. which objects
>> are in which packs, or even loose) which would be too bad for all those
>> HTTP leechers ...
>
> Well, as it is, I end up repacking my git archives on kernel.org every two
> weeks or so anyway, so anybody who uses stupid protocols (rsync or http)
> will end up downloading everything anew anyway.
What about "logaritmic packs" idea someone (Pasky?) posted on git mailing
list: pack from last week, pack from last month except last week, pack from
two months, pack from four months, pack from last year...
> And kernel.org will probably start doing automatic repacking, since the
> current situation just means that some people don't repack on their own,
> and have tens of thousands of loose objects.
...with *.keep to keep archive packs it can be even automated somewhat.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Nicolas Pitre @ 2006-12-12 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612121956470.2807@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>
> > On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> >
> > > On Tue, 12 Dec 2006, Linus Torvalds wrote:
> > >
> > > > But since the thing needs mirroring for non-git uses too, and since
> > > > rsync generally _works_ apart from the slight race-condition issue,
> > >
> > > ... and git would probably change the pack structure (i.e. which objects
> > > are in which packs, or even loose) which would be too bad for all those
> > > HTTP leechers ...
> >
> > I don't see how that would be more of a concern than the current
> > situation with occasional repacks.
>
> Oh well. I did not want to get bashed for something which is probably no
> problem,
Sorry, far from me to sound as if I was bashing you.
> but I suspected that the two mirror machines could get out of
> sync, which could well mean that the new packs would have to be downloaded
> _twice_. As I said, probably no problem.
In theory that should not happen since all mirrors would get the same
updates in the same steps. But in practice if one mirror fails to get
updated for whatever reason then the next time around it could have a
bigger pack instead of two smaller ones for the same set of objects.
> But it would become a non-problem when the HTTP transport would learn to
> read and interpret the .idx files, basically constructing thin packs from
> parts of the .pack files ("Content-Range:" comes to mind)...
Woooh.
^ permalink raw reply
* LilyPond 2.11.2 is out
From: Han-Wen Nienhuys @ 2006-12-12 19:29 UTC (permalink / raw)
To: git
2.11.2 is out.
This release has further tuning of the skyline code, and support for
harmonics and glissandos in tablature. Of course, it also includes
several bugfixes.
Enjoy!
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Johannes Schindelin @ 2006-12-12 19:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121420580.18171@xanadu.home>
Hi,
On Tue, 12 Dec 2006, Nicolas Pitre wrote:
> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
>
> > But it would become a non-problem when the HTTP transport would learn
> > to read and interpret the .idx files, basically constructing thin
> > packs from parts of the .pack files ("Content-Range:" comes to
> > mind)...
>
> Woooh.
Does that mean "Yes, I'll do it"? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] E-mail aliases
From: Eric Wong @ 2006-12-12 19:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0612120449k4a13ac85t313df1e460ed46e4@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> Hi,
>
> I added a feature to StGIT (not released yet) so that one can specify
> an alias instead of a complete e-mail address on the command line (or
> in the template file), i.e.:
>
> stg mail --to=lkml
git-send-email can be configured to parse mutt, mailrc, pine and gnu
alias files. I use the mutt one extensively myself and find it very
useful.
--
^ permalink raw reply
* Re: LilyPond 2.11.2 is out
From: Han-Wen Nienhuys @ 2006-12-12 19:36 UTC (permalink / raw)
To: git
In-Reply-To: <elmvup$q4v$1@sea.gmane.org>
Han-Wen Nienhuys escreveu:
> 2.11.2 is out.
>
> This release has further tuning of the skyline code, and support for
> harmonics and glissandos in tablature. Of course, it also includes
> several bugfixes.
>
> Enjoy!
>
Excuse me, error located between chair and computer.
Please ignore.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Linus Torvalds @ 2006-12-12 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612122031450.2807@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>
> > On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> >
> > > But it would become a non-problem when the HTTP transport would learn
> > > to read and interpret the .idx files, basically constructing thin
> > > packs from parts of the .pack files ("Content-Range:" comes to
> > > mind)...
> >
> > Woooh.
>
> Does that mean "Yes, I'll do it"? ;-)
Umm. I hope it means "Woooh, that's crazy talk".
You do realize that then you need to teach the http-walker about walking
the delta chain all the way up? For big pulls, you're going to be a lot
_slower_ than just downloading the whole dang thing, because the delta
objects are often just ~40 bytes, and you've now added a ping-pong latency
for each such small transfer.
You don't need to download many such small ranges, and suddenly the few
hundred ping-pongs that got you a few tens of kB of data took longer than
just downloading a big stream efficiently that got you everything.
One big reason the native git protocol is efficient is that it's largely a
streaming protocol (apart from the early ref-walking, but even that tries
to stream as much as possible, rather than having a back-and-forth latency
for each query)
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Nicolas Pitre @ 2006-12-12 19:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612122031450.2807@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>
> > On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> >
> > > But it would become a non-problem when the HTTP transport would learn
> > > to read and interpret the .idx files, basically constructing thin
> > > packs from parts of the .pack files ("Content-Range:" comes to
> > > mind)...
> >
> > Woooh.
>
> Does that mean "Yes, I'll do it"? ;-)
Absolutely not. ;-) I know next to nothing about HTTP to start with.
It just looks like a crazy idea that might actually work.
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Deepak Barua @ 2006-12-12 19:51 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200612051726.kB5HQO2t015777@laptop13.inf.utfsm.cl>
Hi Mr Brand,
what you are suggesting seems fine to me but the
thing is should i write a GIT plugin where cani get info to write
one...?
Regards
Deepak
On 12/5/06, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:
> Deepak Barua <dbbarua@gmail.com> wrote:
> > I am just thought of a idea to integrate a spell checker with
> > git so that when we check in the code the code comments are spell
> > checked before being put into the tree,maybe have a optimized
> > dictionary search.
> > what about this...? is it appropriate ...?
>
> An external tool that spellchecks your code would certainly be nice, but
> I'd vote against integrating it into git (or any other tool for that
> matter). git doesn't care if what is being saved is C code, Malebolge, or a
> collection of dirty pictures. And that is 100% fine with me. Don't kill
> this, it is one of the fundamental Unix strengths.
> --
> Dr. Horst H. von Brand User #22616 counter.li.org
> Departamento de Informatica Fono: +56 32 2654431
> Universidad Tecnica Federico Santa Maria +56 32 2654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
>
>
--
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Jakub Narebski @ 2006-12-12 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612121144220.3535@woody.osdl.org>
Linus Torvalds wrote:
>
>
> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
>> On Tue, 12 Dec 2006, Nicolas Pitre wrote:
>>
>>> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
>>>
>>>> But it would become a non-problem when the HTTP transport would learn
>>>> to read and interpret the .idx files, basically constructing thin
>>>> packs from parts of the .pack files ("Content-Range:" comes to
>>>> mind)...
>>>
>>> Woooh.
>>
>> Does that mean "Yes, I'll do it"? ;-)
>
> Umm. I hope it means "Woooh, that's crazy talk".
>
> You do realize that then you need to teach the http-walker about walking
> the delta chain all the way up? For big pulls, you're going to be a lot
> _slower_ than just downloading the whole dang thing, because the delta
> objects are often just ~40 bytes, and you've now added a ping-pong latency
> for each such small transfer.
>
> You don't need to download many such small ranges, and suddenly the few
> hundred ping-pongs that got you a few tens of kB of data took longer than
> just downloading a big stream efficiently that got you everything.
While I think the problem is much better solved by having "archive" pack(s)
and "current" pack, perhaps with always sownloading the whole delta it
would be feasible?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Johannes Schindelin @ 2006-12-12 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612121144220.3535@woody.osdl.org>
Hi,
On Tue, 12 Dec 2006, Linus Torvalds wrote:
> On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> > On Tue, 12 Dec 2006, Nicolas Pitre wrote:
> >
> > > On Tue, 12 Dec 2006, Johannes Schindelin wrote:
> > >
> > > > But it would become a non-problem when the HTTP transport would learn
> > > > to read and interpret the .idx files, basically constructing thin
> > > > packs from parts of the .pack files ("Content-Range:" comes to
> > > > mind)...
> > >
> > > Woooh.
> >
> > Does that mean "Yes, I'll do it"? ;-)
>
> Umm. I hope it means "Woooh, that's crazy talk".
>
> You do realize that then you need to teach the http-walker about walking
> the delta chain all the way up? For big pulls, you're going to be a lot
> _slower_ than just downloading the whole dang thing, because the delta
> objects are often just ~40 bytes, and you've now added a ping-pong latency
> for each such small transfer.
Two points:
- For loose objects, the HTTP walker does exactly that. This is the normal
case for "just a few objects since the last fetch". It will _never_ be the
case for the initial clone!
- Usually, the object fetching can be parallelized, because you want
multiple objects which are in disjunct delta chains. And for these, you
can say something like "Content-Range: 15-31,64-79,108-135" IIRC.
You could even fetch sensible chunks, i.e. cut only at multiples of 512 to
make the transport more efficient, and only fetch the parts which are
_still_ missing.
So, a crazy idea, yes. But a feasible one. Just not crazy enough to be
tempting for me (I use the git protocol whenever possible, too).
Ciao,
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Johannes Schindelin @ 2006-12-12 20:27 UTC (permalink / raw)
To: Deepak Barua; +Cc: Horst H. von Brand, git
In-Reply-To: <b5a19cd20612121151g74bae55fjd022b6314ffcf6c8@mail.gmail.com>
Hi,
On Wed, 13 Dec 2006, Deepak Barua wrote:
> what you are suggesting seems fine to me but the
> thing is should i write a GIT plugin where cani get info to write
> one...?
For a start, you might want to read Documentation/hooks.txt. Then you want
to inspect templates/hooks--pre-commit.
Hth,
Dscho
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-12 21:19 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Martin Langhoff, Jeff Garzik, Git Mailing List, Linus Torvalds,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457BB1A3.2070408@zytor.com>
By the way, setting Last-Modified: and ETag: and checking for
If-Modified-Since: and If-None-Match: is easy only for log-like views:
"shortlog", "log", "history", "rss"/"atom". With "shortlog" and
"history" we have additional difficulity of using relative dates there.
And even for those views we need reverse proxy / caching engine
(e.g. Squid in "HTTP accelerator" mode) in front.
It would be easier to pre-generate most common accessed views:
"projects_list", "summary" and "rss"/"atom" main for each project, and
just serve static pages. I don't know if we need to modify gitweb for
that.
BTW. for single client (rather stupid benchmark, I know) mod_perl is
about twice faster in keepalive mode than CGI version of gitweb for
git.git summary page.
--
Jakub Narebski
^ permalink raw reply
* Re: git-pull from git.git - no remote ref for pu or next?
From: Eric Wong @ 2006-12-12 21:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612120949230.3535@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> > And then it mysteriously fixed itself a few minutes later.
> > Is there some sort of publishing failure, or intermittent race condition?
>
> But because the public sites just mirror using rsync, and aren't really
> aware of git repositories etc at that stage, what can happen is that a
> mirroring is on-going when Junio does a push, and then the changes to the
> "refs/" directory might get rsync'ed before the "object/" directory does,
> and you end up with the public sites having references to objects that
> don't even _exist_ on those public sites any more.
>
> And once the mirroring completes, the issue just goes away, which explains
> why it just magically works five minutes later.
If kernel.org isn't using it already, I've found the --delay-updates
option of rsync works reasonably well and can cut down the
race-condition window. It does use more memory and disk space, however.
atomic-rsync (a perl front-end distributed with the rsync source) takes
even more disk space but works across an entire subdirectory all at once
(with 2 renames)
--
^ permalink raw reply
* Re: index manipulation quickref
From: Nguyen Thai Ngoc Duy @ 2006-12-12 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac1tvuyr.fsf@assigned-by-dhcp.cox.net>
On 12/13/06, Junio C Hamano <junkio@cox.net> wrote:
> I think this goes in the wrong direction. For "newbies" the
> Porcelain-ish set is supposed to be enough and if there is
> something missing that they need to do update-index command
> itself or a pipeline that involves update-index to achieve
> common tasks, we should enhance Porcelain-ish that captures the
> pattern.
It is supposed to be porcelain command only. I figure what operation a
user may need when manipulating index, then find the corresponding
porcelain command.
As you can see, we have porcelain commands for most of operations. The
missing piece is reset a file in index (and maybe "git cat-file
::file" -- it's too cryptic). Hopefully "git reset -- file" will be
implemented soon.
--
^ 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