* [PATCH] Unclutter cg status with --directory as GIT does
From: Paolo 'Blaisorblade' Giarrusso @ 2006-01-19 21:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Pass the new --directory option (from git 1.1) to git-ls-others for
list_untracked_files, as does git-status - it's very useful.
Probably this must be deferred to when the git 1.1 dependency is added, however
please queue it for then.
Thanks.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 30e2ee9..539c885 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -206,7 +206,7 @@ list_untracked_files()
fi
EXCLUDE="$EXCLUDE --exclude-per-directory=.gitignore"
fi
- git-ls-files -z --others $EXCLUDE
+ git-ls-files -z --others --directory $EXCLUDE
}
# Usage: showdate SECONDS TIMEZONE [FORMAT]
^ permalink raw reply related
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Linus Torvalds @ 2006-01-19 21:16 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119203428.GA5090@trixie.casa.cgf.cx>
On Thu, 19 Jan 2006, Christopher Faylor wrote:
>
> Btw, we're looking to roll out a new release of cygwin which fixes the
> embarrassing typo in sockaddr_storage. It is fixed in cygwin snapshots:
>
> http://cygwin.com/snapshots/
Quick question for cygwin people (I asked this at an earlier point, but I
don't think there was any reply): would cygwin prefer using "vfork()" over
"fork()", or is there no advantage? With vfork(), I could imagine that you
might avoid a lot of strange VM games..
I think almost all of the git fork usage is of the type where "vfork()"
would work fine (git-daemon in non-inetd form is an exception, perhaps the
only one).
So if using vfork() is preferable, we probably should do that. It tends to
be a small performance improvement on Linux too, although on Linux it's
really pretty much in the noise.
Alternatively, is there anything else we can do that makes things easier?
Linus
^ permalink raw reply
* [PATCH] local push/pull env cleanup
From: Matt Draisey @ 2006-01-19 20:58 UTC (permalink / raw)
To: git
From: Matt Draisey <matt@draisey.ca>
remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation
---
connect.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/connect.c b/connect.c
index d6f4e4c..50cc879 100644
--- a/connect.c
+++ b/connect.c
@@ -644,8 +644,13 @@ int git_connect(int fd[2], char *url, co
ssh_basename++;
execlp(ssh, ssh_basename, host, command, NULL);
}
- else
+ else {
+ unsetenv("GIT_DIR");
+ unsetenv("GIT_INDEX_FILE");
+ unsetenv("GIT_OBJECT_DIRECTORY");
+ unsetenv("GIT_ALTERNATE_OBJECT_DIRECTORIES");
execlp("sh", "sh", "-c", command, NULL);
+ }
die("exec failed");
}
fd[0] = pipefd[0][0];
^ permalink raw reply related
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060119161000.GA27888@trixie.casa.cgf.cx>
On Thu, Jan 19, 2006 at 11:10:00AM -0500, Christopher Faylor wrote:
>On Thu, Jan 19, 2006 at 12:59:57AM -0800, Junio C Hamano wrote:
>>Christopher Faylor <me@cgf.cx> writes:
>>>"They" probably would like to hear about any irregularities that are
>>>found. "They" probably don't like it when people treat an open source
>>>project as if it was some unresponsive proprietary enterprise which
>>>does not listen to or accept patches.
>>
>>First of all, thanks for joining our discussion.
>
>You're welcome. I use git on linux and cygwin so I'm happy to try to help.
Btw, we're looking to roll out a new release of cygwin which fixes the
embarrassing typo in sockaddr_storage. It is fixed in cygwin snapshots:
http://cygwin.com/snapshots/
cgf
^ permalink raw reply
* Re: Something wrong with pickaxe?
From: Andreas Ericsson @ 2006-01-19 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <7vfynkdqj1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>>... I give it a function name to search for and want to
>>know when the calling semantics changed for that function.
>
>
> "Calling semantics" meaning "function signature"?
>
Yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Support precise tracking of file modes
From: Petr Baudis @ 2006-01-19 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, Adam Hunt, git
In-Reply-To: <7vacdsdqio.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jan 19, 2006 at 07:25:03PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
> > attitude to testing and documentation... ;-)
>
> It is premature for us mere mortals to imitate Linus in that
> aspect by at least ten years ;-). Please don't.
Yes, it was really just kind of proof-of-concept patch.
> About the content of the change, if we were to do this, we need
> to also record owner and group. recording full permissions
> without recording owner and group does not make much sense.
This would require much larger changes to the tree structure while we
can get this essentially for free and I believe it covers most of the
usage scenarios. In my /etc, all but two files are owned by root.root,
and in my ~, all the dot-files are owned by pasky.users, while the
permissions are a lot more varied.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 18:31 UTC (permalink / raw)
To: Alex Riesen, git
In-Reply-To: <81b0412b0601190242m4792e73bg181172e478b6e0c2@mail.gmail.com>
On Thu, Jan 19, 2006 at 11:42:46AM +0100, Alex Riesen wrote:
>On 1/19/06, Christopher Faylor <me@cgf.cx> wrote:
>>"They" probably don't like it when people treat an open source project
>>as if it was some unresponsive proprietary enterprise which does not
>>listen to or accept patches.
>
>Please, accept my appologies for the sarcasm in the original post.
>Sometimes I get an impression of cygwin being not maintained at all,
>and that, if not justifies my behavior, but at least is an attempt to
>explain it.
Hmm. I thought we'd already dispelled the myth that cygwin is
unsupported in this very mailing list. That is an odd impression given
the fact that you were complaining about behavior in a version of cygwin
which was released on Monday but, apology accepted.
If you want to see evidence of continual cygwin development, you can always
visit this page: http://cygwin.com/snapshots/ . This page has snapshots
of cygwin built from cvs. We make these available so that people will check
things out prior to an actual release.
>>>And on top of that, they removed dirent->d_ino (or probably replaced it
>>>by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
>>>referenced only in fsck-objects.c Anyway, to workaround this I put
>>>
>>>COMPAT_CFLAGS += -Dd_ino=__ino32
>>>
>>>It helps, but surely is not the solution.
>>
>>I don't see how it could help since __ino32 is not actually filled in
>>with anything. In fact, I'll rename the field to __invalid_ino32 to
>>make that clear.
>
>But why keep the DT_-macros?! And why there is two fields hinting at
>d_ino, and why there is 3 (!)
The default entry (i.e., the one you get without defining
__INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the
correct one.
>"struct dirent" definitions in dirent.h (sys/dirent.h)? Some with
>different names (d_reserved?). And if cygwin is aiming for posix, what
>would d_fd or d_version be (Open Group Specs v6[1] mention only d_ino
>and d_name)?
>
>[1]
>http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
Hmm. On linux, my /usr/include/bits/dirent.h has a d_reclen field in
dirent. I know what that is and what it is used for but it's not
mentioned, that I can see, in SUSv3. But, since I don't see anything in
the description of dirent in SUSv3 which says that the must have only
the fields mentiond, that's ok.
In any event, we don't claim to be POSIX compatible. We actually are
working for linux compatibility but this is one regrettable place where
Windows doesn't allow that.
I explained about the DT macros and why we dropped d_ino support in
another message.
Anyway, I understand why the DT macros would cause problems and I have
removed them from the current CVS. I don't see why the existence of
extra fields in dirent or why other non-default definitions would
cause any problems other than the "Doctor, doctor, it hurts when I
do this" variety.
cgf
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-19 18:28 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Alex Riesen, git
In-Reply-To: <81b0412b0601190701g2696b1a9l14f3d288875e11ab@mail.gmail.com>
On Thu, Jan 19, 2006 at 04:01:19PM +0100, Alex Riesen wrote:
>On 1/19/06, Junio C Hamano <junkio@cox.net> wrote:
>> By the way, if you have an access to git on cygwin with FAT,
>> could you test your patch ($SECONDS) and then i-num patch (the
>> machine with cygwin I can borrow has only NTFS) please?
>
>Works if sleep is for 2 secs (I completely forgot about that stupid
>FAT granularity!)
>st_ino is always the same (it is a hash of pathname).
>Christopher, how is that supposed to work with hardlinks? (NTFS has
>hardlinks, BTW)
There is OS support hardlinks work on NTFS/NT but not on FAT*
"filesystems" or Windows 9x variants. Hardlink support on Cygwin
mirrors this.
cgf
^ permalink raw reply
* Re: [PATCH] Support precise tracking of file modes
From: Junio C Hamano @ 2006-01-19 18:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Ryan Anderson, Adam Hunt, git
In-Reply-To: <20060119094156.GY28365@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
> attitude to testing and documentation... ;-)
It is premature for us mere mortals to imitate Linus in that
aspect by at least ten years ;-). Please don't.
About the content of the change, if we were to do this, we need
to also record owner and group. recording full permissions
without recording owner and group does not make much sense.
^ permalink raw reply
* Re: Something wrong with pickaxe?
From: Junio C Hamano @ 2006-01-19 18:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <43CF5816.1010004@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> True again. It is hard to be "more friendly" without actually
>> generating a diff ;-).
>
> I thought generating diffs was fairly cheap...
Probably. But we currently do not do diff generation
internally, so the comparison is "now doing diff with N lines of
code" vs "having 0 lines of code to do diff".
> ... I give it a function name to search for and want to
> know when the calling semantics changed for that function.
"Calling semantics" meaning "function signature"?
^ permalink raw reply
* Re: Joining Repositories
From: Junio C Hamano @ 2006-01-19 18:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Mathias Waack, git
In-Reply-To: <20060118141442.GP28365@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> oops, it seems this is only in the latest pu branch of git. If you are
> not brave enough for that, you will need to use the prefix facility of
> checkout-index instead, and it'll take much longer:
>...
> Note that I'm not sure when which feature was introduced. Your best
> bet is to just use the latest stable GIT/Cogito versions.
The "read-tree --prefix" and friends were only talked about
during the "bind" commit discussion, and with some experimental
code in "pu". Here is my thought on their readiness:
- "read-tree --prefix=<prefix>/" may independently be useful
even if we choose not to go "bind" commit approach. However
what it does when the index already has something at
<prefix>/ has room for improvement. I think it should have
an option to do an equivalent of either one-way merge or
two-way merge for that part of subtree. Currently it always
rejects if the current index has anything there.
- "write-tree --prefix=<prefix>/" is redundant for the purpose
of "bind" commit, because we would write the whole tree to be
recorded in the enclosing project and it is easy to pick the
subproject part with ls-tree from such a tree. So it needs
an independent advocate / rationale before graduating from
"pu".
- "write-tree --bound=<prefix>/ --bound=<prefix>/ ..." cannot
be emulated by any other way and may be independently useful
outside "bind" commit context. Maybe the option should be
renamed to --exclude=<prefix>/ or somesuch before going to
"master".
- "commit-tree --bind" should stay in "pu" until other pieces
to correctly deal with commit objects with "bind" lines are
ready, including fsck-objects and rev-list. It _might_ be
safer to bump the core.repositoryformatversion automatically
once you have such a commit object in your repo.
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Junio C Hamano @ 2006-01-19 18:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, Christopher Faylor
In-Reply-To: <81b0412b0601190701g2696b1a9l14f3d288875e11ab@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> Works if sleep is for 2 secs (I completely forgot about that stupid
> FAT granularity!)
> st_ino is always the same (it is a hash of pathname).
> Christopher, how is that supposed to work with hardlinks? (NTFS has
> hardlinks, BTW)
So the verdict is to take your patch but wait for three seconds?
I still have mild aversion about $SECONDS though...
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Junio C Hamano @ 2006-01-19 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Franck, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601190842270.3240@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> - a full clone takes a long time. Git _could_ fairly easily have an
> extension to add a date specifier to clone too:
>
> git clone --since=1.month.ago <source> <dst>
>
> and just leave any older stuff (you could always fetch it later), but
> we've just never done it. Maybe we should. It _should_ be pretty simple
> to do from a conceptual standpoint.
True, except some implementation details you forgot to mention
in your other message that you talked about upload-version.
Both commit walkers and git native transfer fundamentally
operate by trusting that our current refs are complete, which
makes "could always fetch it later" part a bit involved.
It fortunately would not be a rocket science. We would need to
have a mode "do not trust our current refs are complete" with an
explicit command line option, or automatically fall back to that
mode when seeing the $GIT_DIR/info/grafts file has changed, and
revalidate the commit ancestry chain we have in a repository
cloned that way.
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Junio C Hamano @ 2006-01-19 18:24 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <cda58cb80601190251v5251c8bdh@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> I don't see why it is so bad to create a "grafted" repository ? I want
> it to be small but still want to merge by using git-resolve with XX
> repository.
Franck, and people on the list,
I have a bad habit of responding to a "call for help" request by
stating how things are currently done and why, sometimes with an
outline of how the limitation in the current way can be (or at
least I think it could be, without testing that solution myself)
worked around, but without making it explicit if the limitation
is something that should not be there or if it is something
fundamental. This often makes it sound as if I am saying I
think the original request is unreasonable, and/or the current
state of affairs is perfect. This is one of such cases.
I agree it would be nice to support "strictly speaking, the
repository is incomplete but has everything necessary as long as
you operate near the tip of the development" mode of operation.
It only has never been a high priority.
> Well in my graft file I did:
>
> $ cat > .git/info/grafts
> <shaid> <shaid>
>
> $
The trailing empty line at the end is discarded as a comment, I
think, so that should be fine. "terminated by a newline" in the
documentation talks about each line being terminated by a LF,
not about terminating the file itself with an extra newline.
I think you spotted a bug in a documentation and another in the
code. I presume these two <shaid> are the same in what you did;
you are saying "this commit has itself as its parent", but that
can never be the case and the graft parser should reject such
line and complain but I do not think the current code does so.
The documentation says "a commit and its fake parents ...
separated by a space and terminated by a newline". We should at
least say "zero or more fake parents", or make it ever clearer
by giving a couple of examples.
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Linus Torvalds @ 2006-01-19 17:49 UTC (permalink / raw)
To: Franck; +Cc: Petr Baudis, Junio C Hamano, Git Mailing List
In-Reply-To: <cda58cb80601190933o4cedde92x@mail.gmail.com>
On Thu, 19 Jan 2006, Franck wrote:
>
> that would be great ! something like:
>
> git clone --since=v2.6.15 <src> <dst>
>
> would be very useful for me. How would it work ? Does it automatically
> set up a graft file for me ?
I think we'd have to set up the grafts file, yes. However, it's actually
less of an advantage than you'd think: especially for long development
histories, the incremental packing is very very efficient. In contrast, if
you only get recent versions, there's nothing to be incremental against,
so the size of the pack will not be that much smaller.
So getting just a tenth of the development history will _not_ cause the
pack to be just a tenth in size. It's probably closer to half the size of
the full history.
Anyway, it's _conceptually_ something that git wouldn't have any problems
with, but that doesn't mean that it's totally trivial either. The easiest
way to do it (by far) would be to expand the native git protocol with a
"get all objects of this one version" or something like that, and then
you'd just do a "pull and mark all unknown commits in the grafts file".
So in effect, instead of getting the whole history pack, you'd get a pack
that contains _one_ version (no history at all), and then (if you want to)
you can get a pack that gets all stuff that isn't reachable from that one
(ie "newer").
That would have the advantage that it's quite possible that many users
might want to do just
git clone --only=v2.6.15 <source> <target>
which would do that "one single version" variant of the clone. Then, later
on, you could just do
git pull --graft-unknown <source> <target>
to update the history.
Anybody want to try that? It would be a new command to "git-daemon"
(instead of "git-upoload-pack", you'd do a new "git-upload-version"
command internally: it would look a lot like upload-pack, and use the same
unpacking protocol).
> but it's really a pain to run for example git-repack or git-prune commands.
Well, you really don't need to do that very often.
Linus
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Petr Baudis @ 2006-01-19 17:45 UTC (permalink / raw)
To: Andreas Ericsson, torvalds; +Cc: Git Mailing List
In-Reply-To: <43CF97AF.9060300@op5.se>
Dear diary, on Thu, Jan 19, 2006 at 02:44:15PM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Ach, no. The current kernel repo only has history since April 17 (around
> 155 MB of objects, with less than optimal packing), when it started
> using git for versioning. The kernel repo also sees a lot of very rapid
> development.
>
> The full kernel tree, with history since 1991 or some such, is about 3.2
> GB.
There is some "accurate" history only from the moment the kernel got
tracked in BK, and it is certainly far less.
The question is, what is the "official" kernel history repository?
There is at least
http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
with a 251M pack and
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
with a 165M pack - IIRC the latter is obsoleted by the former and
perhaps should be blasted to prevent confusion?
Getting a little offtopic here... Linus, would it be deemed useful to
have the script I've pasted in <20060119130519.GB28365@pasky.or.cz>
(earlier in this thread) in the kernel's scripts/ directory, pointing at
the canonical history repository?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Franck @ 2006-01-19 17:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601190842270.3240@g5.osdl.org>
2006/1/19, Linus Torvalds <torvalds@osdl.org>:
> - a full clone takes a long time. Git _could_ fairly easily have an
> extension to add a date specifier to clone too:
>
> git clone --since=1.month.ago <source> <dst>
>
> and just leave any older stuff (you could always fetch it later), but
> we've just never done it. Maybe we should. It _should_ be pretty simple
> to do from a conceptual standpoint.
>
that would be great ! something like:
git clone --since=v2.6.15 <src> <dst>
would be very useful for me. How would it work ? Does it automatically
set up a graft file for me ?
> but "everyday" operations shouldn't slow down from having a long history.
but it's really a pain to run for example git-repack or git-prune commands.
Thanks
--
Franck
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Petr Baudis @ 2006-01-19 17:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Franck, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601190842270.3240@g5.osdl.org>
Dear diary, on Thu, Jan 19, 2006 at 05:58:09PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Thu, 19 Jan 2006, Petr Baudis wrote:
> >
> > Dear diary, on Thu, Jan 19, 2006 at 11:51:22AM CET, I got a letter
> > where Franck <vagabon.xyz@gmail.com> said that...
> > > well, dealing with a repo that has more than 300,000 objects becomes a
> > > burden. A lots of git commands are slow, and cloning it take a while !
> >
> > Were the objects packed? It would be interesting to have some data about
> > how GIT performs with that much objects...
>
> The historical linux archive has a lot more than 300,000 objects. In fact,
> even the _current_ kernel archive has almost 200,000 objects.
Eek. I was burnt by git-count-objects' misleading name. I guess
git-rev-list --objects --all | wc -l
should give accurate results - 145941 for kernel repository back from
December. I will follow up later with a patch for git-count-objects.
> - a full clone takes a long time. Git _could_ fairly easily have an
> extension to add a date specifier to clone too:
>
> git clone --since=1.month.ago <source> <dst>
>
> and just leave any older stuff (you could always fetch it later), but
> we've just never done it. Maybe we should. It _should_ be pretty simple
> to do from a conceptual standpoint.
Yes. I receive wishes for this time by time and it is buried somewhere
deep in my TODO list. I'm not sure how happy the GIT tools will be about
invalid parent references.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Linus Torvalds @ 2006-01-19 16:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Franck, Junio C Hamano, Git Mailing List
In-Reply-To: <20060119130940.GC28365@pasky.or.cz>
On Thu, 19 Jan 2006, Petr Baudis wrote:
>
> Dear diary, on Thu, Jan 19, 2006 at 11:51:22AM CET, I got a letter
> where Franck <vagabon.xyz@gmail.com> said that...
> > well, dealing with a repo that has more than 300,000 objects becomes a
> > burden. A lots of git commands are slow, and cloning it take a while !
>
> Were the objects packed? It would be interesting to have some data about
> how GIT performs with that much objects...
The historical linux archive has a lot more than 300,000 objects. In fact,
even the _current_ kernel archive has almost 200,000 objects.
Maybe somebody was thinking "commits", not "objects". Something with
300,000 commits is indeed a pretty big project.
Anyway, from a scalability standpoint, git should have no problem at all
with tons of objects, as long as you pack the old history. There are a few
things that get slower:
- if you end up doing things that look at history, they are obviously at
least linear is history size. Often there are other downsides too
(using lots of memory).
Example: try even just a simple "gitk" on the (regular, new) kernel
archive, and it will take a while before the whole thing has been done.
Of course, you'll see the top entries interactively, so mostly you
won't care, but I routinely limit it some way just to make it not make
the CPU fans come on. So I do something like
gitk --since=1.week.ago
gitk v2.6.15..
instead of plain gitk, just because it makes operations cheaper.
- a full clone takes a long time. Git _could_ fairly easily have an
extension to add a date specifier to clone too:
git clone --since=1.month.ago <source> <dst>
and just leave any older stuff (you could always fetch it later), but
we've just never done it. Maybe we should. It _should_ be pretty simple
to do from a conceptual standpoint.
but "everyday" operations shouldn't slow down from having a long history.
I can still apply 4-5 patches a second to the kernel archive, for example,
as you can see from
git log --pretty=fuller | grep CommitDate | less -S
and looking for one of the patch series I've applied from Andrew..
Linus
^ permalink raw reply
* Re: /etc in git?
From: Joel Becker @ 2006-01-19 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Hunt, git
In-Reply-To: <7v64ogkdtu.fsf@assigned-by-dhcp.cox.net>
On Wed, Jan 18, 2006 at 09:05:01PM -0800, Junio C Hamano wrote:
> You are much better off to keep /usr/src/rootstuff/.git (and
> working tree files are /usr/src/rootstuff/etc/hosts and
> friends), have a build procedure (read: Makefile) there, and
> version control that source directory. I usually have 'install'
> and 'diff' target in that Makefile, so that I can do this:
A while back I wrote CVSMan, which tries to be berkeley sup(8)
with CVS as the transport. I think git would work well here, but I
haven't yet generalized the code to support non-CVS SCMs (I certainly
have wanted to, it's the only thing I use CVS for anymore).
Like GIT, CVS doesn't do perms well. However, CVSMan handles
the perms via .cvsperms files.
Joel
--
"What does it say about a society's priorities when the time you
spend in meetings on Monday is greater than the total number of
hours you spent sleeping over the weekend?"
- Nat Friedman
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkxciodu.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 19, 2006 at 12:59:57AM -0800, Junio C Hamano wrote:
>Christopher Faylor <me@cgf.cx> writes:
>>"They" probably would like to hear about any irregularities that are
>>found. "They" probably don't like it when people treat an open source
>>project as if it was some unresponsive proprietary enterprise which
>>does not listen to or accept patches.
>
>First of all, thanks for joining our discussion.
You're welcome. I use git on linux and cygwin so I'm happy to try to help.
>Being able to hear from somebody from other project firsthand (not just
>listen to somebody talking in his own changelogs and code comments, but
>in actual e-mail exchange discussion) lets us put faces and names to
>the entity "so far just one of the external projects to us".
I only read this list sporadically but I have chimed in from time to time
when people were talking about cygwin. For the most part, it seems like
my input hasn't been needed all that much.
>>>For reasons unknown, cygwin decided to use our sockaddr_storage.
>
>I haven't looked at the proposed patch by Alex, so would not comment on
>this part, but I'd appreciate your input.
>
>>>For the other, probably unrelated, reasons, they decided to leave
>>>declarations of DT_* macros in dirent.h without providing
>>>dirent->d_type.
>
>I was wondering what the justification for keeping DT_* without d_type
>myself. What is the preferred resolution on this one from your point
>of view? I suspect removing d_type while leaving DT_* was just a
>transient error and you would want to remove DT_* as well, in which
>case the patch on this issue by Alex would become unnecessary.
Actually, I started adding DT_* macros at one point, in preparation for
adding d_type, and then got sidetracked. Their existence is a real bug
so, I have ifdef'ed out the DT macros in current CVS.
>>>And on top of that, they removed dirent->d_ino (or probably replaced it
>>>by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
>>>referenced only in fsck-objects.c Anyway, to workaround this I put
>>>
>>>COMPAT_CFLAGS += -Dd_ino=__ino32
>>>
>>>It helps, but surely is not the solution.
>>
>> I don't see how it could help since __ino32 is not actually filled in
>> with anything. In fact, I'll rename the field to __invalid_ino32 to
>> make that clear.
>
>I think renaming __invalid_* makes sense. I'll see how we would
>work this around on the git side to make things more portable.
There were two fields in the dirent struct. One was the "real" d_ino
which was a 64-bit ino_t, __ino32 was a legacy field from a time when
inodes were 32 bits. I had already renamed the d_ino to __invalid_d_ino
but I didn't think I had to rename __ino32, too, since it wasn't a
standard field and didn't think that anyone would be using it. However,
it is now __invalid_ino32 (and will probably disappear entirely) in CVS.
I knew that there would be fallout from getting rid of d_ino but this
change has been a long time coming. Previously, the inodes reported in
d_ino were different from the (correct) ones in st_ino and some
applications were understandbly confused by that fact. Making d_ino
accurate would have meant that we'd have to open every file in readdir
to get the windows equivalent of inode information and, since we get
enough "cygwin is slow" complaints, that wasn't a cost we were willing
to pay.
cgf
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-19 15:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20060119130009.GA28365@pasky.or.cz>
On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:
> But of course when this goes on, soon the gcc commandline will get
> really awfully ugly. This is why something _like_ autoconf is a good
> thing - you can just detect if the system headers provide the type and
> #define it only when they don't.
not you. Someone has done the job of detecting things for you.
It's just a fair amount of hard work badly done.
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-19 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20060119125155.GZ28365@pasky.or.cz>
On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter
> where Alex Riesen <raa.lkml@gmail.com> said that...
> > For reasons unknown, cygwin decided to use our sockaddr_storage.
> > As it is redefined to sockaddr_in it'd cause compilation errors in
> > cygwin headers. Fixed by first patch, which uses a more git-related
> > name (can we claim rights for the symbol, being first to use it? :-)
>
> Huh? "Our"? See RFC 2553 and e.g.:
>
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html
>
> You have no business meddling with this identifier except working around
> platforms which do not support it, but then do not complain that things
> break when the platforms actually start supporting it. ;-)
That will remind me to consult the specs first.
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Alex Riesen @ 2006-01-19 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Christopher Faylor
In-Reply-To: <7vmzhtqakl.fsf@assigned-by-dhcp.cox.net>
On 1/19/06, Junio C Hamano <junkio@cox.net> wrote:
> By the way, if you have an access to git on cygwin with FAT,
> could you test your patch ($SECONDS) and then i-num patch (the
> machine with cygwin I can borrow has only NTFS) please?
Works if sleep is for 2 secs (I completely forgot about that stupid
FAT granularity!)
st_ino is always the same (it is a hash of pathname).
Christopher, how is that supposed to work with hardlinks? (NTFS has
hardlinks, BTW)
^ permalink raw reply
* cg-update bug?
From: walt @ 2006-01-19 14:07 UTC (permalink / raw)
To: git
Hi Petr,
After this commit:
commit 476b0a8846f08fed436a393de42d1476c2d97c60
committer Petr Baudis <xpasky@machine.or.cz> Sun, 15 Jan 2006 15:34:55
Make cg-fetch w/o -v be silent about the fetched changes altogether
cg-update is now also silent about fetched changes, but
there is no -v flag for cg-update. Could it be added
so I can get the old behavior back?
Thanks!
^ 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