* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 19:42 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm>
I was slowly writing a reply but it seems David beat me to it, so here
goes a couple of additional comments.
On Fri, Oct 24, 2008 at 9:11 PM, <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>> Running "git init" in an empty directory consumes about 100k of diskspace
>> on the machine I am typing this on, and you should be able to share most
>> of them (except one 41-byte file that is the branch tip ref) when you
>> track many files inside a single directory by using a single repository,
>> one branch per file (or "one set of branches per file") model.
>
> the reason to use seperate repos is to ease the work involved if you need to
> move that file (and it's repo) elsewhere.
Precisely. The one-repo-per-file is just the simplest and most
flexible solution. But yes, I have to admit I hadn't looked into disk
usage, and indeed we should try and squeeze this as much as possible.
> with the git directory being under .zit, would it be possible to link the
> things that are nessasary togeather?
I'm not sure about _which_ files could be shared.
> hmm, looking at this in more detail.
>
> about 44K of diskspace is used by the .sample hook files, so those can be
> removed
Exactly. I'm setting up zit to prepare its repos to a more compact
form, and getting rid of hooks and description is the first step.
> the remaining 56K is mostly directories eating up a disk block
>
> find . -ls
> 200367 4 drwxr-xr-x 7 dlang users 4096 Oct 24 12:00 .
> 200368 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./refs
> 200369 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
> ./refs/heads
> 200370 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
> ./refs/tags
> 200371 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
> ./branches
> 200372 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./hooks
> 200373 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./info
> 1798469 4 -rw-r--r-- 1 dlang users 240 Oct 24 12:00
> ./info/exclude
> 1600716 4 -rw-r--r-- 1 dlang users 58 Oct 24 12:00
> ./description
> 200374 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./objects
> 200375 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
> ./objects/pack
> 200376 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
> ./objects/info
> 1600717 4 -rw-r--r-- 1 dlang users 23 Oct 24 12:00 ./HEAD
> 1600719 4 -rw-r--r-- 1 dlang users 92 Oct 24 12:00 ./config
>
> how many of these are _really_ nessasary?
For starters, I'm wondering if setting core.preferSymlinkRefs would be
useful here. Does it break sometihng?
> tags, info, hooks, branches, and description could probably be skipped for
> the common zit case, as long as they can be created as needed.
It seems that tags, hooks, branches and description can be done with.
info contains exclude which is rather essential, and this is something
that could be shared across repositories. Also, we could spare a block
by removing info, moving exclude to the .git dir and setting
core.excludesfile appropriately
> the objects directory will eat up more space as revisions are checked in
> (and more sub-directories are created), would it make sense to have a config
> option to do a flat objects directory instead of the current fan-out?
This is probably the biggest remaining spacewaste. Typical zit usage
will generate a rather small number of objects, so flattening the
object store for the repo wouldn't be a bad idea. Is that possible?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Performance impact of a large number of commits
From: david @ 2008-10-24 19:43 UTC (permalink / raw)
To: Samuel Abels; +Cc: git
In-Reply-To: <1224874946.7566.13.camel@localhost>
On Fri, 24 Oct 2008, Samuel Abels wrote:
> Hi,
>
> I am considering Git to maintain a repository of approximately 300.000
> files totaling 1 GB, with a number of ~100.000 commits per day, all in
> one single branch. The only operations performed are "git commit", "git
> show", and "git checkout", and all on one local machine. Does this sound
> like a reasonable thing to do with Git?
100,000 commits per day??
that's 1.5 commits/second. what is updating files that quickly?
I suspect that you will have some issues here, but it's going to depend on
how many files get updated each 3/4 of a second.
David Lang
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: david @ 2008-10-24 19:46 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810241242y7467f6fexcca4b7cd768e7992@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> I was slowly writing a reply but it seems David beat me to it, so here
> goes a couple of additional comments.
>
> On Fri, Oct 24, 2008 at 9:11 PM, <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>>> Running "git init" in an empty directory consumes about 100k of diskspace
>>> on the machine I am typing this on, and you should be able to share most
>>> of them (except one 41-byte file that is the branch tip ref) when you
>>> track many files inside a single directory by using a single repository,
>>> one branch per file (or "one set of branches per file") model.
>>
>> the reason to use seperate repos is to ease the work involved if you need to
>> move that file (and it's repo) elsewhere.
>
> Precisely. The one-repo-per-file is just the simplest and most
> flexible solution. But yes, I have to admit I hadn't looked into disk
> usage, and indeed we should try and squeeze this as much as possible.
>
>> with the git directory being under .zit, would it be possible to link the
>> things that are nessasary togeather?
>
> I'm not sure about _which_ files could be shared.
>
>> hmm, looking at this in more detail.
>>
>> about 44K of diskspace is used by the .sample hook files, so those can be
>> removed
>
> Exactly. I'm setting up zit to prepare its repos to a more compact
> form, and getting rid of hooks and description is the first step.
>
>> the remaining 56K is mostly directories eating up a disk block
>>
>> find . -ls
>> 200367 4 drwxr-xr-x 7 dlang users 4096 Oct 24 12:00 .
>> 200368 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./refs
>> 200369 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
>> ./refs/heads
>> 200370 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
>> ./refs/tags
>> 200371 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
>> ./branches
>> 200372 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./hooks
>> 200373 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./info
>> 1798469 4 -rw-r--r-- 1 dlang users 240 Oct 24 12:00
>> ./info/exclude
>> 1600716 4 -rw-r--r-- 1 dlang users 58 Oct 24 12:00
>> ./description
>> 200374 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./objects
>> 200375 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
>> ./objects/pack
>> 200376 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00
>> ./objects/info
>> 1600717 4 -rw-r--r-- 1 dlang users 23 Oct 24 12:00 ./HEAD
>> 1600719 4 -rw-r--r-- 1 dlang users 92 Oct 24 12:00 ./config
>>
>> how many of these are _really_ nessasary?
>
> For starters, I'm wondering if setting core.preferSymlinkRefs would be
> useful here. Does it break sometihng?
>
>> tags, info, hooks, branches, and description could probably be skipped for
>> the common zit case, as long as they can be created as needed.
>
> It seems that tags, hooks, branches and description can be done with.
do you mean 'can be done away with'?
> info contains exclude which is rather essential,
is it? by default everything in this file is commented out. And with you
only adding files explicitly why would it ever need to excluded anything?
David Lang
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 19:51 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <alpine.DEB.1.10.0810241244170.27333@asgard.lang.hm>
On Fri, Oct 24, 2008 at 9:46 PM, <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>
>> It seems that tags, hooks, branches and description can be done with.
>
> do you mean 'can be done away with'?
Ahem. Yes. I've got a patch ready for zit that gets rid of them.
(A smarter way would be to create a template, but I'm not smart.)
>> info contains exclude which is rather essential,
>
> is it? by default everything in this file is commented out. And with you
> only adding files explicitly why would it ever need to excluded anything?
Zit does
echo "*" > $GIT_DIR/info/exclude
and yes it sucks to use a whole block for a file that only contains
one character. Suggestions welcome.
The reason why we want the exclude is that when you do zit status
somefile you don't want every other file in the directory to come up
as 'not tracked'.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: david @ 2008-10-24 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Giuseppe Bilotta, Jean-Luc Herren, git
In-Reply-To: <7vabct3l1e.fsf@gitster.siamese.dyndns.org>
On Fri, 24 Oct 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>
>>>> If you decide against a shared repository, maybe you want to
>>>> consider to not use ".zit.file/", but ".zit/file/" as the
>>>> repository? This would reduce the clutter to a single directory,
>>>> just like with ".git". And moving files around wouldn't be that
>>>> much complicated.
>>>
>>> Right. I'll give that a shot.
>>
>> By the way RCS which I use for version control of single files use
>> both approaches: it can store 'file,v' alongside 'file' (just like
>> your '.zit.file/' or '.file.git/'), but it can also store files on
>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>> '.zit/file.git/' solution)
>
> I am not opposed to the wish to track a single file (but I have to say I
> am not personally in need for such a feature), but I have to wonder from
> the technical point of view if one-repo-per-file is the right approach.
I just had what's probably a silly thought.
how close is a zit setup to a subproject setup?
David Lang
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: david @ 2008-10-24 19:54 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810241251w4c2486a0x4684a25b364ebbbb@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 9:46 PM, <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>>
>>> It seems that tags, hooks, branches and description can be done with.
>>
>> do you mean 'can be done away with'?
>
> Ahem. Yes. I've got a patch ready for zit that gets rid of them.
>
> (A smarter way would be to create a template, but I'm not smart.)
>
>>> info contains exclude which is rather essential,
>>
>> is it? by default everything in this file is commented out. And with you
>> only adding files explicitly why would it ever need to excluded anything?
>
> Zit does
> echo "*" > $GIT_DIR/info/exclude
> and yes it sucks to use a whole block for a file that only contains
> one character. Suggestions welcome.
can this be configured in the config file?
> The reason why we want the exclude is that when you do zit status
> somefile you don't want every other file in the directory to come up
> as 'not tracked'.
good point.
David Lang
^ permalink raw reply
* Re: Performance impact of a large number of commits
From: Samuel Abels @ 2008-10-24 19:56 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810241240100.27333@asgard.lang.hm>
On Fri, 2008-10-24 at 12:43 -0700, david@lang.hm wrote:
> 100,000 commits per day??
>
> that's 1.5 commits/second. what is updating files that quickly?
This is an automated process taking snapshots of rapidly changing files
containing statistical data. Unfortunately, our needs go beyond what a
versioning file system has to offer, and the data is an unstructured
text file (in other words, using a relational database is not a good
option).
> I suspect that you will have some issues here, but it's going to depend on
> how many files get updated each 3/4 of a second.
That would be 5 to 10 changed files per commit, and those are passed to
git commit explicitly (i.e., walking the tree to stat files for finding
changes is not necessary).
-Samuel
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 20:06 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <alpine.DEB.1.10.0810241251490.27333@asgard.lang.hm>
On Fri, Oct 24, 2008 at 9:53 PM, <david@lang.hm> wrote:
> I just had what's probably a silly thought.
>
> how close is a zit setup to a subproject setup?
Honestly, I haven't the slightest idea how they work. My
understanding, which could be completely wrong, is that they are
full-fledged git repositories, and that additional metadata at the top
level takes care of understanding what ref is needed for each toplevel
project. If this is true, using them wouldn't simplify zit, but rather
make it more complex (and space intensive).
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Performance impact of a large number of commits
From: david @ 2008-10-24 20:11 UTC (permalink / raw)
To: Samuel Abels; +Cc: git
In-Reply-To: <1224878202.7566.25.camel@localhost>
On Fri, 24 Oct 2008, Samuel Abels wrote:
> On Fri, 2008-10-24 at 12:43 -0700, david@lang.hm wrote:
>> 100,000 commits per day??
>>
>> that's 1.5 commits/second. what is updating files that quickly?
>
> This is an automated process taking snapshots of rapidly changing files
> containing statistical data. Unfortunately, our needs go beyond what a
> versioning file system has to offer, and the data is an unstructured
> text file (in other words, using a relational database is not a good
> option).
>
>> I suspect that you will have some issues here, but it's going to depend on
>> how many files get updated each 3/4 of a second.
>
> That would be 5 to 10 changed files per commit, and those are passed to
> git commit explicitly (i.e., walking the tree to stat files for finding
> changes is not necessary).
I suspect that your limits would be filesystem/OS limits more than git
limits
at 5-10 files/commit you are going to be creating .5-1m files/day, even
spread across 256 directories this is going to be a _lot_ of files.
packing this may help (depending on how much the files change), but with
this many files the work of doing the packing would be expensive.
David Lang
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 20:13 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <alpine.DEB.1.10.0810241254330.27333@asgard.lang.hm>
On Fri, Oct 24, 2008 at 9:54 PM, <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> Zit does
>> echo "*" > $GIT_DIR/info/exclude
>> and yes it sucks to use a whole block for a file that only contains
>> one character. Suggestions welcome.
>
> can this be configured in the config file?
Yes, the file pointed at by the config key core.excludesfile is read
too, so we could have it point at $GIT_DIR/zitexclude, which would
allow us to spare a block. The most space saving would be achieved by
a core.excludepattern or similar key, which would allow us to get rid
of the exclude file altogether.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 20:30 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: David Lang, Junio C Hamano, Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810241313o341febccgbea1cd59b25b9cc4@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 9:54 PM, <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>> Zit does
>>> echo "*" > $GIT_DIR/info/exclude
>>> and yes it sucks to use a whole block for a file that only contains
>>> one character. Suggestions welcome.
>>
>> can this be configured in the config file?
>
> Yes, the file pointed at by the config key core.excludesfile is read
> too, so we could have it point at $GIT_DIR/zitexclude, which would
> allow us to spare a block. The most space saving would be achieved by
> a core.excludepattern or similar key, which would allow us to get rid
> of the exclude file altogether.
Well, with all zit repositories in '.zit/' directory (similar to RCS/)
you could have point core.excludesfile to _common_ '.zit/excludes';
the pattern doesn't change from zit repository to zit repository?
You could even use per-user ~/.zitignore (I'm not sure if git expands
'~' in paths; there was some patch for it, but was it accepted?) or
system-wide /usr/lib/zitignore or /usr/libexec/zitignore file.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-daemon and hook output
From: Miklos Vajna @ 2008-10-24 20:39 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20081024050713.GA21548@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Fri, Oct 24, 2008 at 01:07:13AM -0400, Joey Hess <joey@kitenet.net> wrote:
> I ran into this in a real-world application -- I'm implementing
> anonymous pushes into ikiwiki, which are checked pre-receive to limit
> them to changes that could be done via the web interface. So all my nice
> error messages about why a commit is refused are not available, which is
> a pity.
I think the recommended protocol even for anonymous push is ssh, at
least that's what repo.or.cz uses for the 'mob' user, which is
equivalent to anonymous, AFAIK.
(The source is available under repo.git, I did not have a look how one
can set up an account - using git-shell - that can be used without a
password.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-daemon and hook output
From: Shawn O. Pearce @ 2008-10-24 20:42 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Joey Hess, git
In-Reply-To: <20081024203943.GV26961@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Oct 24, 2008 at 01:07:13AM -0400, Joey Hess <joey@kitenet.net> wrote:
> > I ran into this in a real-world application -- I'm implementing
> > anonymous pushes into ikiwiki, which are checked pre-receive to limit
> > them to changes that could be done via the web interface. So all my nice
> > error messages about why a commit is refused are not available, which is
> > a pity.
>
> I think the recommended protocol even for anonymous push is ssh, at
> least that's what repo.or.cz uses for the 'mob' user, which is
> equivalent to anonymous, AFAIK.
Nah. git:// supports anonymous push. For some applications its
just what people want. I say the original change is worthwhile;
expose the remote address and let a hook do logging and/or denials
based on its own logic.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Junio C Hamano @ 2008-10-24 21:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Sixt, Matthieu Moy
In-Reply-To: <20081024025330.GC2831@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is much cleaner. I have a nagging worry that a
> text-converted filespec might live longer than I expect. Maybe it would
> make sense to free the filespec data after the diff has been generated
> (and then further populate_filespec calls would just restore the
> original data).
Either that or drop data_is_textconv and have two sets of <ptr,size> pair
in filespec, one for real data and another purely for diff text
generation.
But I have a very naïve question.
Why isn't this just primarily a patch to diff.c::builtin_diff() function?
That is, you let fill_mmfile() to fill the real data in mf1 and mf2 as
before, ask one/two if they have textconv, and if so, convert mf1 and mf2
in place, and let xdl work on it, like...
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
+ if (has_textconv(one))
+ apply_textconv(one, &mf1);
+ if (has_textconv(two))
+ apply_textconv(two, &mf2);
if (!DIFF_OPT_TST(o, TEXT) &&
- (diff_filespec_is_binary(one) || diff_filespec_is_binary(two))) {
+ ( (diff_filespec_is_binary(one) && !has_textconv(one)) ||
+ (diff_filespec_is_binary(two) && !has_textconv(two)) )) {
/* Quite common confusing case */
...
}
else {
/* Crazy xdl interfaces.. */
const char *diffopts = getenv("GIT_DIFF_OPTS");
...
^ permalink raw reply
* RE: git history and file moves
From: Moore, Robert @ 2008-10-24 21:30 UTC (permalink / raw)
To: Michael J Gruber, Lin, Ming M; +Cc: Alex Riesen, git@vger.kernel.org
In-Reply-To: <48FF1EDB.8010503@drmicha.warpmail.net>
Here's what we have:
/var/www/cgi-bin/gitweb.acpica/gitweb.conf
Containts this : GITWEB_CSS = "/icons/gitweb.css";
What should we add to automatically get all file history?
Thanks,
Bob
>-----Original Message-----
>From: Michael J Gruber [mailto:git@drmicha.warpmail.net]
>Sent: Wednesday, October 22, 2008 5:39 AM
>To: Lin, Ming M
>Cc: Alex Riesen; git@vger.kernel.org; Moore, Robert
>Subject: Re: git history and file moves
>
>Alex Riesen venit, vidit, dixit 10/22/08 13:19:
>> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>>> I'm looking for a way to move files to a new directory and have the
>>> full history follow the file automatically. Is this possible?
>>>
>>> I know about --follow, but I want the history to just follow the file
>>> transparently. ...
>>
>> Of all Git tools, what does not do this "transparently" or
>"automatically"?
>> How more transparent do you imagine this?
>> What do you think should follow what?
>>
>> I ask, because it is hard to understand what exactly is it you're
>missing:
>> merge support (which we have), git log listing the files as
>copied/renamed
>> (which is what --follow is for, and the suggestion for you is to make an
>> alias or something), git blame (ever looked at git gui blame?) or gitk
>> (which follows renames in default configuration)
>>
>>> Also, we have a git web interface and we want the full
>>> history for the moved files to be available.
>>
>> It is available. Whether it is shown is another question. git-web can
>> be improved (or just configured?)
>
>By default, gitweb uses "-M" for diff. You can specify all options (-C,
>-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
>is what you are using. Is it?
>
>Anyways, using default configs for git log and gitweb.cgi both of them
>show the full history (renames, history before and after) for me here,
>using current git (1.6.0.3.514.g2f91b). What is your setup?
>
>Michael
^ permalink raw reply
* Re: git history and file moves
From: Alex Riesen @ 2008-10-24 21:43 UTC (permalink / raw)
To: Moore, Robert; +Cc: Michael J Gruber, Lin, Ming M, git@vger.kernel.org
In-Reply-To: <4911F71203A09E4D9981D27F9D8308580AA7FFFB@orsmsx503.amr.corp.intel.com>
2008/10/24 Moore, Robert <robert.moore@intel.com>:
> Here's what we have:
>
> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>
> Containts this : GITWEB_CSS = "/icons/gitweb.css";
>
> What should we add to automatically get all file history?
>
Nothing. It is the default. You can change the variable Michael
mentioned to use "-M -M -C -C" but it is very-very slow on any
kind of history worth its commits.
And you almost never talk about _file_ history in Git. It is all
_project_ history, filtered for commits which touch the file you're
interested in at the moment of looking.
^ permalink raw reply
* [PATCH] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-24 21:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-add--interactive.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..a560133 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -811,11 +811,16 @@ EOF
}
sub patch_update_cmd {
- my @mods = grep { !($_->{BINARY}) } list_modified('file-only');
+ my @all_mods = list_modified('file-only');
+ my @mods = grep { !($_->{BINARY}) } @all_mods;
my @them;
if (!@mods) {
- print STDERR "No changes.\n";
+ if (@all_mods) {
+ print STDERR "No changes except to binary files.\n";
+ } else {
+ print STDERR "No changes.\n";
+ }
return 0;
}
if ($patch_mode) {
--
tg: (759ad19..) t/add-p-binary-warn (depends on: origin/master)
^ permalink raw reply related
* Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Junio C Hamano @ 2008-10-24 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810240853310.3287@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The "git buglet" looks liek this:
>
> - build a kernel
>
> - do "git clean -dqfx". This fails with
>
> warning: failed to remove 'include/config/'
>
> - do "git clean -dqfx" again. And now it works - apparently because the
> first invocation deleted enough of the big directory.
>
> Doing an 'strace' to see what is going on, I see:
>
> ..
> getdents(3, /* 132 entries */, 4096) = 3888
> lstat("include/config/sgi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> open("include/config/sgi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
> fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents(4, /* 3 entries */, 4096) = 80
> lstat("include/config/sgi/partition.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> unlink("include/config/sgi/partition.h") = 0
> getdents(4, /* 0 entries */, 4096) = 0
> close(4) = 0
> rmdir("include/config/sgi") = 0
> lstat("include/config/sgi", 0x7fffdc4d2110) = -1 ENOENT (No such file or directory)
> close(3) = 0
> write(2, "warning: failed to remove \'include/config/\'\n", 44) = 44
> ..
>
> and notice how it does that
>
> lstat("include/config/sgi", ..
>
> _twice_. That, in turn (knowing the git implementation), implies that it
> was returned twice from that first "getdents(3, ...)" call.
>
> So what git clean does is to scan over the readdir() return values, see if
> it's a file it knows about, try to remove it if not, lstat() every entry,
> recurse into them if they are directories, and then remove it. If the
> lstat() fails, "git clean" will fail.
Hmm, interesting.
-- >8 --
Subject: allow readdir(3) to return the same entry twice
When removing a large directory recursively, repeatedly running unlink(2)
on what we read from readdir(3) can cause readdir(3) (or underlying
getdents(2)) to return the same entry twice. If we have already removed
it, running lstat() on the entry would fail with ENOENT, but there is no
harm if we ignore such an error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git i/dir.c w/dir.c
index 0131983..293df4e 100644
--- i/dir.c
+++ w/dir.c
@@ -800,8 +800,11 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
strbuf_setlen(path, len);
strbuf_addstr(path, e->d_name);
- if (lstat(path->buf, &st))
- ; /* fall thru */
+ if (lstat(path->buf, &st)) {
+ if (errno == ENOENT)
+ continue;
+ /* otherwise fall thru */
+ }
else if (S_ISDIR(st.st_mode)) {
if (!remove_dir_recursively(path, only_empty))
continue; /* happy */
^ permalink raw reply related
* RE: git history and file moves
From: Moore, Robert @ 2008-10-24 22:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael J Gruber, Lin, Ming M, git@vger.kernel.org
In-Reply-To: <81b0412b0810241443t75e2022fg984df400585cb254@mail.gmail.com>
What we are seeing is an issue after we do a file move to a new directory. Once moved, the previous history of the file is not readily available. One needs to know to use --follow on the command line, and worse, gitweb does not show the full history at all.
We have almost a decade of history on the project, from several different source control systems. We often find it useful to go back and find out when something changed, so we want to keep it and have it easily available.
>-----Original Message-----
>From: Alex Riesen [mailto:raa.lkml@gmail.com]
>Sent: Friday, October 24, 2008 2:43 PM
>To: Moore, Robert
>Cc: Michael J Gruber; Lin, Ming M; git@vger.kernel.org
>Subject: Re: git history and file moves
>
>2008/10/24 Moore, Robert <robert.moore@intel.com>:
>> Here's what we have:
>>
>> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>>
>> Containts this : GITWEB_CSS = "/icons/gitweb.css";
>>
>> What should we add to automatically get all file history?
>>
>
>Nothing. It is the default. You can change the variable Michael
>mentioned to use "-M -M -C -C" but it is very-very slow on any
>kind of history worth its commits.
>
>And you almost never talk about _file_ history in Git. It is all
>_project_ history, filtered for commits which touch the file you're
>interested in at the moment of looking.
^ permalink raw reply
* Re: git history and file moves
From: Jakub Narebski @ 2008-10-24 22:13 UTC (permalink / raw)
To: Moore, Robert
Cc: Michael J Gruber, Lin, Ming M, Alex Riesen, git@vger.kernel.org
In-Reply-To: <4911F71203A09E4D9981D27F9D8308580AA7FFFB@orsmsx503.amr.corp.intel.com>
"Moore, Robert" <robert.moore@intel.com> writes:
>
> Thanks,
> Bob
>
> >-----Original Message-----
>Michael J Gruber wrote:
>>Alex Riesen venit, vidit, dixit 10/22/08 13:19:
>>> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>>>> I'm looking for a way to move files to a new directory and have the
>>>> full history follow the file automatically. Is this possible?
>>>>
>>>> I know about --follow, but I want the history to just follow the file
>>>> transparently. ...
>>>
>>> Of all Git tools, what does not do this "transparently" or "automatically"?
[...]
>>>> Also, we have a git web interface and we want the full
>>>> history for the moved files to be available.
>>>
>>> It is available. Whether it is shown is another question. git-web can
>>> be improved (or just configured?)
>>
>> By default, gitweb uses "-M" for diff. You can specify all options (-C,
>> -CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
>> is what you are using. Is it?
>>
>> Anyways, using default configs for git log and gitweb.cgi both of them
>> show the full history (renames, history before and after) for me here,
>> using current git (1.6.0.3.514.g2f91b). What is your setup?
>
> Here's what we have:
>
> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>
> Containts this : GITWEB_CSS = "/icons/gitweb.css";
This fragment has nothing to do with rename (file movement) detection.
>
> What should we add to automatically get all file history?
While the 'commitdiff' view would, in default gitweb configuration,
contain information about file renames, currently 'history' view does
not support '--follow' option to git-log. It wouldn't be too hard to
add it, but it just wasn't done (well, add to this the fact that
--follow works only for simple cases).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-24 22:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gdsjb1$eob$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> * gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
>> - gitweb: generate parent..current URLs
>> - gitweb: parse parent..current syntax from PATH_INFO
>> - gitweb: use_pathinfo filenames start with /
>> - gitweb: generate project/action/hash URLs
>> - gitweb: parse project/action/hash_base:filename PATH_INFO
>>
>> Seventh iteration; hopefully the usual gitweb gangs will give quick
>> comments and ack to push this out to 'next' soon.
>
> If I remember correctly v7 is mainly cosmetic changes, and I have
> acked all or almost all of the equivalent patches from v6.
I take it to mean you reviewed v7 and we have your Ack on them;
thanks.
^ permalink raw reply
* Re: [PATCH] Fixed git archive for bare repos
From: René Scharfe @ 2008-10-24 22:19 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Deskin Miller, kenneth johansson, gitster
In-Reply-To: <1224712023-5280-1-git-send-email-charles@hashpling.org>
Charles Bailey schrieb:
> This moves the call to git config to a place where it doesn't break
> the logic for using git archive in a bare repository but retains the
> fix to make git archive respect core.autocrlf.
If one combines your patch, Deskin's commit message and test and extends
on the latter a bit then I think we have a winner. :)
Here are a few more tests which create a ZIP file in addition to a tar
archive and compare them to their non-bare counterparts.
Care to resend?
Thanks,
René
t/t5000-tar-tree.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index e395ff4..bf5fa25 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -58,6 +58,11 @@ test_expect_success \
git commit-tree $treeid </dev/null)'
test_expect_success \
+ 'create bare clone' \
+ 'git clone --bare . bare.git &&
+ cp .gitattributes bare.git/info/attributes'
+
+test_expect_success \
'remove ignored file' \
'rm a/ignored'
@@ -74,6 +79,14 @@ test_expect_success \
'diff b.tar b2.tar'
test_expect_success \
+ 'git archive in a bare repo' \
+ '(cd bare.git && git archive HEAD) >b3.tar'
+
+test_expect_success \
+ 'git archive vs. the same in a bare repo' \
+ 'test_cmp b.tar b3.tar'
+
+test_expect_success \
'validate file modification time' \
'mkdir extract &&
"$TAR" xf b.tar -C extract a/a &&
@@ -151,6 +164,14 @@ test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD >d.zip'
+test_expect_success \
+ 'git archive --format=zip in a bare repo' \
+ '(cd bare.git && git archive --format=zip HEAD) >d1.zip'
+
+test_expect_success \
+ 'git archive --format=zip vs. the same in a bare repo' \
+ 'test_cmp d.zip d1.zip'
+
$UNZIP -v >/dev/null 2>&1
if [ $? -eq 127 ]; then
echo "Skipping ZIP tests, because unzip was not found"
^ permalink raw reply related
* Re: Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Linus Torvalds @ 2008-10-24 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsfx1wnb.fsf_-_@gitster.siamese.dyndns.org>
On Fri, 24 Oct 2008, Junio C Hamano wrote:
>
> Subject: allow readdir(3) to return the same entry twice
The thing is, this really is a kernel bug. We have even bisected it (and
it hasn't hit any released kernel). The original reporter showed it with a
simple "rm -r".
So it really isn't a git bug, even though I initially thought it might be,
before I looked closer.
That said, the git patch may be worth it just because two *concurrent*
invocations of "git clean" could then cause one (or both) to fail this
way.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: William Pursell @ 2008-10-24 22:32 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081023064455.GA10675@hashpling.org>
Charles Bailey wrote:
>
> After more thoughts, I'm somewhat in favour of dropping the short
> switch altogether. As it just saves a single keypress per merge I
> imagine that most mergetool users, once they discover this new
> feature and decide that they want to use it, will prefer to use a user
> config option to switch it on. The command line option then becomes
> something that you would only need to use to override your normal
> default and something on which to hang the option description in the
> man page.
If the short option is dropped, the config option should
probably associated with mergetool.<tool>.interactive rather
than mergetool.interactive. (s/interactive/whatever)
--
William Pursell
^ permalink raw reply
* Re: Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Junio C Hamano @ 2008-10-24 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810241524350.3287@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>>
>> Subject: allow readdir(3) to return the same entry twice
>
> The thing is, this really is a kernel bug. We have even bisected it (and
> it hasn't hit any released kernel). The original reporter showed it with a
> simple "rm -r".
>
> So it really isn't a git bug, even though I initially thought it might be,
> before I looked closer.
>
> That said, the git patch may be worth it just because two *concurrent*
> invocations of "git clean" could then cause one (or both) to fail this
> way.
Yeah, or on perhaps a buggy implementation of readdir(3) on somebody
else's system. In either case, I just thought it might be a low impact
belt-and-suspenders fix that is worth considering.
^ 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