* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.
From: Jan Hudec @ 2007-09-05 18:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Kakurin, Johannes Schindelin, Petr Baudis,
Git Mailing List
In-Reply-To: <7vk5r5jzpn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]
On Wed, Sep 05, 2007 at 01:14:44 -0700, Junio C Hamano wrote:
> "Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
>
> > I assert that since index does not have .gitattributes the one from
> > local directory should not be used.
> >
> > Think about dedicated build machine scenario: I have a machine that
> > always does sync + build. After every sync the local directory should
> > always be identical to what-was-committed.
>
> Thinking about the reason _why_ .gitattributes may be updated,
> one would notice that it is because somebody did this command
> sequence:
>
> git checkout ;# now work tree is clean
> edit .gitattributes ;# modify the attributes of a file
> edit file ;# edit the file attributes talks about
> git add file ;# this can be affected by .gitattributes
> git add .gitattributes ;# this is changed in the same commit
> git commit
>
> Now, should we always take .gitattributes from the index?
Yes, they should:
$ git checkout
$ edit .gitattributes
$ edit file
$ git add file
$ git commit ;# this does NOT have the changes to .gitattributes
the above case is a user error that can (at some cost) be detected:
$ git checkout
$ edit .gitattributes
$ edit file
$ git add file
$ git add .gitattributes
Warning! Changes to gitattributes affects handling of files scheduled for
commit. Please add following files again before commit:
file
$
It would be possible to special-case .gitattributes in add to:
- do diff between the old and new value of .gitattributes in index,
- list files changed in index compared to HEAD,
- match each of them to all patterns in the diff,
- if any matches, print the warning and list of matches.
It might be even possible to actually inspect the changes and apply those
that can be automatically (and not ask user to re-add), but some filters
loose information, so user interaction is needed to add good version.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Nix @ 2007-09-05 18:28 UTC (permalink / raw)
To: Steven Grimm; +Cc: Govind Salinas, Linus Torvalds, Git Mailing List
In-Reply-To: <46DEE8E8.2000801@midwinter.com>
On 5 Sep 2007, Steven Grimm stated:
> Govind Salinas wrote:
>> This is one reason why I really think that gc should be *plumbing*
>> and *not* porcelain.
>
> That's a good way to think of it IMO. It's a low-level operation
> (albeit one that encapsulates other, lower-level ones) that tells git
> to rearrange its internal data structures. It is not something that
> has any user-visible effect.
It certainly has a sysadmin-visible effect. Repack a couple of big git
repositories and that's a backup tape gone if you do incremental
backups: and you can't *not* back up the pack files, even though a lot
of the state in them is recoverable from elsewhere on the net: the stuff
which is not recoverable is tangled up with the stuff which is.
(of course the solution here was .keep files. I cheered when they were
introduced and started rolling git out everywhere I could. There's just
one last vast repository maintained by a horrible shell script layered
atop SCCS which I have to find some way to convert...)
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Nix @ 2007-09-05 18:22 UTC (permalink / raw)
To: Steven Grimm; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <46DEF1FA.4050500@midwinter.com>
On 5 Sep 2007, Steven Grimm stated:
> Nix wrote:
>> Indeed. I repack all our git trees in the middle of the night, and our
>> incremental backup script drops .keep files corresponding to every
>> existing pack before running the backup.
>>
>> This is probably a good job for cron :)
>
> If you are setting up cron jobs to repack multiple git trees, you are
> not the kind of novice or casual git user who this proposal would
> primarily be aimed at.
True enough: but the point is that it was only about three lines of code
(a locate and git-gc pipeline). We could just put that in the
documentation...
... which people then won't read. Oh well. Sorry for the mindless
optimism.
> git-gc can leave behind a "last completed" timestamp and we can
> suppress the check for excess loose objects until some minimum amount
> of time has passed since last git-gc. If that amount is greater than
> the interval between your cron jobs, you won't even get any
> (measurable) overhead from the detection to see if the warning is
> needed.
I personally wonder if git-gc shouldn't use a proportional scheme, so
that only some packs get repacked, maybe the smallest ones (and when
they grow to the same size as the next largest one, the two get repacked
into one). This has the singular advantage that you won't have to
carefully drop .keep files everywhere or have to worry about your git-gc
of 50K of loose objects suddenly deciding to repack 100Mb of packfiles
and taking ages.
It's probably not hard to implement, but I don't need it because I keep
everything packed anyway...
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Steven Grimm @ 2007-09-05 18:14 UTC (permalink / raw)
To: Nix; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <87odgh0zn6.fsf@hades.wkstn.nix>
Nix wrote:
> Indeed. I repack all our git trees in the middle of the night, and our
> incremental backup script drops .keep files corresponding to every
> existing pack before running the backup.
>
> This is probably a good job for cron :)
>
If you are setting up cron jobs to repack multiple git trees, you are
not the kind of novice or casual git user who this proposal would
primarily be aimed at.
But in any event, since you are doing that, your repos will never
accumulate a high enough percentage of loose objects (whatever the
threshold is) to trigger the warning and/or automatic launch. So you can
continue to operate as before, no difference in behavior, while people
who don't know how / want to set up cron jobs will have their
repositories cleaned too.
git-gc can leave behind a "last completed" timestamp and we can suppress
the check for excess loose objects until some minimum amount of time has
passed since last git-gc. If that amount is greater than the interval
between your cron jobs, you won't even get any (measurable) overhead
from the detection to see if the warning is needed.
-Steve
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Nix @ 2007-09-05 18:06 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git discussion list
In-Reply-To: <6E4416B2-FA7C-47C3-B5C6-9E94D8ABE17D@lrde.epita.fr>
On 5 Sep 2007, Benoit SIGOURE told this:
> The autoconf maintainers will be glade to hear about such legends or inaccurate things.
I know, and when I finally dig up my list (it's on an old CD somewhere)
I'll send it their way. (Disk crash -> lots of stuff still stuck on CDs
years after the fact... obviously I should have kept everything
significant in git instead so I just had to restore one packfile ;) )
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Jing Xue @ 2007-09-05 17:55 UTC (permalink / raw)
To: Carl Worth; +Cc: Govind Salinas, Linus Torvalds, Git Mailing List
In-Reply-To: <87ir6pc9n1.wl%cworth@cworth.org>
Quoting Carl Worth <cworth@cworth.org>:
> I don't think the warning message alone is a good fix. I think the
> people who would understand the warning and appreciate that they could
> then take care of repacking as convenient are the same people that
> already understand the repacking concept, and are likely already
> repacking occasionally, (so would likely never see the warning).
>
> But the problematic case is the user who knows nothing of the
> issue. And in that case, giving this warning isn't useful education,
> it's just forcing the user to learn more and do more work. "If git
> notices it has too many 'loose object' and 'git gc' would fix the
> problem, then why didn't it do that itself? And what the heck is a
> 'loose object' anyway?"
(my 2 cents as another ordinary new git user)
Hmm, not necessarily. That a system knows what the best action is
doesn't meant that _right now_ is the best time to take that action.
One subtle difference I think between git's gc and Java/python/etc.'s
gc is that in the latter case it is, at least metaphorically, a life
and death situation - if gc isn't run, the application will run out of
memory, where as in git, it's more of a performance degradation issue,
which, sort of, can wait.
On the issue of implementation awareness, a warning message saying
something along the lines of "your repository is getting slower. You
might want to consider running 'git gc', and remember to do that from
time to time." is not much different from "your file system is getting
slower. You might want to consider running <whatever-defrag-tool>, and
remember to do that from time to time."
Neither these messages nor the actions they propose _require_ users to
learn what "repacking", "loose object", or "file fragments" are about
before they can proceed.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Benoit SIGOURE @ 2007-09-05 17:54 UTC (permalink / raw)
To: Nix; +Cc: git discussion list
In-Reply-To: <87bqclngh6.fsf@hades.wkstn.nix>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Sep 2, 2007, at 7:07 PM, Nix wrote:
> On 2 Sep 2007, David Kastrup uttered the following:
>> As usual, <URL:info:autoconf#Limitations%20of%20Usual%20Tools>
>> (aka as
>> (info "(autoconf) Limitations of Usual Tools")
>> ) provides a real horror show of sed variants.
>
> A goodly number of things in that section of the Autoconf manual are
> passing on hints and ancient legends that may or may not be accurate:
> I've found a number of its descriptions of shell limitations to be
> downright wrong (applying to one build of one shell back in 1981 that
> was never shipped to anyone, that sort of thing).
>
> (Of course it's valuable, even if it *is* a compendium of legends. But
> confirming any of it is quite hard.)
The autoconf maintainers will be glade to hear about such legends or
inaccurate things.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Nix @ 2007-09-05 17:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <20070905074206.GA31750@artemis.corp>
On 5 Sep 2007, Pierre Habouzit said:
> I know I don't really answer the question, but the point I try to make
> is that yeah, some kind of automated way to run the gc is great, but I'm
> not sure that _git_ is the tool to automate that, because when *I* use
> git, I expect it to be just plain fast, and I don't want it to
> occasionally hang.
Indeed. I repack all our git trees in the middle of the night, and our
incremental backup script drops .keep files corresponding to every
existing pack before running the backup.
This is probably a good job for cron :)
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: J. Bruce Fields @ 2007-09-05 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
On Wed, Sep 05, 2007 at 12:09:27AM -0700, Linus Torvalds wrote:
> I personally repack everything way more often than is necessary, and I had
> kind of assumed that people did it that way, but I was apparently wrong.
> Comments?
Well, this may just prove I'm an idiot, but one of the reasons I rarely
run it is that I have trouble remembering exactly what it does; in
particular,
- does it prune anything that might be needed by a repo I
cloned with -s?
- is there anything that's unsafe to do while the git-gc is
running?
- what are the implications for http users if this is a public
repo?
- is git-gc enough on its own or should I be running something
more agressive ocassionally too?
No doubt they all have simple answers, which probably amount to "just
don't worry about it", and which I could have found in less time than
it'd take to write this email. But when I've got other work to do,
reading "man git-gc" is just enough effort for me to postpone the whole
thing to another day.
So, anyway, your message reminded me to run git-gc on my main working
repo. At which point one of my personal scripts immediately started
failing--it was assuming it could find any ref under .git/refs/, and I
hadn't realized (or maybe I had once, and I'd forgotten) that git-gc
packs refs by default now.
Bah. I don't know what the moral of that story is.
--b.
^ permalink raw reply
* Re: Git's database structure
From: Mike Hommey @ 2007-09-05 17:39 UTC (permalink / raw)
To: Jon Smirl
Cc: Julian Phillips, Andreas Ericsson, Theodore Tso, Junio C Hamano,
Git Mailing List
In-Reply-To: <9e4733910709050912i57ed7137o6abb02ee741d394b@mail.gmail.com>
On Wed, Sep 05, 2007 at 12:12:28PM -0400, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/5/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> > On Wed, 5 Sep 2007, Jon Smirl wrote:
> >
> > > On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
> > >> Jon Smirl wrote:
> > >>>
> > >>> The path name field needs to be moved back into the blobs to support
> > >>> alternative indexes. For example I want an index on the Signed-off-by
> > >>> field. I use this index to give me the SHAs for the blobs
> > >>> Signed-off-by a particular person. In the current design I have no way
> > >>> of recovering the path name for these blobs other than a brute force
> > >>> search following every path looking for the right SHA.
> > >>>
> > >>
> > >> Ah, there we go. A use-case at last :)
> >
> > But not a brilliant one. You sign off on commits not blobs. So you go
> > from the sign-off to paths, then to blobs. There is no need to go from
> > blob to path unless you deliberately introduce such a need.
>
> Use blame for an example. Blame has to crawl every commit to see if it
> touched the file. It keeps doing this until it figures out the last
> author for every line in the file. Worse case blame has to crawl every
> commit in the data store.
And why exactly would you need to change blobs to contain path for blame
to be faster ?
Or more generally, what, in the current way of git doing things,
prevents you from adding an index to $THE_DATA_YOU_LIKE, exactly ?
>From the very few use cases you've given, I see nothing preventing to
create an additional index from the data git currently uses.
Mike
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Steven Grimm @ 2007-09-05 17:35 UTC (permalink / raw)
To: Govind Salinas; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <69b0c0350709050947k5e32ba7fj38924a0968569d9a@mail.gmail.com>
Govind Salinas wrote:
> This is one reason why I really think that gc should be *plumbing*
> and *not* porcelain.
>
That's a good way to think of it IMO. It's a low-level operation (albeit
one that encapsulates other, lower-level ones) that tells git to
rearrange its internal data structures. It is not something that has any
user-visible effect. Every other porcelain-level git command *does
something* from the user's point of view. Running git-gc is basically a
no-op, which from the user's point of view makes it a waste of
keystrokes and an annoying distraction from focusing on the stuff
they're using git to help them build.
> The user should never have to trigger a gc, they should even be
> discouraged from doing so. That is how other gc systems are. Can you
> imagine if you had a Java app that had a button on it to do a gc?
> When should I push it? Should I wait till the system is getting slow
> or just start spamming the button whenever I'm bored? I know that
> Java/c#/py GC are different than git gc, but they fulfill the same
> basic purpose as git gc. IE to clean up unused items and free up
> resources. Git additionally may do some re-optimization, but that is
> not relevant to a user.
>
I'll play devil's advocate for a moment here, though, and say that, as
others have suggested in this thread, git could be made to tell you when
it's appropriate to run gc. So the "I don't know when to run it"
argument isn't a hard one to address.
With that in mind, here's what the message should look like IMO:
---
Your repository can be optimized for better performance and lower disk
usage.
Please run "git gc" to optimize it now, or run "git config gc.auto true"
to tell
git to automatically optimize it in the future (this will launch
processes in the
background.) For more information, "man git-gc".
---
And that "gc.auto" config option (just an arbitrary name, call it
something else if that's no good) actually has four settings:
warn (the default) - prints the warning message, at most once every N
minutes (we can determine a good value for N)
true - launches git-gc in the background as needed
false - suppresses the warning and the check that triggers the warning
foreground - launches git-gc in the foreground as needed (to make it
easier to abort)
I don't buy the "git gc takes too much memory to run in the background"
argument as a reason automatic git-gc is a bad idea. Many of us (me
included) work on machines with plenty of memory to launch a background
git-gc without hampering our development work, and/or on repositories
small enough that it doesn't eat that much memory in the first place.
And if you make it an option that the user has to enable, people on
low-memory machines can simply not enable it, end of problem.
One big problem with git-gc now is that it's not discoverable. Or
rather, the need for it isn't discoverable. So at the very least we
should print the warning, IMO -- and if we're already going to all the
trouble to determine whether or not git-gc needs to be run, it will
reduce the "why are you telling me to run something when you could just
do it for me, you stupid machine?" factor if there's an easily
discoverable way to just do it as needed.
-Steve
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Matthieu Moy @ 2007-09-05 17:31 UTC (permalink / raw)
To: Johan De Messemaeker
Cc: Martin Langhoff, Junio C Hamano, Steven Grimm, Linus Torvalds,
Git Mailing List
In-Reply-To: <D32A7C27-EAF5-4156-BE0E-99FE3D948AE8@wgaf.org>
Johan De Messemaeker <johan.demessemaeker@wgaf.org> writes:
>> Currently, AFAIK, that can only be done with a (trivial) script
>> external to git. I suppose this can easily be added to the core git
>> porcelain. Perhaps a "git gc --recursive" would do.
>>
>> It doesn't solve the problem, but makes it easier to solve it (git gc
>> --recursive in cron for example).
>
> I'm a git newb so I can be wrong here but ...
>
> Why --recursive? Why not use the submodule-information ?
all projects are not necessarily subprojects of each others.
I have ~/teaching/some-course/.git (well, almost) and ~/etc/.git which
are two unrelated projects, and to "git gc" both of them, I need
either a script, or two manual invocations.
(yes, I'm really talking about something trivial)
--
Matthieu
^ permalink raw reply
* Re: Git's database structure
From: Julian Phillips @ 2007-09-05 17:31 UTC (permalink / raw)
To: Jon Smirl
Cc: Andreas Ericsson, Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910709050912i57ed7137o6abb02ee741d394b@mail.gmail.com>
On Wed, 5 Sep 2007, Jon Smirl wrote:
> On 9/5/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> On Wed, 5 Sep 2007, Jon Smirl wrote:
>>
>>> On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
>>>> Jon Smirl wrote:
>>>>>
>>>>> The path name field needs to be moved back into the blobs to support
>>>>> alternative indexes. For example I want an index on the Signed-off-by
>>>>> field. I use this index to give me the SHAs for the blobs
>>>>> Signed-off-by a particular person. In the current design I have no way
>>>>> of recovering the path name for these blobs other than a brute force
>>>>> search following every path looking for the right SHA.
>>>>>
>>>>
>>>> Ah, there we go. A use-case at last :)
>>
>> But not a brilliant one. You sign off on commits not blobs. So you go
>> from the sign-off to paths, then to blobs. There is no need to go from
>> blob to path unless you deliberately introduce such a need.
>
> Use blame for an example. Blame has to crawl every commit to see if it
> touched the file. It keeps doing this until it figures out the last
> author for every line in the file. Worse case blame has to crawl every
> commit in the data store.
And this is advantaged by having the path in the blob how? The important
information here is knowing which commits touched the file - this
information is expensive in git because it is snapshot based. You have to
go back through all the commits looking for changes to the given path.
The information you might want to cache is which commits touched the file,
which you could do without changing the current data storage. Presumably
you are suggesting that such a cache would be cleaner with the filename in
the blob? Or do you think that it would somehow be faster to create? If
so, how?
--
Julian
---
Humor in the Court:
Q: (Showing man picture.) That's you?
A: Yes, sir.
Q: And you were present when the picture was taken, right?
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Matthieu Moy @ 2007-09-05 17:29 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: Lukas Sandström, Git Mailing List, Junio C Hamano
In-Reply-To: <1189004090.20311.12.camel@hinata.boston.redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:
>> Hi.
>>
>> This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c
>>
>> The patch doesn't pass all the tests in the testsuit yet, but I thought I'd
>> send it out so people can decide if they like how the code looks.
>>
>> I'm not sending a patch to add the library files at this time. I'll send
>> that patch when this patch is working.
>>
>> The changes required to make it pass the tests shouldn't be very large.
>
> Please, no. Let's not pull in a dependency for something as simple as a
> string library. How many distros have bstring pcakaged?
> The right version?
That's not a good argument. If dependancy is a problem, bsstring can
easily be distributed as part of git. It's really small, so it wont
make git bloated:
$ wc -l *.c *.h
82 bsafe.c
3462 bstest.c
1134 bstraux.c
2964 bstrlib.c
358 testaux.c
43 bsafe.h
112 bstraux.h
302 bstrlib.h
442 bstrwrap.h
8899 total
> Does it work on Windows?
The library is totally stand alone, portable (known to work with
gcc/g++, MSVC++, Intel C++, WATCOM C/C++, Turbo C, Borland C++, IBM's
native CC compiler on Windows, Linux and Mac OS X)
> We already have strbuf.c, lets just consolidate the string
> manipulation code already in git under that interface.
The right question is: what does git need. One way to consolidate
strbuf would be to simply
$ rm strbuf.{c,h}
$ unzip bsstring.zip
and if people decide that git needs a non-trivial string library,
writting/testing more code in strbuf.c would probably be more work
than just reading what bsstring code does to become familiar enough
with it to even be able to maintain it later.
If people decide that git needs a really trivial string library, then
a few improvements to stbuf.c can be good.
I'd argue in favor of the first option. C strings are horrible, and I
think doing something pleasant to use and safe is not completely
trivial. But I'm not a big contributor enough to really decide in
spite of others ;-).
--
Matthieu
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Carl Worth @ 2007-09-05 17:19 UTC (permalink / raw)
To: Govind Salinas; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <69b0c0350709050947k5e32ba7fj38924a0968569d9a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]
On Wed, 5 Sep 2007 11:47:45 -0500, "Govind Salinas" wrote:
> I know this goes against the general mood here (which seems to be
> against auto-gc) but I thought I would give my $.02 as a user of git.
I'll throw my opinion in here as well. I think git should
automatically do repacking by default, (once loose objects exceed some
threshold). There have several posts in this thread from people who
don't want auto-gc, but these same people should be able to avoid it,
and likely without changing habits. That's because:
* They're already in the habit of manually repacking every once in a
while, (or like, Linus, much more often than strictly necessary).
* They've already got cron jobs setup to do the repacking.
And one could augment this with an option to disable the repacking of
course.
And if you're really concerned about people that don't want this
getting it anyway, just determine some useful threshold and then
double it or so before it triggers automatic repacking, (so the
automatic repacking hits only us idiots that completely neglect it).
[Pardon me for continuing to quote in the original top-posted order,
but I like the flow here.]
On 9/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > James didn't seem to realize that the fact that he had apparently never
> > ever repacked his repository was a big deal.
I know it was surprising to you, Linus, but I'm glad you noticed
it. I've seen the same thing from many users. And git actually
discourages users from learning about repacking. If the user starts
with a small (or new) project, then everything performs well, and
there's no performance problem whatsoever.
So then the problems creep up gradually, and the user has no idea that
he should be doing anything different than he's always done. Instead
the user is left to just conclude that git's performance isn't scaling
well as the project grows. That's a bad conclusion of course, and it's
bad that git sets things up so the user reaches that conclusion.
Instead, git should just fix things up itself in this case.
> > I've been against automatic repacking, but that was really based on what
> > appears to be potentially a very wrong assumption, namely that people
> > would do the manual repack on their own. If it turns out that people don't
> > do it, maybe the right thing for git to do really is to at least notify
> > people when they have way too many pack-files and/or loose
> > objects.
I don't think the warning message alone is a good fix. I think the
people who would understand the warning and appreciate that they could
then take care of repacking as convenient are the same people that
already understand the repacking concept, and are likely already
repacking occasionally, (so would likely never see the warning).
But the problematic case is the user who knows nothing of the
issue. And in that case, giving this warning isn't useful education,
it's just forcing the user to learn more and do more work. "If git
notices it has too many 'loose object' and 'git gc' would fix the
problem, then why didn't it do that itself? And what the heck is a
'loose object' anyway?"
In general, git has always printed too many obscure messages that
don't actually help a new user get his work done, (and the work is
_not_ to learn more about git internals). From 1.4 to 1.5 much of that
was improved. But please let's not go backwards by adding more of
these.
So one vote from me for auto repacking, (but feel free to make the
threshold so high that anyone that actually _cares_ about loose
objects and repacking will never get the auto repack).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git.__remotes_from_dir() should only return lists
From: Pavel Roskin @ 2007-09-05 16:57 UTC (permalink / raw)
To: Catalin Marinas, kha, git
If there are no remotes, return empty list, not None. The later doesn't
work with builtin set().
This fixes t1001-branch-rename.sh
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
stgit/git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 4b4c626..f847cce 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -953,7 +953,7 @@ def __remotes_from_dir(dir):
if os.path.exists(d):
return os.listdir(d)
else:
- return None
+ return []
def remotes_list():
"""Return the list of remotes in the repository
^ permalink raw reply related
* Re: People unaware of the importance of "git gc"?
From: Govind Salinas @ 2007-09-05 16:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
Hi,
I am very new to git but I have thought about this a bit from a user's
perspective. I have several thoughts on the matter.
First, I would like to point out that the hg folks like to compare
themselves to git a lot and they list the need for manual gc as a
reason to choose hg over git. This may not be something that the git
community cares about but I thought I would point it out.
Second, it *is* a hassle. When trying to figure out what I could
convince my co-workers to use, having to gc was something that I did
not think they would be conscious of or care enough about to do. It
makes git more of a PITA than it could be. Similarly, I have no idea
when it is a good time to do a gc. After every commit? Before push?
What if I never push a repo? What if it is a remote repo only used to
sync up with my co-workers, do I have to go there and periodically gc?
This is one reason why I really think that gc should be *plumbing*
and *not* porcelain.
The user should never have to trigger a gc, they should even be
discouraged from doing so. That is how other gc systems are. Can you
imagine if you had a Java app that had a button on it to do a gc?
When should I push it? Should I wait till the system is getting slow
or just start spamming the button whenever I'm bored? I know that
Java/c#/py GC are different than git gc, but they fulfill the same
basic purpose as git gc. IE to clean up unused items and free up
resources. Git additionally may do some re-optimization, but that is
not relevant to a user.
I know this goes against the general mood here (which seems to be
against auto-gc) but I thought I would give my $.02 as a user of git.
Thanks,
Govind.
On 9/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> So we had a git bof at linux.conf.eu yesterday, and I leart something
> new: even people who have been using git for a long time apparently don't
> necessarily realize the importance of repacking.
>
> James Bottomley (the Linux SCSI maintainer) is an old-time BK user, and
> very comfy using git. But when he was demonstrating things on his poor old
> laptop, simple things like "git branch" literally took a long time, and
> James didn't seem to realize that the fact that he had apparently never
> ever repacked his repository was a big deal.
>
> The kernel archive is a 190MB pack for me fully repacked (I just checked -
> I had actually thought that it was somewhat larger than that), but because
> James hadn't repacked, his .git directory was over a gigabyte in size, and
> his laptop wasn't able to cache anything at all effectively as a result.
>
> Repacking it took over an hour, simply because everything was *so*
> unpacked, and James' kernel repository had something like 92 thousand
> loose objects, and several hundred packfiles. Simple operations that
> really take much less than a second for me ("git branch" takes 0.022s on
> my laptop, which has the same 512M that James had on his) took many many
> seconds as a result, and James seemed to think that this was all normal.
>
> And James didn't even want to repack, because it was so expensive (which
> he knew - he claims to have never ever repacked at all, but maybe he had
> started it and just control-C'd it when it was really slow at some point).
>
> Now, it may be that James didn't realize how important the occasional
> garbage collect is exactly *because* he is an old-timer and used BK long
> before he used git, and just continued using git simply as a BK
> replacement, but it did make me wonder whether maybe this lack of
> repacking awareness is fairly common.
>
> I've been against automatic repacking, but that was really based on what
> appears to be potentially a very wrong assumption, namely that people
> would do the manual repack on their own. If it turns out that people don't
> do it, maybe the right thing for git to do really is to at least notify
> people when they have way too many pack-files and/or loose objects.
>
> I personally repack everything way more often than is necessary, and I had
> kind of assumed that people did it that way, but I was apparently wrong.
> Comments?
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Git's database structure
From: Jon Smirl @ 2007-09-05 16:12 UTC (permalink / raw)
To: Julian Phillips
Cc: Andreas Ericsson, Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709051648400.3189@reaper.quantumfyre.co.uk>
On 9/5/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Wed, 5 Sep 2007, Jon Smirl wrote:
>
> > On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
> >> Jon Smirl wrote:
> >>>
> >>> The path name field needs to be moved back into the blobs to support
> >>> alternative indexes. For example I want an index on the Signed-off-by
> >>> field. I use this index to give me the SHAs for the blobs
> >>> Signed-off-by a particular person. In the current design I have no way
> >>> of recovering the path name for these blobs other than a brute force
> >>> search following every path looking for the right SHA.
> >>>
> >>
> >> Ah, there we go. A use-case at last :)
>
> But not a brilliant one. You sign off on commits not blobs. So you go
> from the sign-off to paths, then to blobs. There is no need to go from
> blob to path unless you deliberately introduce such a need.
Use blame for an example. Blame has to crawl every commit to see if it
touched the file. It keeps doing this until it figures out the last
author for every line in the file. Worse case blame has to crawl every
commit in the data store.
> >>
> >> So now we have a concrete problem that we can formulate thus:
> >> "How can one create a database listing the relationship between 'signers'
> >> and blobs?"
> >>
> >> So the second question: Do you seriously argue that git should take a
> >> huge performance loss on its common operations to accommodate a need that
> >> I suspect very few people have?
> >
> > Why do you keep jumping to a performance loss? Both schemes will have
> > an index based on paths. The problem is how those indexes are
> > constructed, not the existence of the index. Moving the paths into the
> > blobs in no way prevents you from creating an index on that field.
>
> But moving the path into the blob _IS_ the perfomance hit. You lose the
> ability to tell the two files have the same content _without even looking
> at the blob_. This is one of the core parts of making git operations
> blindingly fast. You can't throw that out, and then say that there is no
> performance hit.
>
> You keep talking about abstract database performance - but git is not an
> abstract database. It has very specific common usage patterns, and is
> optomisied to handle them.
>
> >
> > The problem is that the SHAs have been intertwined with the tree
> > nodes. This blending has made it impossible to create other indexes on
> > the blobs.
> >
> > The path index in the flat scheme will probably look just like tree
> > nodes do today but these new tree nodes won't be intertwined with the
> > SHAs.
>
> And you will have to prove that diff/merge etc. don't become very much
> slower before you get buy in.
>
> --
> Julian
>
> ---
> Many receive advice, few profit by it.
> -- Publilius Syrus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Miklos Vajna @ 2007-09-05 16:02 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86y7fohtmw.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On Mon, Sep 03, 2007 at 01:32:07PM +0200, David Kastrup <dak@gnu.org> wrote:
> >> And if I understand the documentation correctly, then
> >
> >> $ mkdir foo && cd foo
> >> $ cat ../x
> >> x: No such file or directory
> >
> >> Right?
> >
> > correct.
>
> Have you tested this, or is this from reading the documentation? In
> either case: brilliant, but the former would be funnier (depending on
> one's sense of humor, of course).
umm, thanks for the notice, i was wrong:
----
$ cat ../x
this is makefile
----
the situation what triggers the 'no such file' problem is:
----
$ touch foo/Makefile
$ mkdir bar
$ ln -s foo/Makefile bar
$ cd bar
$ cat Makefile
cat: Makefile: No such file or directory
----
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git's database structure
From: Julian Phillips @ 2007-09-05 15:54 UTC (permalink / raw)
To: Jon Smirl
Cc: Andreas Ericsson, Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910709050837o61a2dedfpc5f72a239b1cb8e3@mail.gmail.com>
On Wed, 5 Sep 2007, Jon Smirl wrote:
> On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
>> Jon Smirl wrote:
>>>
>>> The path name field needs to be moved back into the blobs to support
>>> alternative indexes. For example I want an index on the Signed-off-by
>>> field. I use this index to give me the SHAs for the blobs
>>> Signed-off-by a particular person. In the current design I have no way
>>> of recovering the path name for these blobs other than a brute force
>>> search following every path looking for the right SHA.
>>>
>>
>> Ah, there we go. A use-case at last :)
But not a brilliant one. You sign off on commits not blobs. So you go
from the sign-off to paths, then to blobs. There is no need to go from
blob to path unless you deliberately introduce such a need.
>>
>> So now we have a concrete problem that we can formulate thus:
>> "How can one create a database listing the relationship between 'signers'
>> and blobs?"
>>
>> So the second question: Do you seriously argue that git should take a
>> huge performance loss on its common operations to accommodate a need that
>> I suspect very few people have?
>
> Why do you keep jumping to a performance loss? Both schemes will have
> an index based on paths. The problem is how those indexes are
> constructed, not the existence of the index. Moving the paths into the
> blobs in no way prevents you from creating an index on that field.
But moving the path into the blob _IS_ the perfomance hit. You lose the
ability to tell the two files have the same content _without even looking
at the blob_. This is one of the core parts of making git operations
blindingly fast. You can't throw that out, and then say that there is no
performance hit.
You keep talking about abstract database performance - but git is not an
abstract database. It has very specific common usage patterns, and is
optomisied to handle them.
>
> The problem is that the SHAs have been intertwined with the tree
> nodes. This blending has made it impossible to create other indexes on
> the blobs.
>
> The path index in the flat scheme will probably look just like tree
> nodes do today but these new tree nodes won't be intertwined with the
> SHAs.
And you will have to prove that diff/merge etc. don't become very much
slower before you get buy in.
--
Julian
---
Many receive advice, few profit by it.
-- Publilius Syrus
^ permalink raw reply
* Re: Git's database structure
From: Jon Smirl @ 2007-09-05 15:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <46DEC26E.7030809@op5.se>
On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
> Jon Smirl wrote:
> >
> > The path name field needs to be moved back into the blobs to support
> > alternative indexes. For example I want an index on the Signed-off-by
> > field. I use this index to give me the SHAs for the blobs
> > Signed-off-by a particular person. In the current design I have no way
> > of recovering the path name for these blobs other than a brute force
> > search following every path looking for the right SHA.
> >
>
> Ah, there we go. A use-case at last :)
>
> So now we have a concrete problem that we can formulate thus:
> "How can one create a database listing the relationship between 'signers'
> and blobs?"
>
> So the second question: Do you seriously argue that git should take a
> huge performance loss on its common operations to accommodate a need that
> I suspect very few people have?
Why do you keep jumping to a performance loss? Both schemes will have
an index based on paths. The problem is how those indexes are
constructed, not the existence of the index. Moving the paths into the
blobs in no way prevents you from creating an index on that field.
The problem is that the SHAs have been intertwined with the tree
nodes. This blending has made it impossible to create other indexes on
the blobs.
The path index in the flat scheme will probably look just like tree
nodes do today but these new tree nodes won't be intertwined with the
SHAs.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Kristian Høgsberg @ 2007-09-05 15:27 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46DDC500.5000606@etek.chalmers.se>
On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:
> Hi.
>
> This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c
>
> The patch doesn't pass all the tests in the testsuit yet, but I thought I'd
> send it out so people can decide if they like how the code looks.
>
> I'm not sending a patch to add the library files at this time. I'll send
> that patch when this patch is working.
>
> The changes required to make it pass the tests shouldn't be very large.
Please, no. Let's not pull in a dependency for something as simple as a
string library. How many distros have bstring pcakaged?
The right version? Does it work on Windows? We already have strbuf.c,
lets just consolidate the string manipulation code already in git under
that interface.
Kristian
^ permalink raw reply
* Re: Git's database structure
From: Andreas Ericsson @ 2007-09-05 14:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910709050641j34d58683ra72caa52c56cdf0f@mail.gmail.com>
Jon Smirl wrote:
>
> The path name field needs to be moved back into the blobs to support
> alternative indexes. For example I want an index on the Signed-off-by
> field. I use this index to give me the SHAs for the blobs
> Signed-off-by a particular person. In the current design I have no way
> of recovering the path name for these blobs other than a brute force
> search following every path looking for the right SHA.
>
Ah, there we go. A use-case at last :)
So now we have a concrete problem that we can formulate thus:
"How can one create a database listing the relationship between 'signers'
and blobs?"
So the second question: Do you seriously argue that git should take a
huge performance loss on its common operations to accommodate a need that
I suspect very few people have?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Kristian Høgsberg @ 2007-09-05 14:54 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <46DDC500.5000606@etek.chalmers.se>
On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:
> Hi.
>
> This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c
>
> The patch doesn't pass all the tests in the testsuit yet, but I thought I'd
> send it out so people can decide if they like how the code looks.
>
> I'm not sending a patch to add the library files at this time. I'll send
> that patch when this patch is working.
>
> The changes required to make it pass the tests shouldn't be very large.
Please, no. Let's not pull in a dependency for something as simple as a
string library. How many distros have bstring pcakaged?
The right version? Does it work on Windows? We already have strbuf.c,
lets just consolidate the string manipulation code already in git under
that interface.
Kristian
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Johan De Messemaeker @ 2007-09-05 14:17 UTC (permalink / raw)
To: Matthieu Moy
Cc: Martin Langhoff, Junio C Hamano, Steven Grimm, Linus Torvalds,
Git Mailing List
In-Reply-To: <vpqzm01v4li.fsf@bauges.imag.fr>
On 05 Sep 2007, at 11:33, Matthieu Moy wrote:
>
> There's indeed a real idea behind that. The issue is that the alias
> shouldn't be just "gc", but "find-all-repositories-and-do-gc-there".
>
> Currently, AFAIK, that can only be done with a (trivial) script
> external to git. I suppose this can easily be added to the core git
> porcelain. Perhaps a "git gc --recursive" would do.
>
> It doesn't solve the problem, but makes it easier to solve it (git gc
> --recursive in cron for example).
I'm a git newb so I can be wrong here but ...
Why --recursive? Why not use the submodule-information ?
Johan
^ 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