* Re: Merging submodules
From: H.Merijn Brand @ 2008-07-31 20:44 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160807311203o3fb4deb8u4a5ae57818c76fab@mail.gmail.com>
On Thu, 31 Jul 2008 21:03:26 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Thu, Jul 31, 2008 at 20:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com>
> > wrote:
> >
> >> I see all OK. Can you provide a self consistent simple testcase that
> >> shows what is wrong?
> >
> > Yes. was rather easy.
> > http://www.xs4all.nl/~hmbrand/testcase.tgz
> >
>
> It is because you cannot merge a branch with an empty branch.
Super. So I start with a .gitignore and continue this process. It
worked!
> So, or you create an initial commit in the "superproject" or you
> create a commit just moving the files of the first module as in:
>
> http://article.gmane.org/gmane.comp.version-control.git/79887
Thanks again!
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Björn Steinbrink @ 2008-07-31 20:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
On 2008.07.31 13:09:09 -0700, Linus Torvalds wrote:
>
>
> On Thu, 31 Jul 2008, Craig L. Ching wrote:
> >
> > We find ourselves constantly having to shift gears and work on other
> > things in the middle of whatever it is we're currently working on. For
> > instance, in the scenario above, A might be branch that contains a
> > feature going into our next release. B might be a bugfix and takes
> > priority over A, so you have to leave A as-is and start work on B. When
> > I come back to work on A, I have to rebuild A to continue working, and
> > that's just too expensive for us. So we use the monotone-like
> > new-workdir which allows us to save those build artifacts.
> >
> > So, that said, I ask again, am I missing something? Is there a better
> > way to do this? How do the kernel developers do this, surely they're
> > switching branches back and forth having to build in-between?
>
> Sure, if you want to keep the build tree around, you would probably not
> use branches.
>
> But yes, then you'd likely do "git clone -s" with some single "common
> point" or use "git worktree". And even if you don't use "-s", you should
> _still_ effectively share at least all the old history (which tends to be
> the bulk) thanks to even a default "git clone" will just hardlink the
> pack-files.
>
> So literally, if you do
>
> git clone <cntral-repo-over-network> <local>
Hum, I guess I'm just missing something and prepare to get flamed, but
wouldn't you want that one to be bare? Otherwise, the other clones won't
see all of the original repo's branches, right?
Maybe even better:
mkdir local-mirror
cd local-mirror
git --bare init
git remote add -f --mirror origin <central-repo-over-network>
A cronjob (or whatever) could keep the local mirror up-to-date and the
other repos can fetch from there. Pushing would need to go to a
different remote then though.. Humm... Maybe not worth the trouble for a
bit of additional object sharing.
Björn
^ permalink raw reply
* Re: [PATCH 0/2] gitweb use sections
From: Gustavo Sverzut Barbieri @ 2008-07-31 20:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Jakub Narebski
In-Reply-To: <20080731203250.GO10151@machine.or.cz>
On Thu, Jul 31, 2008 at 5:32 PM, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> On Thu, Jul 31, 2008 at 04:43:35PM -0300, Gustavo Sverzut Barbieri wrote:
>> Since nobody replied and I missed some gitweb guys in CC, I'm adding
>> Petr and Jakub, as some guys said on IRC.
>>
>> Have anyone tried this patch, any problems?
>
> sorry, I have it in my review queue. At first pass it was looking
> good, but I wanted to look at it better before commenting.
no problem, just to see it was noticed or not :-)
> One thing I'm wondering about is how to make this stuff configurable,
> since I'm not very comfortable with adding more "unbound" configuration
> variables and would rather prefer stuff to be added to the $features
> array... I'm not at all sure about my own sentiment here, however.
Path comparison (first patch), Sections (second), both?
I know path comparison can be a performance hit on large listings on
sites with heavy traffic. However, I don't see many people accessing
the projects page at the same time for long periods, it's not like
slashdot... people mostly use it to know about repositories and then
use git to track it.
The slowness is due O(n^2) worst case of sort and each step is not
a bit heavier since it need to split path into components and walk
these. Maybe cache the split?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Sean Estabrooks @ 2008-07-31 20:57 UTC (permalink / raw)
To: Craig L. Ching; +Cc: Linus Torvalds, sverre, Git Mailinglist
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A5EE@emailmn.mqsoftware.com>
On Thu, 31 Jul 2008 14:48:21 -0500
"Craig L. Ching" <cching@mqsoftware.com> wrote:
> I have a question about this. I asked this awhile back and didn't
> really get any satisfactory answers except to use git-new-workdir, which
> makes git behave a lot like monotone. In our workflow, we do create
> branches for nearly everything, but we do find that we have a need to
> keep the build artifacts of those branches isolated from each other
> because rebuilding is expensive. IOW, we have this sort of workflow:
Is there a problem using git-new-workdir? It sounds like it does
exactly what you want.
> We find ourselves constantly having to shift gears and work on other
> things in the middle of whatever it is we're currently working on. For
> instance, in the scenario above, A might be branch that contains a
> feature going into our next release. B might be a bugfix and takes
> priority over A, so you have to leave A as-is and start work on B. When
> I come back to work on A, I have to rebuild A to continue working, and
> that's just too expensive for us. So we use the monotone-like
> new-workdir which allows us to save those build artifacts.
>
> So, that said, I ask again, am I missing something? Is there a better
> way to do this? How do the kernel developers do this, surely they're
> switching branches back and forth having to build in-between?
A decent build system will only compile the source files that actually
changed when switching branches. Couple that with a compiler cache
(such as ccache) and switching between branches in the kernel or git
project usually isn't prohibitively time consuming.
Sean
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Jan Krüger @ 2008-07-31 20:57 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891A0D0.6060503@lyx.org>
Hi,
> Disclaimer: I am involved in LyX development, so anything I said will
> be biased :-)
I think that's fine since I consider LaTeX (and therefore LyX as the
best graphical editor for it that I know) a choice always worth
considering when it comes to projects that have the size of a book.
> Now, about my shameless plug: LyX is ideally suited for structured
> documentation writing :-)
That may well be, but it gets really complicated once you want to
get your document into other markup-based formats while preserving all
the important aspects of formatting. I know this because I started
using LaTeX for a project that was supposed to be available in HTML
form along with, say, PDF. I've found that the only converter that
comes close to being useful for somewhat more ambitious sources
(including, perhaps, custom environments and stuff like that) without
spending a ridiculous amount of time trying to understand it is hevea.
Of course, hevea only translates to HTML, so, for example, generating
manpages or plain text is an entirely different matter of considerable
difficulty.
In addition to that, I suspect that LyX files might be difficult to
deal with in forky Git situations. For example, what if two
separately contributed patches need merging into a LyX source file?
This will only work automatically if the LyX source, treated as plain
text, has a really low chance of randomly changing in other places than
what the patch is supposed to touch. Also, if a merge does cause a
conflict, I imagine it would be difficult to resolve that.
Finally, it's pretty much a given that Git's manpages continue to use
AsciiDoc because there are few other things that can generate actual
manpages. I'm not sure it would be a good idea to keep half of Git's
documentation in one format and the rest in another. And AsciiDoc is --
by far! -- not the worst choice. I'm tempted to say it's the best that
I know.
-Jan
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-31 21:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080731044531.GB1860@spearce.org>
* Shawn O. Pearce <spearce@spearce.org> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> > alas, fetching still seems to be slow:
> >
> > titan:~/tip> time git-fetch origin
> >
> > real 0m5.112s
> > user 0m0.972s
> > sys 0m3.380s
>
> What version of git are dealing with on the client side?
the client side on titan has:
titan:~> git version
git version 1.5.2.2
oldish but not outrageously old, right?
server side has:
earth4:~> git version
git version 1.5.6.1.108.g660379
>
> fetch times of ~472 ms over git:// to your -tip.git tree and ~128 ms
> for strictly local fetch. If your SSH overhead is ~300 ms this is
> only a ~700 ms real time for `git fetch origin`, not 5100 ms.
>
> Is your git-fetch a shell script? Or a compiled binary? The port
> into C made it go _much_ faster, even though it is still a naive
> O(N^2) matching algorithm. Yea, we still should fix that, but I think
> an upgrade to 1.5.4 or later would make the client side improve
> consideribly.
ah, it is a shell script indeed! I'll upgrade to latest.
Ingo
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Avery Pennarun @ 2008-07-31 21:10 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Linus Torvalds, Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <20080731205400.GA7911@atjola.homenet>
On 7/31/08, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Maybe even better:
>
> mkdir local-mirror
> cd local-mirror
> git --bare init
> git remote add -f --mirror origin <central-repo-over-network>
>
> A cronjob (or whatever) could keep the local mirror up-to-date and the
> other repos can fetch from there. Pushing would need to go to a
> different remote then though.. Humm... Maybe not worth the trouble for a
> bit of additional object sharing.
What would be *really* great is if we could find a way for multiple
local clones to share the same objects, refs, and configuration - ie.
without pushing and pulling between them at all. Then they could
*all* point at the remote upstream repo through "origin", and
pushing/pulling with that repo would update the objects and refs for
all the local repos.
I'm not sure of the best way to do this, though. In particular, it
seems like having multiple work trees checked out on the same ref
could be problematic.
Is that just what git-new-workdir is for? (It seems to be
undocumented so it's hard to tell.) And what about this
.gitlink/.gitfile stuff I've heard about? Could I use that to have
multiple work trees share the same .git folder?
Thanks,
Avery
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-31 21:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080731210307.GF25138@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> > for strictly local fetch. If your SSH overhead is ~300 ms this is
> > only a ~700 ms real time for `git fetch origin`, not 5100 ms.
> >
> > Is your git-fetch a shell script? Or a compiled binary? The port
> > into C made it go _much_ faster, even though it is still a naive
> > O(N^2) matching algorithm. Yea, we still should fix that, but I
> > think an upgrade to 1.5.4 or later would make the client side
> > improve consideribly.
>
> ah, it is a shell script indeed! I'll upgrade to latest.
on another box, with 1.5.4, i have:
dione:~/tip> time git fetch origin
real 0m0.481s
user 0m0.136s
sys 0m0.060s
dione:~/tip> time ./tip-fetch
b714d1a257cca93ba6422ca3276ac80a2cde2b59
b714d1a257cca93ba6422ca3276ac80a2cde2b59
real 0m0.273s
user 0m0.012s
sys 0m0.020s
that's a 2.66 GHz core2 quad, i.e. a pretty fast box too. As you can see
most time spent in the tip-fetch case was waiting for the network. So
there's about 200 msecs of extra CPU cost on the local side. On a CPU
1-2 generations older that could be up to 1000 msecs or more.
In any case, performance has improved significantly with the C version!
(I'll still use tip-fetch to squeeze out the last bit of performance,
but it's quite comparable now.)
Sorry that i didnt notice that titan had 1.5.2 - i almost never notice
it when i switch between stable git versions. (you guys are doing a
really good job on compatibility)
Ingo
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-07-31 21:13 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <20080731205400.GA7911@atjola.homenet>
On Thu, 31 Jul 2008, Björn Steinbrink wrote:
> >
> > So literally, if you do
> >
> > git clone <cntral-repo-over-network> <local>
>
> Hum, I guess I'm just missing something and prepare to get flamed, but
> wouldn't you want that one to be bare? Otherwise, the other clones won't
> see all of the original repo's branches, right?
Making it bare might be a good idea for other reasons too (it makes it
much more obvious that it's a "local clone" and is somehow special). But
it's really a matter of taste - and the project - exactly how you do it.
For example, the kernel only has a single master branch in the top repo,
so there it really doesn't matter, and yes, I'm more kernel-oriented than
anything else, of course.
But I don't think it's exactly wrong to have the initial clone be a real
repository that you do work in. Quite often the history really is the
_bulk_ of the database by far (at least with projects that have big enough
repositories for this to even matter in the first place!), and as long as
you just download that once and share that thing, you're already ahead of
the game and the rest is really just details.
> Maybe even better:
>
> mkdir local-mirror
> cd local-mirror
> git --bare init
> git remote add -f --mirror origin <central-repo-over-network>
>
> A cronjob (or whatever) could keep the local mirror up-to-date and the
> other repos can fetch from there.
Heh. You can certainly do it many ways. I suspect the _easiest_ model is
actually to do one single local repo that is special (and perhaps bare),
and then you can clone all the other ones with
git clone --reference <local-reference> <remote> <new-local>
because that will automatically set up the new local repo to have the
local reference as an alternates thing, and will avoid downloading
unnecessary stuff.
So my point about the eleven repos was not that it's the best way to do
one remote clone and then eleven local ones - my point was that even if
you do that _stupid_ thing, you'd have seen sharing without even knowing
what you really did.
If you want to explicitly share, I think the local bare reference and
using "git clone --reference" is the best way. It sets up a special
link-file (it's just a text-file that git knows about, so it should work
fine under Windows too - no need for filesystem support) in
.git/objects/info/alternates.
IOW, git-clone --reference works like "git clone -s", but does so with one
special local database, while allowing you to clone from anywhere. Very
convenient.
And no, I don't think we document all these "tricks" very well. Partly
because people are _already_ complaining about how git can do so many
things ;) But partly because if you don't know what you're doing, the
"tricks" are often things you really need to understand, and can be a bit
dangerous otherwise.
For example, the "git clone -s" (or --reference) thing is *very* useful,
but one result of other repositories then sharing a database with the
reference one is that suddenly the reference repo is very special. You
must not remove it (obviously!), but you also must not rebase it and prune
it etc.
So all the normal git workflows are at least designed to be _safe_ even in
the absense of people not knowing what they are doing. The duplication may
be using harddisk space, but
- quite often the checkout is actually an even bigger issue, and the git
repo is small enough that lots of people don't really worry.
- duplicating the repo also means that you cannot _possibly_ screw up
other people/repos and does give you a kind of backup (even if
same-disk backups are obviously of dubious use: they shouldn't be your
_primary_ backup, but having multiple copies on a single disk still
protects against a _lot_ of problems)
so... It's a trade-off.
Linus
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-31 21:19 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080731211141.GA1159@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
>
> on another box, with 1.5.4, i have:
>
> dione:~/tip> time git fetch origin
>
> real 0m0.481s
> user 0m0.136s
> sys 0m0.060s
>
> dione:~/tip> time ./tip-fetch
> b714d1a257cca93ba6422ca3276ac80a2cde2b59
> b714d1a257cca93ba6422ca3276ac80a2cde2b59
>
> real 0m0.273s
> user 0m0.012s
> sys 0m0.020s
>
> that's a 2.66 GHz core2 quad, i.e. a pretty fast box too. As you can see
> most time spent in the tip-fetch case was waiting for the network. So
> there's about 200 msecs of extra CPU cost on the local side.
Yea. My testing last night was suggesting about 1/2 of that 200
ms is on the client, and the other 200 ms is on the server side
of the connection. That matches up somewhat with your test above,
where git-fetch used about 100 ms more user time on the client side
than your tip-fetch shell script.
I have no clue where the bottleneck is, I didn't get that far before
I realized you must have been running a shell script based git-fetch
to be seeing the performance you were.
Maybe 1.6.1 or .2 we can try to squeeze fetch to run faster.
Its far too late for 1.6.0.
> Sorry that i didnt notice that titan had 1.5.2 - i almost never notice
> it when i switch between stable git versions. (you guys are doing a
> really good job on compatibility)
Yea, its easy to not realize your git isn't giving you the latest
and greatest toys. ;-)
--
Shawn.
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Theodore Tso @ 2008-07-31 21:22 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Craig L. Ching, Linus Torvalds, sverre, Git Mailinglist
In-Reply-To: <BLU0-SMTP273E4683B41DB7E44122F0AE7C0@phx.gbl>
On Thu, Jul 31, 2008 at 04:57:24PM -0400, Sean Estabrooks wrote:
> > We find ourselves constantly having to shift gears and work on other
> > things in the middle of whatever it is we're currently working on. For
> > instance, in the scenario above, A might be branch that contains a
> > feature going into our next release. B might be a bugfix and takes
> > priority over A, so you have to leave A as-is and start work on B. When
> > I come back to work on A, I have to rebuild A to continue working, and
> > that's just too expensive for us. So we use the monotone-like
> > new-workdir which allows us to save those build artifacts.
>
> A decent build system will only compile the source files that actually
> changed when switching branches. Couple that with a compiler cache
> (such as ccache) and switching between branches in the kernel or git
> project usually isn't prohibitively time consuming.
That being said, if the bugfix is on a "maint" branch, and one of the
things that has changed is a header file that forces most of the
project to be recompiled, a separate work directory may be more
convenient. Of course, a separate work directory (whether created
using "git clone -s" or "git-new-workdir" means more disk space and it
means greater use of the page cache or a slowdown while the different
sets of sources get paged in and out. Of course, you could hack
git-work-dir to use cp -rl to initially copy the working directory
using hard links, and then when the new branch is checked out, if most
of the files haven't changed, the files in the working directory could
be shared too. A lot depends on how much you want to squeeze the last
bit of hard drive and speed optimization, and how big your project is.
- Ted
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-07-31 21:31 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: git
In-Reply-To: <4891B872.3040707@panasas.com>
Excellent idea; thank you!
> The practice of avoiding C++ keywords from public C headers is
> very welcome. You should send a patch and try to push it.
>
> That said the problem can be easily avoided.
>
> Produce a C file and header that defines some stable API to your
> GUI application, that does not expose any git internal headers.
> Then compile that, say git_api.c, with C compiler in Makefile
> and extern "C" link that file to your C++ application. This will
> completely insulate you from any git code.
>
> This could also solve the other problem of API changing, only
> the git_api.c need change, your outer GUI code stays the same.
>
> And if you do all that maybe you can submit it for inclusion
> as a: somewhat stable high-level library, for developers.
> Ala git-dev
>
> Cheers
> Boaz
>
>
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Martin Langhoff @ 2008-07-31 21:43 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Linus Torvalds, Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <20080731205400.GA7911@atjola.homenet>
On Fri, Aug 1, 2008 at 8:54 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
>> So literally, if you do
>>
>> git clone <cntral-repo-over-network> <local>
>
> Hum, I guess I'm just missing something and prepare to get flamed, but
> wouldn't you want that one to be bare? Otherwise, the other clones won't
> see all of the original repo's branches, right?
Yes, that's why
git clone --reference /path/to/fat/checkout/.git/ <central-repo>
is far better. Each "thin" checkout sees the central repo normally,
but they borrow the object store from the referenced local "fat"
checkout.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-07-31 21:44 UTC (permalink / raw)
To: sverre; +Cc: Dmitry Potapov, git
In-Reply-To: <bd6139dc0807311127j57d9ab5ckd6acf16d17621614@mail.gmail.com>
On Thu, Jul 31, 2008 at 11:27 AM, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 31, 2008 at 13:10, cte <cestreich@gmail.com> wrote:
>> I'm not worried about the interfaces changing; the gui is tied to a
>> particular version of git, and I will update the code that calls into
>> libgit I pull new changes from the mainline into my local clone.
>
> You should be ;). Unless you are planning to learn a lot of C very
> fast, you should be worried about the interfaces changing. That is, if
> you want your GUI to be able to stay up to date with the current git
> version.
That is the plan.
>> who's to say that the output of the various commands won't change
>> formats with future releases of git?
>
> Junio is to say. Plumbing output format is git's API.
Using output from the command line utilities as an API has its own set
of problems. For instance, check out some of the difficulties that
gitk and qgit have had to deal with:
http://kerneltrap.org/mailarchive/git/2007/11/2/379067. Digging into
the git internals and reusing its core functions will always be more
powerful and flexible than parsing command line output. Of course, it
is not always easy; git wasn't written to be easily compiled into a
library and reused (graceful error handling and memory management are
problematic). But I think the right thing to do is to work towards
making the awesome git internals easier to use for other developers so
great tools can continue to be built on top of git.
>> There is no correct solution if
>> you are worried about forward compatibility, unless a well defined API
>> is created (which would be sweet btw, but is probably not a priority).
>
> There is, use the plumbing, forward compatibility is 95% assured. With
> the exception of major releases, for which any plumbing
> output/behavior changes will be announced in the changelog, usually
> including an explanation on how to change your code to match.
95% assured != correct, IMO :)
> In short, use the forc-... errr, plumbing ;).
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* "remote add -f --mirror" fails when the stash is non-empty
From: Björn Steinbrink @ 2008-07-31 21:50 UTC (permalink / raw)
To: git
Hi,
when there are stashed changes in a repo, creating a mirror with "remote
add -f --mirror" fails, because it is missing the objects that are on
the stash.
$ git remote add -f --mirror or ~/src/git
Updating or
remote: Counting objects: 80150, done.
remote: Compressing objects: 100% (21254/21254), done.
remote: Total 80150 (delta 57481), reused 80146 (delta 57477)
Receiving objects: 100% (80150/80150), 21.21 MiB | 16028 KiB/s, done.
Resolving deltas: 100% (57481/57481), done.
From /home/doener/src/git
* [new branch] master -> master
* [new branch] rebase -> rebase
* [new branch] origin/HEAD -> origin/HEAD
* [new branch] origin/html -> origin/html
* [new branch] origin/maint -> origin/maint
* [new branch] origin/man -> origin/man
* [new branch] origin/master -> origin/master
* [new branch] origin/next -> origin/next
* [new branch] origin/pu -> origin/pu
* [new branch] origin/todo -> origin/todo
error: unable to find 9e5c2066d7d2bdca937a11b45a7ed8354c637bc9
fatal: object 9e5c2066d7d2bdca937a11b45a7ed8354c637bc9 not found
error: Could not fetch or
In ~/src/git:
$ git rev-parse stash
9e5c2066d7d2bdca937a11b45a7ed8354c637bc9
No idea if that is a recent breakage, as I learned about the --mirror
option recently and most of the time my stash is empty anyway.
Björn
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-07-31 21:40 UTC (permalink / raw)
To: Craig L. Ching; +Cc: sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
On Thu, 31 Jul 2008, Linus Torvalds wrote:
>
> Sure, if you want to keep the build tree around, you would probably not
> use branches.
Side note: it's often faster to recompile, if your project has a good
build system.
For example, for the kernel, I can literally rebuild my whole kernel
(which is just what I use on _that_ machine) in about 16 seconds. This is
_not_ using ccache or anything else - it's rebuilding the whole tree with
-j16.
It turns out that using multiple build trees would actually slow things
down, because then the source code wouldn't fit in memory any more. If I
have to actually read the source code from the disk, my nice 16-second
compile goes up to a minute or more.
Now, the thing you should take away from this is:
- kernel people have cool toys, and CPU's that are faster than what you
have. Nyaah, nyaah.
- disk is slow. REALLY slow. If you can share most of a single source
tree and thus keep it in memory, you're ahead.
- even large projects can have a fast build cycle if your build chain
doesn't suck. The kernel is larger than most, but a _lot_ of build
systems don't parallelize or use horribly inefficient tools, so they
take much longer to build.
The last part is the thing that people often stumble on. For example, I
can literally compile the kernel a hell of a lot faster than I can do
"make doc" on the git tree! Even just trying a "make -j16" when building
the git documentation is really really really painful. I suspect I'd need
a ton more memory for that horror.
So if your workflow involves xml (I think the doc build for git is all
xsltproc - along with asciidoc written in python or something), you're
screwed. But in the kernel we've actually cared pretty deeply about build
times, and as a result it's actually very pleasant to switch branches and
just rebuild. Even if some core header file has changed, it's _still_ ok
if you've got enough CPU.
(I just tested - I can do a "make doc" for git in just under a minute from
a clean tree. Ouch. That really is three times longer than my kernel
build - as long as I brought the kernel and compiler into memory first ;)
Linus
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Sverre Rabbelier @ 2008-07-31 21:51 UTC (permalink / raw)
To: cte; +Cc: Dmitry Potapov, git
In-Reply-To: <ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com>
On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
> Using output from the command line utilities as an API has its own set
> of problems. For instance, check out some of the difficulties that
> gitk and qgit have had to deal with:
> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
I beg to differ. If I skimmed the topic correctly, the problems there
were not related to having to parse git's output, but due to the fact
that '--topo-order' is a post-processing operation, which takes long.
Do read the recent discussion between Linus and Roman about that.
> Digging into
> the git internals and reusing its core functions will always be more
> powerful and flexible than parsing command line output.
Sure, but is it worth it? What do you need in your GUI that you cannot
get from the plumbing?
> Of course, it
> is not always easy; git wasn't written to be easily compiled into a
> library and reused (graceful error handling and memory management are
> problematic). But I think the right thing to do is to work towards
> making the awesome git internals easier to use for other developers so
> great tools can continue to be built on top of git.
I do agree with that, libification of git would be really nice.
Especially since that'd mean that integrating it into other languages
(by means of wrappers), such as Python or Ruby, becomes a lot easier.
>> There is, use the plumbing, forward compatibility is 95% assured. With
>> the exception of major releases, for which any plumbing
>> output/behavior changes will be announced in the changelog, usually
>> including an explanation on how to change your code to match.
>
> 95% assured != correct, IMO :)
Why not? Junio has a very good reputation of keeping git backwards
compatible. The 95% is of course not an actual figure but an
expression meant to indicate "statement is true, minus a few rare case
exceptions".
>> In short, use the forc-... errr, plumbing ;).
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>>
It's ok to remove text that you do not respond to, including signatures :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Shawn O. Pearce @ 2008-07-31 21:58 UTC (permalink / raw)
To: sverre; +Cc: cte, Dmitry Potapov, git
In-Reply-To: <bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com>
Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
> > Using output from the command line utilities as an API has its own set
> > of problems. For instance, check out some of the difficulties that
> > gitk and qgit have had to deal with:
> > http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
>
> I beg to differ. If I skimmed the topic correctly, the problems there
> were not related to having to parse git's output, but due to the fact
> that '--topo-order' is a post-processing operation, which takes long.
> Do read the recent discussion between Linus and Roman about that.
And actually if you try to use topo-order internally in C you still
have to wait for the post-processing. Which is going to cause your
UI to lock up because it is single-threaded as both Git and your UI
toolkit are probably single threaded. At least by forking out to
git-rev-list your UI can respond while the computation is happening
in a background process.
> Especially since that'd mean that integrating it into other languages
> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
I'm going to be shot for saying this, but both Python and Ruby
have implementations that run on the JVM. So does Git. Want
to use Git and Python? Use JGit and Jython. :)
> >> There is, use the plumbing, forward compatibility is 95% assured. With
> >> the exception of major releases, for which any plumbing
> >> output/behavior changes will be announced in the changelog, usually
> >> including an explanation on how to change your code to match.
> >
> > 95% assured != correct, IMO :)
>
> Why not? Junio has a very good reputation of keeping git backwards
> compatible. The 95% is of course not an actual figure but an
> expression meant to indicate "statement is true, minus a few rare case
> exceptions".
Too many people have scripts based upon plumbing to make incompatible
changes. We'd have all of our users screaming. Remember many Git
users are programmers themselves, they will make small home-grown
scripts based upon Git plumbing to simplify their workflow and
everyday tasks. They use plumbing precisely because they can trust
it won't change or break on them.
--
Shawn.
^ permalink raw reply
* [PATCH RFC] Do not override LESS
From: Anders Melchiorsen @ 2008-07-31 22:00 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen
Passing options to "less" with the LESS environment variable can
interfere with existing environment variables. There are at least two
problems, as the following examples show:
1. Alice is using git with colors. Now she decides to set LESS=i for
some reason. Suddenly, git displays codes in place of colors. Alice
likes codes, but she liked colors better!
2. Bob sets GIT_PAGER="less -RS", but does not set LESS. Git sets
LESS=FRSX before calling $GIT_PAGER. Now Bob wonders why his pager is
not always paging, when he explicitly tried to clear the F option.
Maybe Mallory has been messing with something?
By passing the options on the command line instead, both of these
situations are handled.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
There are at least two issues with this change:
A. Now /bin/sh will be executed all the time with the default pager. If
this is perceived as a performance problem, I can make a special case.
B. This will make existing setups with PAGER="less" behave differently.
They can, of course, be fixed with GIT_PAGER="less -FRSX".
I think that neither 1, 2, A or B are big problems. Nevertheless, I think
this change makes things "more correct", so I hereby offer it for discussion.
diff --git a/pager.c b/pager.c
index 6b5c9e4..232d6ed 100644
--- a/pager.c
+++ b/pager.c
@@ -60,7 +60,7 @@ void setup_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = "less -FRSX";
else if (!*pager || !strcmp(pager, "cat"))
return;
@@ -90,7 +90,6 @@ void setup_pager(void)
close(fd[0]);
close(fd[1]);
- setenv("LESS", "FRSX", 0);
run_pager(pager);
die("unable to execute pager '%s'", pager);
exit(255);
--
1.5.6.4
^ permalink raw reply related
* [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vhca6zcuy.fsf@gitster.siamese.dyndns.org>
This one makes it incremental. It is not relative to v2 but on top of
'master'.
The idea and the logic to find what parents to rewrite is the same as the
previous one, but this one works incrementally as much as possible. When
you have this topology, where commits with capital letters are the ones
that change the paths you are interested in:
A---M---o---C---D---o
/ /
---o---B
(1) we can tell that the rightmost one 'o' is not we want to show, without
digging any further than D;
(2) we can show D after inspecting C without digging any further. C is
the sole parent of D, and C itself is an interesting one, so D's
parent will stay to be C and not its ancestor.
(3) before showing C, we need to know what the rewritten parent of it
would be; we need to dig down to M and notice that it has two parents
that simplify to a different commit (both A and B touch the path we
are interested in), so M simplifies to itself and it becomes the
parent of C. IOW, we need to dig no further than A and B in order to
show C.
$ time sh -c 'git log --pretty=oneline --abbrev-commit \
--simplify-merges --parents \
-- kernel/printk.c | head -n 1'
5dfb66b... 1d9b9f6... c9272c4... Merge branch 'for-linus' of git://git.o-hand.com/linux-mfd
real 0m0.344s
user 0m0.324s
sys 0m0.020s
The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
it is much more expensive than the non-incremental one (v2), and about
three times more expensive than non-limiting --full-history for explaining
the history of kernel/printk.c. There must be opportunity to further
optimize this, but I'd stop here for now, as you keep saying this is hard,
and if I continue thinking about this any longer my head would explode ;-)
---
revision.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
revision.h | 1 +
2 files changed, 103 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 3897fec..9554a70 100644
--- a/revision.c
+++ b/revision.c
@@ -1045,6 +1045,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--topo-order")) {
revs->lifo = 1;
revs->topo_order = 1;
+ } else if (!strcmp(arg, "--simplify-merges")) {
+ revs->simplify_merges = 1;
+ revs->rewrite_parents = 1;
+ revs->simplify_history = 0;
} else if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
@@ -1450,9 +1454,10 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
}
}
-static void remove_duplicate_parents(struct commit *commit)
+static int remove_duplicate_parents(struct commit *commit)
{
struct commit_list **pp, *p;
+ int surviving_parents;
/* Examine existing parents while marking ones we have seen... */
pp = &commit->parents;
@@ -1465,9 +1470,13 @@ static void remove_duplicate_parents(struct commit *commit)
parent->object.flags |= TMP_MARK;
pp = &p->next;
}
- /* ... and clear the temporary mark */
- for (p = commit->parents; p; p = p->next)
+ /* count them while clearing the temporary mark */
+ surviving_parents = 0;
+ for (p = commit->parents; p; p = p->next) {
p->item->object.flags &= ~TMP_MARK;
+ surviving_parents++;
+ }
+ return surviving_parents;
}
static int rewrite_parents(struct rev_info *revs, struct commit *commit)
@@ -1536,6 +1545,89 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
return commit_show;
}
+static void simplify_merges(struct rev_info *revs, struct commit *commit)
+{
+ struct commit_list *work = NULL;
+
+ commit_list_insert(commit, &work);
+ while (!commit->util && work) {
+ struct commit *c;
+ struct commit_list *p;
+ int cnt;
+
+ c = pop_commit(&work);
+ if (c->util)
+ continue;
+ if ((c->object.flags & UNINTERESTING) || !c->parents) {
+ c->util = c;
+ continue;
+ }
+
+ /*
+ * Do we know what commit all of the parents of this
+ * should be rewritten to? Otherwise we are not ready
+ * to rewrite this one yet.
+ */
+ for (cnt = 0, p = c->parents; p; p = p->next) {
+ if (!p->item->util) {
+ if (!cnt)
+ commit_list_insert(c, &work);
+ commit_list_insert(p->item, &work);
+ cnt++;
+ }
+ }
+ if (cnt)
+ continue;
+
+ /*
+ * Rewrite the list of parents.
+ */
+ for (p = c->parents; p; p = p->next)
+ p->item = p->item->util;
+ cnt = remove_duplicate_parents(c);
+
+ /*
+ * It is possible that this is a merge and one side
+ * branch does not have any commit that touches the
+ * given paths; in such a case, the immediate parents
+ * will be rewritten to different commits if we do not
+ * reduce such a false merge of fast-forward parents.
+ *
+ * o----X X: the commit we are looking at;
+ * / / o: a commit that touches the paths;
+ * ---o----'
+ *
+ * Further reduce the parents by removing redundant
+ * parents.
+ */
+ if (1 < cnt) {
+ struct commit_list *h = reduce_heads(c->parents);
+ cnt = commit_list_count(h);
+ free_commit_list(c->parents);
+ c->parents = h;
+ }
+
+ /*
+ * A commit simplifies to itself if it is a root, if
+ * it is UNINTERESTING, if it touches the given paths,
+ * or if it is a merge and its parents simplifies to
+ * more than one commits (the first two cases are
+ * already handled at the beginning of this function).
+ *
+ * Otherwise, it simplifies to what its sole parent
+ * simplifies to.
+ */
+ if (!cnt ||
+ (c->object.flags & UNINTERESTING) ||
+ !(c->object.flags & TREESAME) ||
+ (1 < cnt))
+ c->util = c;
+ else
+ c->util = c->parents->item->util;
+ }
+ free_commit_list(work);
+}
+
static struct commit *get_revision_1(struct rev_info *revs)
{
if (!revs->commits)
@@ -1570,8 +1662,14 @@ static struct commit *get_revision_1(struct rev_info *revs)
case commit_error:
return NULL;
default:
- return commit;
+ break;
+ }
+ if (revs->simplify_merges && !commit->util) {
+ simplify_merges(revs, commit);
+ if (commit->util != commit)
+ continue;
}
+ return commit;
} while (revs->commits);
return NULL;
}
diff --git a/revision.h b/revision.h
index f64e8ce..dfa06b5 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
simplify_history:1,
lifo:1,
topo_order:1,
+ simplify_merges:1,
tag_objects:1,
tree_objects:1,
blob_objects:1,
^ permalink raw reply related
* Re: linking libgit.a in C++ projects
From: Sverre Rabbelier @ 2008-07-31 22:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: cte, Dmitry Potapov, git
In-Reply-To: <20080731215818.GD24631@spearce.org>
On Thu, Jul 31, 2008 at 23:58, Shawn O. Pearce <spearce@spearce.org> wrote:
> And actually if you try to use topo-order internally in C you still
> have to wait for the post-processing.....
Aye, that's what I was reffering to, thanks for clarifying :).
>> Especially since that'd mean that integrating it into other languages
>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
>
> I'm going to be shot for saying this, but both Python and Ruby
> have implementations that run on the JVM. So does Git. Want
> to use Git and Python? Use JGit and Jython. :)
Heheh, nice plug :P, but thanks but no thanks. I'd rather have
something more native than "JGit + Jython", two levels of 'emulation'
can't be good!
> Too many people have scripts based upon plumbing to make incompatible
> changes.....
Exactly! :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Dmitry Potapov @ 2008-07-31 22:23 UTC (permalink / raw)
To: cte; +Cc: sverre, git
In-Reply-To: <ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com>
On Fri, Aug 1, 2008 at 1:44 AM, cte <cestreich@gmail.com> wrote:
>
> Using output from the command line utilities as an API has its own set
> of problems. For instance, check out some of the difficulties that
> gitk and qgit have had to deal with:
> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
There is no problem with parsing. If you want to receive the output
in the specific order, Git has to read everything first, and that
is *slow*. So, --topo-order is convenient but slow, and it is slow
not because it is piping data, but because it takes some time to
read the whole history.
> Digging into
> the git internals and reusing its core functions will always be more
> powerful and flexible than parsing command line output.
"Flexible" is not a synonym of the word "useful". For instance, using
core functions will not help you to overcome the aforementioned problem.
Drawing a graph is NOT what git core functions about. You have to do
that in your GUI, and to do that when revisions are given to you in
arbitrary order is not easy. Yet, it is something what good GUI should
be capable to handle, because otherwise the response time will be bad.
Dmitry
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-07-31 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vabfxyacx.fsf_-_@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
> it is much more expensive than the non-incremental one (v2), and about
> three times more expensive than non-limiting --full-history for explaining
> the history of kernel/printk.c.
Hmm? Why is that, exactly? Does it walk over the same commit over and over
and over again or something?
Can you combine --simplify-merges and --topo-order to get a fast version
again (since --topo-order will force a non-incrmental walk)?
I have this suspicion (gut feel only, not anything else to back it up)
that for any complex global history, you'll always end up having a lot of
merges "live" and have a hard time getting a lot of early output.
That may be why you get a fairly big delay before even the first commit:
> $ time sh -c 'git log --pretty=oneline --abbrev-commit \
> --simplify-merges --parents \
> -- kernel/printk.c | head -n 1'
> 5dfb66b... 1d9b9f6... c9272c4... Merge branch 'for-linus' of git://git.o-hand.com/linux-mfd
>
> real 0m0.344s
> user 0m0.324s
> sys 0m0.020s
>From your previous email:
$ git rev-list --parents --full-history --topo-order HEAD -- kernel/printk.c
3.75user 0.47system 0:04.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
so that's less than 10% of the whole time, but it's still a _lot_ slower
than the
$ git rev-list --parents --full-history HEAD -- kernel/printk.c | head -n 200
0.16user 0.02system 0:00.18elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k
and that was the first 200 commits, not just the first one. I bet you got
the first one in about a tenth of that time - so I'm guessing 0.016s (also
based on my own testing - it's below 0.01s here, but I'm willing to bet my
machine is faster than yours is).
So getting the first one with "--simplify-merges" was really a _lot_
slower.
That said, I'm a huge beliver in the incremental approach - it just looks
like this is potentially "just barely incremental" in practice.
Of course, with a more linear history than the kernel, your approach
probably works better.
Linus
^ permalink raw reply
* [PATCH] git svn: should not display zombie externals
From: Eddy Petrișor @ 2008-07-31 22:33 UTC (permalink / raw)
To: git
during the history of a repo a svn:external could be added and later
removed; such externals shouldn't be displayed since only the current
state is relevant
I have encountered the broken behaviour on a git-svn repo with the svn
origin a repo served via https (git 1:1.5.6-1~bpo40+1 from Debian Etch
backports.) I hope this bug doesn't have to do with the svn repo being
served via https.
Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
---
t/t9101-git-svn-props.sh | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index f420796..e5ab748 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -211,7 +211,28 @@ EOF
test_expect_success 'test proplist' "
git-svn proplist . | cmp - prop.expect &&
- git-svn proplist nested/directory/.keep | cmp - prop2.expect
+ git-svn proplist nested/directory/.keep | cmp - prop2.expect &&
+ cd ..
+ "
+
+test_expect_success 'show external' "
+ cd test_wc &&
+ svn propset svn:externals 'zombie file:///fake/external' . &&
+ svn ci -m 'added a fake svn:external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q 'zombie'
+ "
+
+test_expect_success 'remove external' "
+ cd test_wc &&
+ svn propdel svn:externals . &&
+ svn ci -m 'deleted the fake external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q -v 'zombie'
"
test_done
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH v2] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-07-31 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vd4kuzcst.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> If you look at the output from the "kernel/printk.c" with this patch, you
> would notice that there still are somewhat meaningless merges shown in the
> history (e.g. scroll down to 185a257f2f73bcd89050ad02da5bedbc28fc43fa).
They're not really meaningless.
Yes, they are pointless for the end result, but once you start showing
that whole pointless branch they very much are needed for a complete view
of the "shape" of history. The merges are real points on that branch where
printk changed because it got updates from mainlines.
So either you should have the full simplification (which only shows stuff
that is really meaningful for the end result), or you need for those
"pointless" merges to remain (because you show the changes that happened
on side branches).
I obviously believe that the full simplification is what you most often
want, but the --post-simplify thing does make sense.
(And yes, I agree that the name should be something else, and that
--simplify-merges makes more sense. The "post-simplify" thing is an
implementation issue, and doesn't describe what the effect is. And with
your incremental one, even that isn't true).
Linus
^ 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