* [PATCH] README spellcheck again
From: Pavel Roskin @ 2005-04-21 23:20 UTC (permalink / raw)
To: git
Hello!
Patch against current git, applies cleanly to both linus and pasky
branches.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/README
+++ b/README
@@ -95,7 +95,7 @@ The object types in some more detail:
In particular, since the blob is entirely defined by its data,
if two files in a directory tree (or in multiple different
versions of the repository) have the same contents, they will
- share the same blob object. The object is toally independent
+ share the same blob object. The object is totally independent
of it's location in the directory tree, and renaming a file does
not change the object that file is associated with in any way.
@@ -150,7 +150,7 @@ CHANGESET: The "changeset" object is an
actually have any relationship with the result, for example.
Note on changesets: unlike real SCM's, changesets do not contain
- rename information or file mode chane information. All of that
+ rename information or file mode change information. All of that
is implicit in the trees involved (the result tree, and the
result trees of the parents), and describing that makes no sense
in this idiotic file manager.
@@ -322,7 +322,7 @@ main combinations:
changes in your working directory (ie "update-cache").
However, if you decide to jump to a new version, or check out
- somebody elses version, or just restore a previous tree, you'd
+ somebody else's version, or just restore a previous tree, you'd
populate your index file with read-tree, and then you need to
check out the result with
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Docs update
From: David Greaves @ 2005-04-21 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, GIT Mailing Lists
In-Reply-To: <7vy8bbd9n4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"DG" == David Greaves <david@dgreaves.com> writes:
> Looks nice. I agree with Petr's comment that separating core part
> and Cogito part would be good
OK
> And the option to use working tree is not having the --cached
> flag you describe later. Please also update the usage at the
> top as well:
<snip>
> This command can take commit ID in place of tree ID.
Yep, the intention is to do all the core docs, get consistent use of
<sha1> or <tree> or <id> etc etc and then patch all the usage()s at once.
Thanks for the comments - will edit in the am.
David
^ permalink raw reply
* Re: [PATCH] Add DEST Makefile variable
From: Matthias Urlichs @ 2005-04-21 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7h3d9cu.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano:
> I sent essentially the same some time ago and got a comment to
> follow established naming convention.
>
Well, for a Makefile which installs in basically one directory, that
seems to be overkill.
> # DESTDIR=
> BINDIR=$(HOME)/bin
> install foobar $(DESTDIR)$(BINDIR)/
>
That doesn't make sense; if you set DESTDIR, you are not going to
install in $HOME.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH] Missing linefeeds
From: Matthias Urlichs @ 2005-04-21 23:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050421162614.GF30991@pasky.ji.cz>
Hi,
Petr Baudis:
> Why? report() already prints linefeed.
>
Ah, it didn't when I wrote this.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH] Improve usage messages
From: Junio C Hamano @ 2005-04-21 23:02 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421124152.A28137F87D@smurf.noris.de>
>>>>> "MU" == Matthias Urlichs <smurf@smurf.noris.de> writes:
MU> Index: diff-tree.c
MU> +static const char diff_tree_usage[] =
MU> + "diff-tree [ -r (recurse) | -z (\\0-terminate) ]"
MU> + "\n\t<tree sha1> <tree sha1>";
I think we already have this, and Pasky's right to say the
(recurse) and (\0-terminate) should not be there.
^ permalink raw reply
* Re: [PATCH] Add DEST Makefile variable
From: Junio C Hamano @ 2005-04-21 22:59 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421123904.9F2EB7F8AD@smurf.noris.de>
>>>>> "MU" == Matthias Urlichs <smurf@smurf.noris.de> writes:
MU> # (my ext3 doesn't).
MU> CFLAGS=-g -O3 -Wall
MU> +DEST=$(HOME)/bin
MU> install: $(PROG) $(GEN_SCRIPT)
MU> - install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(HOME)/bin/
MU> + install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DEST)/
I sent essentially the same some time ago and got a comment to
follow established naming convention.
Many people seem to call What you are calling DEST above BINDIR
and DEST or DESTDIR usually means something completely
different. It goes like this:
# DESTDIR=
BINDIR=$(HOME)/bin
install:
install foobar $(DESTDIR)$(BINDIR)/
$ su ;# personal machine install by local root
# make BINDIR=/usr/local/bin install
# binary package creation
$ make BINDIR=/usr/bin DESTDIR=/var/tmp/tmp-inst install
$ tar Ccf /var/tmp/tmp-inst tarball.tar.gz .
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Edgar Toernig @ 2005-04-21 22:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504211238150.2344@ppc970.osdl.org>
Linus Torvalds wrote:
>
> I've just integrated the Mozilla SHA1 library implementation into the
> standard git archive
Thanks.
In the mood for another compatibility hack? My zlib doesn't have
deflateBound and browsing through the git-ml archive it seems I'm
not the only one. How about putting this snippet into some header
file?
#if ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
The formula is the conservative upper bound from zlib-1.2.2.
Ciao, ET.
^ permalink raw reply
* Re: ia64 git pull
From: Petr Baudis @ 2005-04-21 22:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tony.luck, linux-ia64, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0504211520250.2344@ppc970.osdl.org>
Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Thu, 21 Apr 2005 tony.luck@intel.com wrote:
> >
> > I can't quite see how to manage multiple "heads" in git. I notice that in
> > your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> > perhaps that is a clue.
>
> It's mainly a clue to bad practice, in my opinion. I personally like the
> "one repository, one head" approach, and if you want multiple heads you
> just do multiple repositories (and you can then mix just the object
> database - set your SHA1_FILE_DIRECTORY environment variable to point to
> the shared object database, and you're good to go).
There are two points regarding this:
(i) You need to track heads of remote branches anyway.
(ii) I want an easy way for user to refer to head of another working
tree on the same repository (so that you can do just git merge testing).
This is why the multiple heads are there, and it's actually everything
they _do_. There's nothing more behind it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Docs update
From: Junio C Hamano @ 2005-04-21 22:53 UTC (permalink / raw)
To: David Greaves; +Cc: Petr Baudis, GIT Mailing Lists
In-Reply-To: <42680FCC.6030901@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
Looks nice. I agree with Petr's comment that separating core part
and Cogito part would be good, and I would appreciate if you
pushed the core part documentation to Linus as well.
Some nitpicks and notes on your core part description.
DG> commit-tree
DG> - commit-tree <sha1> [-p <sha1>]* < changelog
DG> + commit-tree <sha1> [-p <parent sha1>...] < changelog
The above does not describe what commit-tree expects. It wants
commit-tree <tree-sha1> [-p <parent1 sha1>]* <changelog
That is, you need -p before every parent. I however think what
coommit-tree does here this aspect is wrong, unless Linus has
plans to give parameters other than parent IDs to commit-tree
later. Even if that is the case, those non-parent things can
have their own -flag in front of them so not requiring -p would
be a good change. I'll ask opinion from Linus on this (I just
sent out a patch).
DG> +A commit object usually has 1 parent (a commit after a change) or 2
DG> +parents (a merge) although there is no reason it cannot have more than
DG> +2 parents.
I'd rewrite the "or 2 parents..." part to "up to 16 parents. More
than one parent represents merge of branches that led to them."
DG> +If not provided, commit-tree uses your name, hostname and domain to
DG> +provide author and committer info. This can be overridden using the
DG> +following environment variables.
DG> + ...
DG> +(nb <,> and CRs are stripped)
CRs are kept. It removes '\n' (which is not necessarily LF).
DG> +diff-cache
DG> + diff-cache [-r] [-z] <tree/commit sha1>
DG> +
DG> +Compares the content and mode of the blobs found via a tree object
DG> +with the content of the current cache and, optionally, the stat state
DG> +of the file on disk.
And the option to use working tree is not having the --cached
flag you describe later. Please also update the usage at the
top as well:
diff-cache [-r] [-z] [--cached] <tree/commit sha1>
DG> +In the special case of the file being changed on disk and out of sync with the cache, the sha1
DG> +
DG> +Operating Modes
Is the description truncated after "the sha1"???
DG> ################################################################
DG> diff-tree
DG> - diff-tree [-r] [-z] <tree sha1> <tree sha1>
DG> + diff-tree [-r] [-z] <tree sha1> <tree sha1>
This command can take commit ID in place of tree ID.
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Linus Torvalds @ 2005-04-21 22:47 UTC (permalink / raw)
To: Chris Mason; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504211622.48065.mason@suse.com>
On Thu, 21 Apr 2005, Chris Mason wrote:
>
> Shrug, we shouldn't need help from the kernel for something like this. git as
> a database hits worst case scenarios for almost every FS.
I really disagree.
> We've got:
>
> 1) subdirectories with lots of files
> 2) wasted space for tiny files
> 3) files that are likely to be accessed together spread across the whole disk
On the other hand, git does a lot of things that are just _lovely_ for a
filesystem:
- it never rewrites a file. Rewriting a file is unquestionably _the_
single worst access pattern for any filesystem. In contrast, never
writing to a file again means that filesystems can optimize their
layout and that things like defragmentation actually works.
- it caches beautifully, and efficiently. Part of it comes from never
modifying files after they are written (which means that any network
filesystem automatically breathes a huge sign of relief), but part of
it is that it always reads full files, and the layout is done so that
it really actually _uses_ everything it reads.
It also caches beautifully on a memory subsystem level, largely for the
same reasons.
- it doesn't use tons of directories.
You say that "subdirectories with lots of files" is painful, but that's
not really the whole story. A _deep_ directory structure tends to
actually be worse in many ways, because it's much easier to optimize a
flat directory structure than a deep one. In other words, git ends up
making name hashing etc _productive_.
So yes, it's a bit wasteful. But it's wasteful of what is absolutely the
cheapest resource around: disk space. It's not a huge downside, and in
fact I really do believe that the biggest downside _by_far_ in diskspace
utilization is the _seek_ costs, not the space itself. Let's face it,
anybody who wants three years of kernel archives and thinks that 3GB of
disk is too much, has some serious problems.
The _seek_ issue is real, but git actually has a very nice architecture
even there: not only dos it cache really really well (and you can do a
simple "ls-tree $(cat .git/HEAD)" and populate the case from the results),
but the low level of indirection in a git archive means that it's almost
totally prefetchable with near-perfect access patterns.
In seeking, the real cost is synchronization, and the git model actually
means that there are very few seeks that have to be synchronized. You
could literally do the "ls-tree" thing and make an absolutely trivial
prefetcher that did the prefetching with enough parallellism that the
filesystem could probably get decent IO performance out of a disk.
In other words, we really could have a "git prefetch" command that would
populate the cache of the current head quite efficiently. Because the data
layout supports that.
Linus
^ permalink raw reply
* [PATCH] Make -p flag optional from commit-tree.
From: Junio C Hamano @ 2005-04-21 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
We cannot currently say:
$ commit-tree $(write-tree) $(cat .git/heads/junio .git/heads/linus)
The above must be written as:
$ commit-tree $(write-tree) \
-p $(cat .git/heads/junio) \
-p $(cat .git/heads/linus)
This patch makes -p flag optional. Existing scripts are
hopefully not affected because they are passing -p properly. If
we want to introduce non parent-ID parameters to commit-tree
later, we can give them their own -flag letters.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
commit-tree.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
commit-tree.c: c0b07f89286c3f6cceae8122b4c3142c8efaf8e1
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -297,10 +297,17 @@ int main(int argc, char **argv)
usage(commit_tree_usage);
check_valid(tree_sha1, "tree");
- for (i = 2; i < argc; i += 2) {
- char *a, *b;
- a = argv[i]; b = argv[i+1];
- if (!b || strcmp(a, "-p") || get_sha1_hex(b, parent_sha1[parents]))
+ for (i = 2; i < argc; i++) {
+ /* Historically commit-tree required -p in front of
+ * each parent commit ID. This is confusing. We can
+ * add non parent commit ID parameter later by defining
+ * flags other than "-p" so let's just ignore them.
+ */
+ if (! strcmp(argv[i], "-p"))
+ continue;
+
+ /* Currently it just expects parent IDs. */
+ if (get_sha1_hex(argv[i], parent_sha1[parents]))
usage(commit_tree_usage);
check_valid(parent_sha1[parents], "commit");
parents++;
^ permalink raw reply
* Re: Colorized git log
From: Petr Baudis @ 2005-04-21 22:42 UTC (permalink / raw)
To: Sean; +Cc: GIT Mailing Lists
In-Reply-To: <3536.10.10.10.24.1114117965.squirrel@linux1>
Dear diary, on Thu, Apr 21, 2005 at 11:12:45PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On the off chance that someone else might like it, here is a pager script
> for the git log that adds a splash of color:
Actually, I would've never expected that I would like it, but we all
sometimes surprise ourselves.
I made git log colorized if you pass it -c in current git-pasky. Thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: wit 0.0.3 - a web interface for git available
From: Jon Seymour @ 2005-04-21 22:33 UTC (permalink / raw)
To: Kay Sievers; +Cc: Christoph Hellwig, Greg KH, Christian Meder, git
In-Reply-To: <20050421012827.GA13795@vrfy.org>
On 4/21/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote:
>
> It's working now:
> http://ehlo.org/~kay/gitweb.pl
>
Kay + Christian + Ken,
That looks really great!.
One suggestion: when drilling down through the tree it would be nice
if the context of the parents could be dragged along too. So, for
example, when displaying the BLOB, you could display its name because
you have kept enough context around to allow that.
This would also allow you to extend the functionality so that when you
are at the BLOB level you could navigate to a history of changes to
just that BLOB, at least from the point of view of the commit that
got you there.
Also, have you considered generating pure XML from the database and
relying on XSLT (either at the server, or preferably at the client -
they all do it well these days!) to do the HTML rendering?
jon.
^ permalink raw reply
* Re: Linux 2.6.12-rc3
From: Pavel Machek @ 2005-04-21 22:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050421214119.GO7443@pasky.ji.cz>
Hi!
> > It seems that someone should write "Kernel hacker's guide to
> > git"... Documentation/git.txt seems like good place. I guess I'll do
> > it.
>
> I've also started writing some tutorial-like guide to Cogito on my
> notebook, but I have time for that only during lectures. :^)
Well, this will be really short and really kernel oriented.
> > > I'm not yet sure if we should have some Cogito interface for doing this
> > > and what its semantics should be.
> >
> > What is Cogito, BTW?
>
> New name for git-pasky. Everyone will surely rejoice as the usage will
> change significantly. But better let's clean it up now.
>
> (For more details, check git@ archives for git-pasky-0.6
> announcement.)
I liked git, and git-pasky did not seem too wrong, either... I did
google search for cogito, and there are several companies named that
way, and some are software-related. git was bad name, but cogito seems
bad, too. I'd stick with git.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* Colorized git log
From: Sean @ 2005-04-21 21:12 UTC (permalink / raw)
To: GIT Mailing Lists
On the off chance that someone else might like it, here is a pager script
for the git log that adds a splash of color:
#!/bin/sh
git log "$@" | sed -re '
/.*signed-off-by.*/Is//\x1b[34m&\x1b[0m/
/^--*$/Is//\x1b[31m&\x1b[0m/
/^(commit|tree|parent) .*/Is//\x1b[32m&\x1b[0m/
/^author .*/Is//\x1b[36m&\x1b[0m/
/^committer .*/Is//\x1b[35m&\x1b[0m/' | less -R
Sean
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 22:06 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: git
In-Reply-To: <20050421.221441.85407120.oandrieu@nerim.net>
* Olivier Andrieu <oandrieu@nerim.net> wrote:
> > - naming the boxes by key is quite meaningless. It would be more
> > informative to see the author's email shortcuts in the boxes. Also, it
> > would be nice to see some simple graphical feedback about the size and
> > scope of a changeset, without having to zoom on it.
>
> That's interesting. What do you mean exactly by scope ?
usually there are two interesting things about a patchset: how many
lines does it change, and how many files. Patches that change lots of
files (but change only a couple of lines in every file) have a 'large'
scope. Patches that change 1-2 files have a 'small' scope. A pure
'number of lines changed' metric is useful too. Generally patches that
have either a large linecount or a large scope are more interesting.
(I'm not sure how this could be displayed - perhaps the size of the
rectangle could vary to a certain degree? Perhaps the shape too?
Something non-numeric, so that one gets immediate visual feedback.)
> > i guess you know it, and i'm definitely not complaining about prototype
> > code, but rendering is quite slow: drawing the 340 changesets in the
> > current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the
> > full kernel history (63,000 changesets) would take more than 45 minutes
> > on this box.
> >
> > the current rate of kernel development is ~2000 changesets per month, so
> > drawing the kernel history will get 3 seconds slower every day - it will
> > exceed 1 minute in 20 days, so this will become a pressing issue quite
> > soon i suspect.
>
> Right, it is slow. From what I could understand with a bit of
> profiling, the problem is with the "text" canvas item for the boxes'
> labels. I guess libgnomecanvas isn't using Pango properly or
> something: it lookups the font with fontconfig each time I create such
> an item. I'm not sure what I can do about this.
when the redrawing happens in the visible area then one can see how
really slow it is: 100-200 msec per rectangle (!).
> It works with Petr Baudis' git-pasky (it calls `git diff'). I don't
> know how to do that with the canonical git.
ah, ok. I guess it will start working once Petr's changes are merged
into Linus' tree.
Ingo
^ permalink raw reply
* Re: [3/5] Add http-pull
From: tony.luck @ 2005-04-21 22:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Brad Roberts, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504210007410.30848-100000@iabervon.org>
On Wed, 20 Apr 2005, Brad Roberts wrote:
> How about fetching in the inverse order. Ie, deepest parents up towards
> current. With that method the repository is always self consistent, even
> if not yet current.
Daniel Barkalow replied:
> You don't know the deepest parents to fetch until you've read everything
> more recent, since the history you'd have to walk is the history you're
> downloading.
You "just" need to defer adding tree/commit objects to the repository until
after you have inserted all objects on which they depend. That's what my
"wget" based version does ... it's very crude, in that it loads all tree
& commit objects into a temporary repository (.gittmp) ... since you can
only use "cat-file" and "ls-tree" on things if they live in objects/xx/xxx..xxx
The blobs can go directly into the real repo (but to be really safe you'd
have to ensure that the whole blob had been pulled from the network before
inserting it ... it's probably a good move to validate everything that you
pull from the outside world too).
-Tony
^ permalink raw reply
* Re: Pasky problem with 'git init URL'
From: Fabian Franz @ 2005-04-21 21:57 UTC (permalink / raw)
To: John Stoffel; +Cc: Martin Schlemmer, GIT Mailing Lists, Petr Baudis
In-Reply-To: <17000.6154.748117.967898@smtp.charter.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Donnerstag, 21. April 2005 23:15 schrieb John Stoffel:
> >>>>> "Petr" == Petr Baudis <pasky@ucw.cz> writes:
>
> Petr> Perhaps it would be useful to have some "command classes" (with at
> least Petr> cg-*-(add|ls|rm)), like:
>
> Petr> cg-branch-ls
> Petr> cg-remote-rm
> Petr> cg-tag-add
>
> Just speaking of consistency, can we make it so that all the commands
> are just variations with out the damm dashes in them?
I think the dashes are especially useful, because of "tab-completion".
> git <objecttype> <command> <args> [<obj> ...]
>
I think thats exactly like above:
cg-<objtype>-<command>
cu
Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCaCHbI0lSH7CXz7MRAuSXAJ40v4yNgS13BIExfYTwPv8zbj2HcACdG7G6
YiLFD8u8Guh3xppaa14uD+I=
=dkN/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Tom Lord @ 2005-04-21 21:52 UTC (permalink / raw)
To: t8m; +Cc: gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <1114069758.5886.9.camel@perun.redhat.usu>
> However you're
> right that the original structure proposed by Linus is too flat.
That was the only point I *meant* to defend. The rest was error.
-t
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Tom Lord @ 2005-04-21 21:51 UTC (permalink / raw)
To: t8m; +Cc: gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <1114069758.5886.9.camel@perun.redhat.usu>
> Tom, please stop this ext* filesystem bashing ;-)
For one thing... yes, i'm totally embarassed on this issue.
I made a late-night math error in a spec. *hopefully* would
have noticed it on my own as I coded to that spec but y'all
have been wonderful at pointing out my mistake to me even
though I initially defended it.
As for ext* bashing.... it's not bashing exactly. I/O bandwidth
gets a little better, disks get a bunch cheaper --- then ext*
doesn't look bad at all in this respect. And we're awefully close
to that point.
Meanwhile, for times measured in years, I've gotten complaints from
ext* users about software that is just fine on other filesystems
over issues like the allocation size of small files.
So ext*, from my perspective, was a little too far ahead of its time
and, yes, my complaints about it are just about reaching their
expiration date.
Anyway, thanks for all the sanity about directory layout. Really,
it was just an "I'm too sleepy to be doing this right now" error.
-t
^ permalink raw reply
* Re: Linux 2.6.12-rc3
From: Petr Baudis @ 2005-04-21 21:41 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linus Torvalds, kernel list, git
In-Reply-To: <20050421213811.GA31207@elf.ucw.cz>
Dear diary, on Thu, Apr 21, 2005 at 11:38:11PM CEST, I got a letter
where Pavel Machek <pavel@ucw.cz> told me that...
> Hi!
>
> It seems that someone should write "Kernel hacker's guide to
> git"... Documentation/git.txt seems like good place. I guess I'll do
> it.
I've also started writing some tutorial-like guide to Cogito on my
notebook, but I have time for that only during lectures. :^)
> > I'm not yet sure if we should have some Cogito interface for doing this
> > and what its semantics should be.
>
> What is Cogito, BTW?
New name for git-pasky. Everyone will surely rejoice as the usage will
change significantly. But better let's clean it up now.
(For more details, check git@ archives for git-pasky-0.6 announcement.)
> > > I see quite a lot of problems with fsck-tree. Is that normal?
> > > (I ran out of disk space few times during different operations...)
> >
> > Actually, in case your tree is older than about two days, I hope you did
> > the convert-cache magic or fetched a fresh tree?
>
> No, I did not anything like that. I guess it is rm -rf time, then...
That's the root of all your problems then.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Linux 2.6.12-rc3
From: Pavel Machek @ 2005-04-21 21:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, kernel list, git
In-Reply-To: <20050421190956.GA7443@pasky.ji.cz>
Hi!
It seems that someone should write "Kernel hacker's guide to
git"... Documentation/git.txt seems like good place. I guess I'll do
it.
> > just plain vanilla" without rm -rf?
>
> git cancel will give you "plain last commit". If you need plain vanilla,
> the "hard way" now is to just do
>
> commit-id >.git/HEAD
>
> but your current HEAD will be lost forever. Or do
>
> git fork vanilla ~/vanilla linus
>
> and you will have the vanilla tree tracking linus in ~/vanilla.
Ok, thanks.
> I'm not yet sure if we should have some Cogito interface for doing this
> and what its semantics should be.
What is Cogito, BTW?
> > I see quite a lot of problems with fsck-tree. Is that normal?
> > (I ran out of disk space few times during different operations...)
>
> Actually, in case your tree is older than about two days, I hope you did
> the convert-cache magic or fetched a fresh tree?
No, I did not anything like that. I guess it is rm -rf time, then...
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* Re: Pasky problem with 'git init URL'
From: Petr Baudis @ 2005-04-21 21:26 UTC (permalink / raw)
To: John Stoffel; +Cc: Martin Schlemmer, GIT Mailing Lists
In-Reply-To: <17000.6154.748117.967898@smtp.charter.net>
Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter
where John Stoffel <john@stoffel.org> told me that...
> >>>>> "Petr" == Petr Baudis <pasky@ucw.cz> writes:
>
> Petr> Perhaps it would be useful to have some "command classes" (with at least
> Petr> cg-*-(add|ls|rm)), like:
>
> Petr> cg-branch-ls
> Petr> cg-remote-rm
> Petr> cg-tag-add
>
> Does a standard like:
>
> git <objecttype> <command> <args> [<obj> ...]
Isn't this basically what I was proposing? (Modulo the UI changes
related to git-pasky -> Cogito.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Docs update
From: Petr Baudis @ 2005-04-21 21:26 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <4268181B.6050906@dgreaves.com>
Dear diary, on Thu, Apr 21, 2005 at 11:16:11PM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Petr Baudis wrote:
> >
> >Make a choice - either you are describing git or Cogito. The frmer has
> >no RSYNC_FLAGS and does not care about any heads or anything at all (you
> >might mention it as a recommended convention, though).
>
> I was going to do both - surely that's OK?
I thought the original goal for README.reference was to be git-specific,
and I planned to therefore push it to the core git at some point.
I actually probably don't mind as long as you keep the two separated
cleanly inside of the file, so if we shall want to include it in git,
the trimming of the docs to only relevant parts is simple enough.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Docs update
From: David Greaves @ 2005-04-21 21:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050421204348.GJ7443@pasky.ji.cz>
Petr Baudis wrote:
>
> Make a choice - either you are describing git or Cogito. The frmer has
> no RSYNC_FLAGS and does not care about any heads or anything at all (you
> might mention it as a recommended convention, though).
I was going to do both - surely that's OK?
The only reason it's core so far is that I started working my way
through the code alphabetically (having no other clue where to start!)
As it turns out it will probably make sense to do all the core first -
but I don't want to miss things so as I read through all the mails and
extract content, I make a note of things like environment variables
which I'll bulk up and cross reference later.
I may even change my mind and make notes on Cogito if that takes my
fancy too ;)
I know it's not polished yet - but I'd rather publish it and have people
catch mistakes.
David
^ 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