* Re: People unaware of the importance of "git gc"?
From: Johan Herland @ 2007-09-05 8:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <vpqtzq91p5z.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Wednesday 05 September 2007, Matthieu Moy wrote:
> Johan Herland <johan@herland.net> writes:
>
> > When git-fetch and git-commit has done its job and is about to exit, it checks
> > the number of loose object, and if too high tells the user something
> > like "There are too many loose objects in the repo, do you want me to repack?
> > (y/N)". If the user answers "n" or simply <Enter>,
>
> I don't like commands to be interactive if they don't _need_ to be so.
> It kills scripting, it makes it hard for a front-end (git gui or so)
> to use the command, ...
Ok, so add an option or config variable to turn on/off this behaviour.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Matthieu Moy @ 2007-09-05 8:39 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <200709051013.39910.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> When git-fetch and git-commit has done its job and is about to exit, it checks
> the number of loose object, and if too high tells the user something
> like "There are too many loose objects in the repo, do you want me to repack?
> (y/N)". If the user answers "n" or simply <Enter>,
I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...
--
Matthieu
^ permalink raw reply
* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.
From: Dmitry Kakurin @ 2007-09-05 8:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jan Hudec, Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <7vk5r5jzpn.fsf@gitster.siamese.dyndns.org>
On 9/5/07, Junio C Hamano <gitster@pobox.com> 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?
No, from couple of my emails back:
> This leads to a simple idea that mostly works:
> 1. when files are moved from index to filesystem, then only .gitattributes in the index is used, if it's not there == no special attributes.
> 2. when files are moved from filesystem to index, then only .gitattributes in filesystem is used, again if it's not there == no special attributes.
>
> Then, in any operation, only one .gitattributes is taken into account.
This is a must-do change (IMHO).
To go one step further (again IMHO) is to eliminate workspace version
of .gitattributes all together:
> We could stop here, but to me this redundancy still has some room for confusion and looks unnecessary.
> Plus there is still room for unintentional abuse (by mistake).
> That's why I think it's a good idea to always have only one .gitattributes (in the index).
--
- Dmitry
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Johan Herland @ 2007-09-05 8:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds
In-Reply-To: <7vsl5tk1r8.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]
On Wednesday 05 September 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > 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?
>
> I am as old timer as you are so I am not qualified to add much
> variety to the discussion, but I agree that excessive cruft is
> something we should warn the user about.
>
> I personally was _extremely_ annoyed by git-cvsimport
> occassionary deciding to repack whenever it finds more than
> certain number of loose objects, not because it is a big import,
> but because I happened to start the command to start a very
> small import after doing my own development for a while to
> accumulate loose objects, and I really hate automatic repacking
> for any operation (or tool that thinks it knows better than I do
> in general).
>
> Perhaps _exiting_ "git-commit" and "git-fetch" before doing
> anything, when the repository has more than 5000 loose objects
> with a LOUD bang that instructs an immediate repack would be
> good?
>
> I really do not like the idea of automatically running a repack
> after first interrupting the original command and then resuming.
> For one thing it would make a horribly difficult situation to
> debug if anything goes wrong. You cannot reproduce such a
> situation easily.
What about some sort of middle ground:
When git-fetch and git-commit has done its job and is about to exit, it checks
the number of loose object, and if too high tells the user something
like "There are too many loose objects in the repo, do you want me to repack?
(y/N)". If the user answers "n" or simply <Enter>, it exits immediately
without doing anything, but if the user answers "y", or if there is no
response, say, within a minute (i.e. the user went to lunch), the repack is
initiated. (Of course, the user should be told that a Ctrl-C will abort the
repack and not be harmful in any way.)
If the user answers "n" (or aborts the repack), the question will keep popping
up on the next git-{commit,fetch} to remind/annoy the user until a repack is
done.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: David Kastrup @ 2007-09-05 8:16 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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?
Can it be that getting rid of unused objects is harder once they are
packed? If that is the case, an automatic pack while mucking about
with temporary branches and/or confidential files would be quite a
nuisance.
Automatic packing maybe would be acceptable if packing was really
transparent to what you do with your repo (including janitoring work).
And it would be nice if automatic packing could be done in an
incremental manner, not bogging down normal work.
--
David Kastrup
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Junio C Hamano @ 2007-09-05 8:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <20070905074206.GA31750@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> I do, when I'm bored and that I can't get things done. you know, it
> has become one of my many twitches when I have an empty tty in front of
> me and that I'm doing nothing useful.
Very well said ;-)
^ permalink raw reply
* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.
From: Junio C Hamano @ 2007-09-05 8:14 UTC (permalink / raw)
To: Dmitry Kakurin
Cc: Jan Hudec, Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <a1bbc6950709050106j137215obd7272b2a77c3b13@mail.gmail.com>
"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?
^ permalink raw reply
* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.
From: Dmitry Kakurin @ 2007-09-05 8:06 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <20070904202326.GC3786@efreet.light.src>
On 9/4/07, Jan Hudec <bulb@ucw.cz> wrote:
> On Tue, Aug 28, 2007 at 09:49:47 +0100, Johannes Schindelin wrote:
> > On Mon, 27 Aug 2007, Dmitry Kakurin wrote:
> >
> > > Here is the problem: we need to apply crlf attributes to a file. We
> > > could have .gitattributes both in the index and in the worktree.
> > > Which one do we use?
> > > In general .gitattributes file could be (U)nchanged, (C)hanged, (NP)
> > > NotPresent in each place.
> >
> > I do not see these cases. You can have these cases, basically:
> >
> > - .gitattributes in worktree (then it does not matter what else we have),
> > - .gitattributes not in the worktree, but in the index (then that is taken)
> >
> > In the latter case, there could be conflicts _in_ .gitattributes, in which
> > case those .gitattributes are ignored.
> >
> > I do not see any problem with that.
>
> I do.
>
> IMNSHO it should be the other way around:
> .gitattributes in index, than index version is used.
> .gitattributes not in index, but in worktree, than that tree version is used.
Consider scenario when my commit #1 has .gitattributes:
a.txt -nocrlf
and file a.txt
You pull it.
Now I make some changes to a.txt and realize that a.txt *is* a text
file now. I remove the entry from .gitattributes and notice that it
becomes empty. So I just remove .gitattributes file all together. It
becomes commit#2.
Now you pull it again. There *is* .gitattributes in local directory,
but index does not have it (because I've removed it on purpose). What
should happen?
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.
With every commit 3 things could happen: .gitattributes could appear,
disappear or change. In every case "build machine" must produce the
exact copy of what-was-checked-in. The only way I see this happening
is by using *only* index version of .gitattributes when files are
moved index -> workspace.
A similar reasoning works for other direction (workplace -> index).
--
- Dmitry
^ permalink raw reply
* Re: [PATCH] Simplify strbuf uses in fast-import.c using the proper functions.
From: Junio C Hamano @ 2007-09-05 8:05 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, René Scharfe
In-Reply-To: <20070905074815.GB31750@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> oh boy, yes I fixed that in my local patch collection. I'm waiting for
> a few hours (days ?) to see if there will be some more comments, I've
> integrated every single one done here already (and some I had on IRC
> too), and I'll repost a new clean series that I intend to be a real
> proposal for inclusion.
Ah, I actually did the single trivial fix-up (ALLOC_GROW) and
have been looking at it, but I'll discard it. Thanks.
> And yes, this patch is a perfect example of the gain we have to share
> a common buffer API. The code looks (at least to me) way nicer, and if
> you look in the details, we perform as many memory allocations, copies,
> and so on as in the previous version.
Wait. What is your point in saying this? Is that a good thing
to do "as many"? "API is cleaned-up and it is much easier to
read but we do not do more than before" is certainly a *BIG*
plus, so perhaps that is what you meant, but when I first read
it I thought you were saying "we are not optimizing it at all"
in a negative sense.
^ permalink raw reply
* Re: [PATCH] Simplify strbuf uses in fast-import.c using the proper functions.
From: Pierre Habouzit @ 2007-09-05 7:48 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <46DDEE73.5020904@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
On Tue, Sep 04, 2007 at 11:46:59PM +0000, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > This is just cleaner way to deal with strbufs, using its API rather than
> > reinventing it in the module (e.g. strbuf_append_string is just the plain
> > strbuf_addstr function, and it was used to perform what strbuf_addch does
> > anyways).
> > ---
> > archive-tar.c | 65 ++++++++++++++-------------------------------------------
> > 1 files changed, 16 insertions(+), 49 deletions(-)
>
> Apart from the wrong subject line I really like this patch. :-D
oh boy, yes I fixed that in my local patch collection. I'm waiting for
a few hours (days ?) to see if there will be some more comments, I've
integrated every single one done here already (and some I had on IRC
too), and I'll repost a new clean series that I intend to be a real
proposal for inclusion.
And yes, this patch is a perfect example of the gain we have to share
a common buffer API. The code looks (at least to me) way nicer, and if
you look in the details, we perform as many memory allocations, copies,
and so on as in the previous version.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Tomash Brechko @ 2007-09-05 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vsl5tk1r8.fsf@gitster.siamese.dyndns.org>
Hi!
On Wed, Sep 05, 2007 at 00:30:35 -0700, Junio C Hamano wrote:
> Perhaps _exiting_ "git-commit" and "git-fetch" before doing
> anything, when the repository has more than 5000 loose objects
> with a LOUD bang that instructs an immediate repack would be
> good?
This may break automation. I run git-gc monthly via cron, but that
doesn't guarantee I won't get 5000 loose objects before that. And I
agree that automatic run is annoying. Perhaps simple BIG FAT WARNING
is the best after all.
--
Tomash Brechko
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Pierre Habouzit @ 2007-09-05 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Wed, Sep 05, 2007 at 07:09:27AM +0000, Linus Torvalds wrote:
> 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.
Well independently from the fact that one could suppose that users
should use gc on their own, the big nasty problem with repacking is that
it's really slow. And I just can't imagine git that I use to commit
blazingly fast, will then be unavailable for a very long time (repacks
on my projects -- that are not as big as the kernel but still -- usually
take more than 10 to 20 seconds each).
> 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?
I do, when I'm bored and that I can't get things done. you know, it
has become one of my many twitches when I have an empty tty in front of
me and that I'm doing nothing useful. Though, when I'm in a hack-attack,
well I don't necessarily remember to repack. I'm in one of the (not so
many ?) very lucky companies (yay start-ups) where I could show that git
was very superior, and we now use it as our sole SCM. So when I'm in a
hack attack, it's usually that it's a busy week, and that new patches,
trees, objects (and sometimes with large binary things in it) flows like
hell. And the repository grows larger and larger. Well, the way we chose
to avoid the "I'm coding don't bother me with administrivia"-attitude is
that our users use a small cron that basically runs git gc each day, and
an aggressive repack (with a window of 50 or 100 I don't remember) each
Week-end in a cron. Because the best criterion to repack a repository
is: when there is no-one on the computer.
It has proven quite good, as we have never seen a repository explode
in a day, even after some funny mistakes where people rebase some big
parts of the tree many times, generating very large number of loose
objets.
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Karl Hasselström @ 2007-09-05 7:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <46a038f90709050021o5cdcc976xd099242aeb70643d@mail.gmail.com>
On 2007-09-05 19:21:29 +1200, Martin Langhoff wrote:
> I never followed up on one of your suggestions back in the day --
> that we printed an informational msg along the lines of "you have X
> loose objects, it's about time to repack" after some operations
> (fetch, merge, commit).
git-gui pops up a dialog that says precisely that, and gives you the
choice of repacking right then and there, or skip it.
As for truly automatic repacking after commands such as fetch, it
could probably be a config option (defaulting to "on"). It'd be
important to have "press any key to abort repacking (with no ill
effects)" type funtctionality, though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Junio C Hamano @ 2007-09-05 7:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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?
I am as old timer as you are so I am not qualified to add much
variety to the discussion, but I agree that excessive cruft is
something we should warn the user about.
I personally was _extremely_ annoyed by git-cvsimport
occassionary deciding to repack whenever it finds more than
certain number of loose objects, not because it is a big import,
but because I happened to start the command to start a very
small import after doing my own development for a while to
accumulate loose objects, and I really hate automatic repacking
for any operation (or tool that thinks it knows better than I do
in general).
Perhaps _exiting_ "git-commit" and "git-fetch" before doing
anything, when the repository has more than 5000 loose objects
with a LOUD bang that instructs an immediate repack would be
good?
I really do not like the idea of automatically running a repack
after first interrupting the original command and then resuming.
For one thing it would make a horribly difficult situation to
debug if anything goes wrong. You cannot reproduce such a
situation easily.
^ permalink raw reply
* Re: Git's database structure
From: Andreas Ericsson @ 2007-09-05 7:18 UTC (permalink / raw)
To: Jon Smirl; +Cc: Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910709041454i189e6629k78ddeb89797276b3@mail.gmail.com>
Jon Smirl wrote:
> On 9/4/07, Theodore Tso <tytso@mit.edu> wrote:
>> On Tue, Sep 04, 2007 at 01:44:47PM -0400, Jon Smirl wrote:
>>> The current data store design is not very flexible. Databases solved
>>> the flexibility problem long ago. I'm just wondering if we should
>>> steal some good ideas out of the database world and apply them to git.
>>> Ten years from now we may have 100GB git databases and really wish we
>>> had more flexible ways of querying them.
>> Databases solved the flexibility problem, at the cost of performance.
>> And if you use full normalized form in your database scheme, it costs
>> you even more in performance, because of all of the joins that you
>> need in order get the information you need to do, you know, useful
>> work as opposed to database wanking.
>>
>> If you take a look at the really big databases with super high
>> performance requirements, say like those used to managed airline
>> tickets/reservation/fares, you will find that they are not normalized,
>> and they are not relational; they can't afford to be. And if you take
>> a look at some of git competition that use relational databases to
>> store their SCM data, and take a look at how loooooong they they take
>> to do even basic operations, I would say that the onus is on you to
>> prove that normalization is actually a win in terms of real (not
>> theoretical) advantages, and that it doesn't cause performance to go
>> into the toilet.
>>
>> I think the fundamental disconnect here is that no one is buying your
>> claim that just because the data design is "more flexible" that this
>> is automatically a good thing in and of itself, and we should even for
>> a moment, "put performance aside".
>
> It is very easy to get bogged down in performance arguments on
> database design when the correct answer is that there are always lots
> of different ways to achieve the same goal. I wanted to defer debating
> performance until we closely looked at the relationships between the
> data at an abstract level.
>
But you cannot. Git is performance-critical, for the same reason every
other performance-critical application is: It's a tool to save human
time. Linux development *could* be done using patchfiles by the bundle
and masses of tarballs. It's just not the fastest way to do it, so enter
git, and lots of problems just go away. It's not the only way of doing
it, but it saves time. If you were to add 2 seconds to each commit,
that's several months of developer time that is lost every day!
> Since git hasn't stored all of the fields in the object table (the
> path is encoded in the index) we are never going to be able to build
> an alternative way of indexing the object table.
We can still build alternative indexes. They just have to be separate
from the DAG and the current indexing scheme. Junio has pointed out
ways of doing this already.
> Not being able to
> build alternative indexes is likely to cause problems when the
> database starts getting really big. Without an index every query that
> can't use the path name index is reduced to doing full table scans.
>
I've said it before; The most common delimiter used today is paths. It's
a behaviour git was designed to handle well, because it *is* the most
common way of limiting and separating content. It's not some random
fluke that has made git perform very well on actions that commonly
performed in large scale software projects; Linus designed it that way
from the start, and kudos to him for a job well done.
> A few things that could benefit from alternative indexing, blame,
> full-text search, automating the Maintainers file, etc.
>
Yes, but getting rid of the tree objects and storing pathnames in
blob objects would penalize log-viewing, diffs and merges, which
are far more common operations than full-text searches in a software
project.
> I'm just asking if we really want to make full table scans the only
> possible way to implement these types of queries. If the answer is no,
> then let's first explore how to fix things at an abstract level before
> diving into the performance arguments.
>
Personally, I really don't care. But you should really have read Junio's
mail a bit more carefully. He explained about 'notes' that can be attached
to commits and contain arbitrary data. By all means, create your indexes
there and use them for whatever you like, but leave the foundation on which
git was built *alone*. The design hasn't changed since April 2006 (subtrees
were introduced April 26, I think), because it's a *good* design.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Martin Langhoff @ 2007-09-05 7:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709042355030.19879@evo.linux-foundation.org>
On 9/5/07, Linus Torvalds <torvalds@linux-foundation.org> 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?
(resent with CC to git@)
I never followed up on one of your suggestions back in the day -- that
we printed an informational msg along the lines of "you have X loose
objects, it's about time to repack" after some operations (fetch,
merge, commit). These days it's all C, so I'll pass the buck to people
that actually know how to do printf() ;-)
Also -- early users got everything exploded during clone, James is
probable one of them. It is the worst case scenario, really. Users of
a modern git will start off with a large packs, and accumulate little
packs from pulls, so it's not as bad.
In fact, in James' case, it would have been way way way faster to
"steal" the packs from git.kernel.org via http (or your laptop) and
_then_ repack. He'd been sorted in a minute.
cheers,
martin
^ permalink raw reply
* People unaware of the importance of "git gc"?
From: Linus Torvalds @ 2007-09-05 7:09 UTC (permalink / raw)
To: Git Mailing List
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
^ permalink raw reply
* Re: [PATCH] Function for updating refs.
From: Junio C Hamano @ 2007-09-05 7:04 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin
In-Reply-To: <46DE0890.5020709@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> A function intended to be called from builtins updating refs
> by locking them before write, specially those that came from
> scripts using "git update-ref".
>
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
Thanks. Very nice.
I have two comments but I think they are very minor details I
can and should fix in my inbox and apply, instead of asking you
to update and resend.
> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
> index e2f8ede..a192fd7 100644
> --- a/builtin-fetch--tool.c
> +++ b/builtin-fetch--tool.c
> @@ -31,24 +31,19 @@ static void show_new(enum object_type type, unsigned char *sha1_new)
> find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
> }
>
> -static int update_ref(const char *action,
> +static int update_ref_env(const char *action,
> const char *refname,
> unsigned char *sha1,
> unsigned char *oldval)
> {
> char msg[1024];
> char *rla = getenv("GIT_REFLOG_ACTION");
> - static struct ref_lock *lock;
>
> if (!rla)
> rla = "(reflog update)";
> - snprintf(msg, sizeof(msg), "%s: %s", rla, action);
> - lock = lock_any_ref_for_update(refname, oldval, 0);
> - if (!lock)
> - return 1;
> - if (write_ref_sha1(lock, sha1, msg) < 0)
> - return 1;
> - return 0;
> + if (snprintf(msg, sizeof(msg), "%s: %s", rla, action) >= sizeof(msg))
> + error("reflog message too long: %.*s...", 50, msg);
The original I did was sloppy and did not detect this situation;
thanks for fixing it. You do not refuse the primary operation,
which is to update the ref, so this should be a warning instead
of an error, I think.
> diff --git a/send-pack.c b/send-pack.c
> index 9fc8a81..c59eea4 100644
> --- a/send-pack.c
> +++ b/send-pack.c
> @@ -313,14 +313,9 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
> if (delete_ref(rs.dst, NULL)) {
> error("Failed to delete");
> }
> - } else {
> - lock = lock_any_ref_for_update(rs.dst, NULL, 0);
> - if (!lock)
> - error("Failed to lock");
> - else
> - write_ref_sha1(lock, ref->new_sha1,
> - "update by push");
> - }
This removal makes "struct ref_lock *lock" (not shown in the
context) unused. I will remove the declaration.
^ permalink raw reply
* Re: new to git
From: Junio C Hamano @ 2007-09-05 6:54 UTC (permalink / raw)
To: Kyle Rose; +Cc: git mailing list
In-Reply-To: <46D32973.8030104@krose.org>
[jc: I think this is really worth saving somewhere. Could some
kind soul make this into a patch to have under Documentation/
somewhere?]
Kyle Rose <krose@krose.org> writes:
> (1) Let's say I:
>
> git clone something
Origin repository's history is copied and you get their master
in remotes/origin/master (aka remotes/origin/HEAD aka
remotes/origin), and you can call that 'origin' for brevity.
At the same time, you get your own 'master' branch that points
at the same commit as the 'origin'. Your current branch
pointed at by your HEAD is 'master'.
['origin' repository]
---A---B---C
^master
==>
[your cloned repository]
---A---B---C
^master = HEAD
^remotes/origin
> git branch foo
You create a new branch of your own 'foo' in your repository,
initially pointing at the same commit as your current commit
(i.e. C as you are on 'master' after the clone).
==>
[your cloned repository]
---A---B---C
^master = HEAD
^remotes/origin
^foo
> git checkout foo
You switch from your current branch (i.e. 'master') to the
named branch (i.e. 'foo'), making the latter the current
branch. Your work tree will largely match the commit at the
tip of the branch you are switching to, except that if you had
any local changes (i.e. uncommitted) in your work tree, you
take it along (but in this example you do not have any).
==>
[your cloned repository]
---A---B---C
^master
^remotes/origin
^foo = HEAD
> <make some changes>
> git commit -a
You build a commit whose parent is the commit your HEAD used
to point at; the tip of your current branch advances.
==>
[your cloned repository]
---A---B---C---D
^foo = HEAD
^master
^remotes/origin
> git checkout master
You switch from your current branch (i.e. 'foo') to the
named branch (i.e. 'master'), making the latter the current
branch. Your work tree will largely match the commit at the
tip of the branch you are switching to, except that if you had
any local changes (i.e. uncommitted) in your work tree, you
take it along (but in this example you do not have any).
==>
[your cloned repository]
---A---B---C---D
^foo
^master = HEAD
^remotes/origin
> git pull . foo
This "git pull" command instructs git to "from the repository
'.', grab the commit the repository calls 'foo', and update my
current branch by merging that commit". Because '.' is "the
current directory", which in turn means "my repository", you
do not have to really "grab the commit" --- you already have
it locally.
"git merge foo" is more natural way to write this since 1.5.0
days. The latter command instructs git "update my current
branch by merging commit I call 'foo'".
Now, looking at the above history graph, your current
branch'es tip is at C (you are on 'master', remember?), and
'foo' is at D, which is an descendant of C. By definition, a
merge between such commit pair is the descendant D, so your
current branch is updated to D (this is called "fast
forward").
==>
[your cloned repository]
---A---B---C---D
^foo
^master = HEAD
^remotes/origin
> git push
This is kind of "lazy" and "very not-git-like" command I
literally *hate*. What "git push" does, whey you do not say
anything about "where to" nor "what", is to "push all
corresponding branches and tags to the repository you call
'origin'".
If you recall the very initial picture, the 'origin'
repository has 'master' branch but not 'foo'. The only
matching branch is 'master', and that is pointing at C over
there, which is replaced by your 'master' which now points at
'D'.
['origin' repository]
---A---B---C
^master
==>
['origin' repository]
---A---B---C---D
^master
Note that this update *MUST* be fast-forward by default. IOW,
if somebody worked elsewhere and updated the 'master' branch
at the 'origin' repository before your push, your 'push' will
be prevented with an error message that tells you that remote
'master' is not a strict subset of what you are pushing.
> git pull
Instruct git to "grab the history from the 'origin' repository
and update remotes/origin/* with its branch, and then update my
current branch by merging its tip".
The first step of updating the remotes/origin again *MUST* be
fast-forward by default.
==>
[your cloned repository]
---A---B---C---D
^foo
^master = HEAD
^remotes/origin
If you recall, you are on 'master' branch whose tip is at D.
Now you are telling git to update it by merging what you
fetched, which also is D. So nothing happens.
> (2) Any way to disable this warning:
>
> Warning: No merge candidate found because value of config option
> "branch.local.merge" does not match any remote branch fetched.
Do as the warning says; I do not think the message can be any
clearer (see Documentation/config.txt, or even better "The
User's Manual"). Set branch.local.merge configuration variable
if you want to always merge specific branch you obtain from the
remote.
E.g.
[branch "local"]
remote = origin
merge = refs/heads/master
if you want "git pull", without saying what to pull from where,
to fetch from 'origin' and merge its 'master' branch, when you
are on your 'local' branch.
> (3) I notice I can't reset --hard a single file. So, if I want to
> revert a single file to some revision, blowing away my changes, what is
> the accepted way of doing this? Is there a way to do the equivalent of
> a p4 print foo@some_revision?
I have no idea what p4 does, but:
git checkout -- path
updates the work tree file with the last version of paths you
did "git add path",
git checkout HEAD -- path
updates the work tree file with the version of paths in the HEAD
commit, and
git checkout some_version -- path
updates the work tree file with the version of paths in the
named commit. For various ways to name commits, see
git-rev-parse(1).
> (4) I'm still not clear on when a dst should and should not be used in a
> refspec. It appears that one can only do non-fast forward updates to
> the branch that is checked out (which makes sense, since you may need to
> resolve), but other than that, what is the difference between
>
> git checkout foo
> git pull . master
>
> and
>
> git checkout master
> git push . master:foo
The obvious difference is which branch you end up with.
> (5) Are there any tools for managing some of the metadata (e.g., the
> origin URL) or is it expected that one edit it directly?
git-remote(1).
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Marius Storm-Olsen @ 2007-09-05 6:22 UTC (permalink / raw)
To: git, Johannes Schindelin, Johannes Sixt; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20070904210200.GA32472@nospam.com>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
Rutger Nijlunsing said the following on 04.09.2007 23:02:
> On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:
>> Now I am utterly confused. MSDN says
>> FILETIME
>> Contains a 64-bit value representing the number of 100-nanosecond
>> intervals since January 1, 1601 (UTC).
>> Hmm.
>
> [Warning: war stories ahead...]
> If you really, really want to know more:
> http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm
Thanks, seems like it's the right decision then to ensure that we use
UTC throughout Git on Windows
Hannes & Dscho, looks like we should revert
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
then, and rather apply Dscho's patch for a custom time()
implementation. Dscho, was the custom implementation of time() enough
to fix the issues for you?
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: new to git
From: Jan Hudec @ 2007-09-05 5:56 UTC (permalink / raw)
To: Kyle Rose; +Cc: git mailing list
In-Reply-To: <46D32973.8030104@krose.org>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Mon, Aug 27, 2007 at 15:43:47 -0400, Kyle Rose wrote:
> After many years of dissatisfaction with the limitations of CVS, and
> after getting fed up with the complexity of configuring and maintaining
> a SVN setup, I just started using git for my own personal projects. I
> have to say it's quite nice and fits the UNIX philosophy well: fast,
> simple, powerful.
>
> I've been playing with it for a few weeks and generally understand what
> is going on, but I do have a few usage questions that I couldn't find
> answered in the docs:
>
> (1) Let's say I:
>
> git clone something
> git branch foo
> git checkout foo
> <make some changes>
> git commit -a
> git checkout master
> git pull . foo
git merge foo
would be probably both clearer about the intent and more efficient here.
After all, pull is just a simple wrapper for fetch + merge and you don't need
the fetch from the repository to itself.
> git push
> git pull
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Rework strbuf API and semantics.
From: Miles Bader @ 2007-09-05 4:44 UTC (permalink / raw)
To: git
In-Reply-To: <20070904115317.GA3381@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> In my own coding rules, I have _new/_delete and _init/_wipe functions,
> the former acts on pointers, the latter on the structs. Hence the
> naming.
A little off-topic, but my own personal convention for the latter case
are _init/_fini -- I've always thought the "fini" name was a pretty good
partner for "init", so I share it here... :-)
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
^ permalink raw reply
* Re: [PATCH 2/3] archive: specfile support (--pretty=format: in archive files)
From: Johannes Schindelin @ 2007-09-05 0:12 UTC (permalink / raw)
To: René Scharfe
Cc: Andreas Ericsson, Junio C Hamano, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <46DDE69C.1080908@lsrfire.ath.cx>
Hi,
On Wed, 5 Sep 2007, Ren? Scharfe wrote:
> Johannes Schindelin schrieb:
>
> > On Tue, 4 Sep 2007, Andreas Ericsson wrote:
> >
> >> Junio C Hamano wrote:
> >>> Ren? Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> >>>
> >>>> The attribute is useful for creating auto-updating specfiles. It is
> >>>> limited by the underlying function format_commit_message(), though.
> >>>> E.g. currently there is no placeholder for git-describe like output,
> >>>> and expanded specfiles can't contain NUL bytes. That can be fixed
> >>>> in format_commit_message() later and will then benefit users of
> >>>> git-log, too.
> >>> Interesting. I however wonder if "specfile" is a good name for this
> >>> attribute, although I admit I do not think of anything better offhand.
> >> "releasefile", perhaps?
> >
> > Maybe we should not so much name it by purpose, but by function. How
> > about "substformat" for the attribute name, and replacing any
> > $Format:blablub$ inside those files with something a la
> > --pretty=format:blablub?
>
> I like the $Format:...$ notation. How about naming the attribute
> "template", as that's what a thus marked file is?
Unless somebody comes up with an even better name, yes (I like "template"
better than "substformat" or "releasefile", but I still think that
"template" is not descriptive enough).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Function for updating refs.
From: Carlos Rica @ 2007-09-05 1:38 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
A function intended to be called from builtins updating refs
by locking them before write, specially those that came from
scripts using "git update-ref".
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
builtin-fetch--tool.c | 21 ++++++++-------------
builtin-update-ref.c | 8 ++------
refs.c | 28 ++++++++++++++++++++++++++++
refs.h | 6 ++++++
send-pack.c | 11 +++--------
5 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index e2f8ede..a192fd7 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -31,24 +31,19 @@ static void show_new(enum object_type type, unsigned char *sha1_new)
find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
}
-static int update_ref(const char *action,
+static int update_ref_env(const char *action,
const char *refname,
unsigned char *sha1,
unsigned char *oldval)
{
char msg[1024];
char *rla = getenv("GIT_REFLOG_ACTION");
- static struct ref_lock *lock;
if (!rla)
rla = "(reflog update)";
- snprintf(msg, sizeof(msg), "%s: %s", rla, action);
- lock = lock_any_ref_for_update(refname, oldval, 0);
- if (!lock)
- return 1;
- if (write_ref_sha1(lock, sha1, msg) < 0)
- return 1;
- return 0;
+ if (snprintf(msg, sizeof(msg), "%s: %s", rla, action) >= sizeof(msg))
+ error("reflog message too long: %.*s...", 50, msg);
+ return update_ref(msg, refname, sha1, oldval, 0, QUIET_ON_ERR);
}
static int update_local_ref(const char *name,
@@ -88,7 +83,7 @@ static int update_local_ref(const char *name,
fprintf(stderr, "* %s: storing %s\n",
name, note);
show_new(type, sha1_new);
- return update_ref(msg, name, sha1_new, NULL);
+ return update_ref_env(msg, name, sha1_new, NULL);
}
if (!hashcmp(sha1_old, sha1_new)) {
@@ -102,7 +97,7 @@ static int update_local_ref(const char *name,
if (!strncmp(name, "refs/tags/", 10)) {
fprintf(stderr, "* %s: updating with %s\n", name, note);
show_new(type, sha1_new);
- return update_ref("updating tag", name, sha1_new, NULL);
+ return update_ref_env("updating tag", name, sha1_new, NULL);
}
current = lookup_commit_reference(sha1_old);
@@ -117,7 +112,7 @@ static int update_local_ref(const char *name,
fprintf(stderr, "* %s: fast forward to %s\n",
name, note);
fprintf(stderr, " old..new: %s..%s\n", oldh, newh);
- return update_ref("fast forward", name, sha1_new, sha1_old);
+ return update_ref_env("fast forward", name, sha1_new, sha1_old);
}
if (!force) {
fprintf(stderr,
@@ -131,7 +126,7 @@ static int update_local_ref(const char *name,
"* %s: forcing update to non-fast forward %s\n",
name, note);
fprintf(stderr, " old...new: %s...%s\n", oldh, newh);
- return update_ref("forced-update", name, sha1_new, sha1_old);
+ return update_ref_env("forced-update", name, sha1_new, sha1_old);
}
static int append_fetch_head(FILE *fp,
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 8339cf1..2ed98e8 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -8,7 +8,6 @@ static const char git_update_ref_usage[] =
int cmd_update_ref(int argc, const char **argv, const char *prefix)
{
const char *refname=NULL, *value=NULL, *oldval=NULL, *msg=NULL;
- struct ref_lock *lock;
unsigned char sha1[20], oldsha1[20];
int i, delete, ref_flags;
@@ -62,10 +61,7 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
if (oldval && *oldval && get_sha1(oldval, oldsha1))
die("%s: not a valid old SHA1", oldval);
- lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL, ref_flags);
- if (!lock)
- die("%s: cannot lock the ref", refname);
- if (write_ref_sha1(lock, sha1, msg) < 0)
- die("%s: cannot update the ref", refname);
+ update_ref(msg, refname, sha1, oldval ? oldsha1 : NULL,
+ ref_flags, DIE_ON_ERR);
return 0;
}
diff --git a/refs.c b/refs.c
index 09a2c87..1343f0d 100644
--- a/refs.c
+++ b/refs.c
@@ -1455,3 +1455,31 @@ int for_each_reflog(each_ref_fn fn, void *cb_data)
{
return do_for_each_reflog("", fn, cb_data);
}
+
+int update_ref(const char *action, const char *refname,
+ const unsigned char *sha1, const unsigned char *oldval,
+ int flags, enum action_on_err onerr)
+{
+ static struct ref_lock *lock;
+ lock = lock_any_ref_for_update(refname, oldval, flags);
+ if (!lock) {
+ const char *str = "Cannot lock the ref '%s'.";
+ switch (onerr) {
+ case MSG_ON_ERR: error(str, refname); break;
+ case DIE_ON_ERR: die(str, refname); break;
+ case QUIET_ON_ERR: break;
+ }
+ return 1;
+ }
+ if (write_ref_sha1(lock, sha1, action) < 0) {
+ const char *str = "Cannot update the ref '%s'.";
+ switch (onerr) {
+ case MSG_ON_ERR: error(str, refname); break;
+ case DIE_ON_ERR: die(str, refname); break;
+ case QUIET_ON_ERR: break;
+ }
+ return 1;
+ }
+ return 0;
+}
+
diff --git a/refs.h b/refs.h
index f234eb7..6eb98a4 100644
--- a/refs.h
+++ b/refs.h
@@ -64,4 +64,10 @@ extern int rename_ref(const char *oldref, const char *newref, const char *logmsg
/** resolve ref in nested "gitlink" repository */
extern int resolve_gitlink_ref(const char *name, const char *refname, unsigned char *result);
+/** lock a ref and then write its file */
+enum action_on_err { MSG_ON_ERR, DIE_ON_ERR, QUIET_ON_ERR };
+int update_ref(const char *action, const char *refname,
+ const unsigned char *sha1, const unsigned char *oldval,
+ int flags, enum action_on_err onerr);
+
#endif /* REFS_H */
diff --git a/send-pack.c b/send-pack.c
index 9fc8a81..c59eea4 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -313,14 +313,9 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (delete_ref(rs.dst, NULL)) {
error("Failed to delete");
}
- } else {
- lock = lock_any_ref_for_update(rs.dst, NULL, 0);
- if (!lock)
- error("Failed to lock");
- else
- write_ref_sha1(lock, ref->new_sha1,
- "update by push");
- }
+ } else
+ update_ref("update by push", rs.dst,
+ ref->new_sha1, NULL, 0, 0);
free(rs.dst);
}
}
--
1.5.0
^ permalink raw reply related
* Re: [PATCH 2/3] archive: specfile support (--pretty=format: in archive files)
From: Junio C Hamano @ 2007-09-05 0:23 UTC (permalink / raw)
To: René Scharfe
Cc: Johannes Schindelin, Andreas Ericsson, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <46DDE69C.1080908@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>> Maybe we should not so much name it by purpose, but by function. How
>> about "substformat" for the attribute name, and replacing any
>> $Format:blablub$ inside those files with something a la
>> --pretty=format:blablub?
>
> I like the $Format:...$ notation. How about naming the attribute
> "template", as that's what a thus marked file is?
Sounds good, although I suspect "template" might confuse newbies
that checkout may apply the substitution as well. How about
something with "export" in it? export-subst, perhaps?
^ 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