* Petr Baudis <[EMAIL PROTECTED]> wrote:
> > I think pull is pull. If you are doing lots of local stuff and do not
> > want it overwritten, it should have been in a forked branch.
>
> I disagree. This already forces you to have two branches (one to pull
> from to get the data, mirroring the re
Linus Torvalds wrote:
So I'll see if I can turn the current fsck into a "convert into
uncompressed format", and do a nice clean format conversion.
Just let me know what you want to do, and I can trivially change the
conversion scripts I've already written to do what you want.
-hpa
-
To
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Apr 2005, Ingo Molnar wrote:
> >
> > well, the 'owned by another user' solution is valid though, and doesnt
> > have this particular problem. (We've got a secure multiuser OS, so can
> > as well use it to protect the DB against corruptio
This patch changes identical cut-and-paste usage strings into a
single instance of static string, to make maintenance easier.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
commit-tree.c | 14 ++
diff-cache.c |6 --
diff-tree.c |6 --
read-tree.c | 10
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> perhaps having a new 'immutable hardlink' feature in the Linux VFS
> would help? I.e. a hardlink that can only be readonly followed, and
> can be removed, but cannot be chmod-ed to a writeable hardlink. That i
> think would be a large enough barrier f
> However, I'm claiming a token is defined by the file's language, and
> that a replace patch on anything but a token as per those language
> standards is a silly thing.
Please recall the context of this discussion: getting Darcs to grok
git repositories.
You are arguing that it should be possibl
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > perhaps having a new 'immutable hardlink' feature in the Linux VFS
> > would help? I.e. a hardlink that can only be readonly followed, and
> > can be removed, but cannot be chmod-ed to a writeable hardlink. That i
> > think would be a large enough b
> We're talking about interoperating with a Git repository here,
> right? Even if we got the metadata in there, doesn't Git have to
> understand a replace patch for things to work out?
> 0. All three are in sync to begin with.
> 1. CC creates a token-replace patch, sends the changes in normal hu
[A discussion on the git list about how to provide a hardlinked file
that *cannot* me modified by an editor, but must be replaced by
a new copy.]
[EMAIL PROTECTED] wrote all of:
>>> perhaps having a new 'immutable hardlink' feature in the Linux VFS
>>> would help? I.e. a hardlink that can only be
On Wed, Apr 20, 2005 at 09:53:20AM +0200, Ingo Molnar wrote:
> so the only sensible thing the editor/tool can do when it wants to
> change the file is precisely what we want: it will copy the
> hardlinked files's contents to a new file, and will replace the old
> file with the new file - a copy on
I converted my git archives (kernel and git itself) to do the SHA1 hash
_before_ the compression phase.
So I'll just have to publically admit that everybody who complained about
that particular design decision was right. Oh, well.
On Wed, 20 Apr 2005, H. Peter Anvin wrote:
> Linus Torvalds wr
Hi,
thanks to my friend Frank Sattelberger I got access to a site where I
could set up a demo for wit:
http://grmso.net:8090
Couple of notes wrt why I work on another git web interface compared
with Kay's work:
* I was already experimenting and implementing for a couple of days when
Kay's tool
On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
> Hi,
>
> ok it's starting to look like spam ;-)
>
> I uploaded a new version of wit to http://www.absolutegiganten.org/wit
Got an url where it can be seen on a live repository?
-
To unsubscribe from this list: send the line "unsu
On Tue, Apr 19, 2005 at 09:18:29PM -0700, Greg KH wrote:
> On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
> > Hi,
> >
> > ok it's starting to look like spam ;-)
> >
> > I uploaded a new version of wit to http://www.absolutegiganten.org/wit
>
> Why not work together with Kay's t
As shipped, the example git-merge-one-file-script often leaves
the merge result with not-so-useful mode bits, especially with
glibc 2.0.7 or later whose mkstemp() creates temporary file with
mode 0600. This contradicts the way checkout-cache creates new
files, which is to use 0666 (or 0777 for fil
On Wed, 2005-04-20 at 10:42 +0100, Christoph Hellwig wrote:
> On Tue, Apr 19, 2005 at 09:18:29PM -0700, Greg KH wrote:
> > On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
> > > Hi,
> > >
> > > ok it's starting to look like spam ;-)
> > >
> > > I uploaded a new version of wit to h
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So to convert your old git setup to a new git setup, do the following:
> [...]
did this for two repositories (git and kernel-git), it works as
advertised.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
`git', by Linus Torvalds, contains some very good ideas and some
very entertaining source code -- recommended reading for hackers.
/GNU Arch/ will adopt `git':
>From the /Arch/ perspective: `git' technology will form the
basis of a new archive/revlib/cache format and the basis
of new network tra
`git', by Linus Torvalds, contains some very good ideas and some
very entertaining source code -- recommended reading for hackers.
/GNU Arch/ will adopt `git':
>From the /Arch/ perspective: `git' technology will form the
basis of a new archive/revlib/cache format and the basis
of new network tra
* Petr Baudis <[EMAIL PROTECTED]> wrote:
> Hi,
>
> just FYI, Olivier Andrieu was kind enough to port his monotone-viz
> tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one
> from the monotone repository). The tool visualizes the history flow
> nicely; see
>
> http://
Way to go.
-Miles
--
Do not taunt Happy Fun Ball.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 19, 2005 at 09:49:12AM -0700, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Tupshin Harper wrote:
> > I suspect that any use of wildcards in a new format would be impossible
> > for darcs since it wouldn't allow darcs to construct dependencies,
> > though I'll leave it to david to respon
On Tue, Apr 19, 2005 at 02:25:18PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter
> where Juliusz Chroboczek <[EMAIL PROTECTED]> told me that...
> > > The problem is that there is no sequence of alien versions that one
> > > can differentiate. Git h
On Tue, Apr 19, 2005 at 02:20:55PM +0200, Juliusz Chroboczek wrote:
> [Removing Linus from CC, keeping the Git list -- or should we remove it?]
I think leaving much of this on git would be appropriate, since there are
issues of how to relate to git that should be relevant.
> > If we do it right (
On Tue, Apr 19, 2005 at 06:11:43PM -0700, Ray Lee wrote:
> > second patch:
> > replace ./hello.c [A-Za-z_0-9] world universe
>
> Aha! Okay, I now see at least part of issue: we're using different
> definitions of 'token.' Yours is quite sensible, in that it matches the
> darcs syntax. However, I'm
On 4/20/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> I converted my git archives (kernel and git itself) to do the SHA1 hash
> _before_ the compression phase.
>
Linus,
Am I correct to understand that with this change, all the objects in
the database are still being compressed (so no n
Use a generic rule for executables that depend only on the corresponding
.o and on $(LIB_FILE).
Signed-Off-By: Andre Noll <[EMAIL PROTECTED]>
---
Makefile | 49 ++---
1 files changed, 2 insertions(+), 47 deletions(-)
Makefile: cd299f850679b2456e360d3
On Wed, Apr 20, 2005 at 10:11:10PM +1000, Jon Seymour wrote:
> On 4/20/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > I converted my git archives (kernel and git itself) to do the SHA1 hash
> > _before_ the compression phase.
> >
>
> Linus,
>
> Am I correct to understand that with
So I wrote up my ideas regarding blob chunking as code; see attached.
This is against git-0.4 (I know, ancient, but I had to start somewhere.)
The idea here is that blobs are chunked using a rolling checksum (so the
chunk boundaries are content-dependent and stay fixed even if you mutate
pieces o
On 4/20/05, Martin Uecker <[EMAIL PROTECTED]> wrote:
> The storage method of the database of a collection of
> files in the underlying file system. Because of the
> random nature of the hashes this leads to a horrible
> amount of seeking for all operations which walk the
> logical structure of som
> The main point is not about trying different compression
> techniques but that you don't need to compress at all just
> to calculate the hash of some data. (to know if it is
> unchanged for example)
>
Ah, ok, I didn't understand that there were extra compresses being
performed for that reason.
On Wed, 2005-04-20 at 02:08 -0700, Linus Torvalds wrote:
> I converted my git archives (kernel and git itself) to do the SHA1
> hash _before_ the compression phase.
I'm happy to see that -- because I'm going to be asking you to make
another change which will also require a simple repository conver
On Wed, 20 Apr 2005, Jon Seymour wrote:
>
> Am I correct to understand that with this change, all the objects in the
> database are still being compressed (so no net performance benefit), but by
> doing the SHA1 calculations before compression you are keeping open the
> possibility that at so
On Wed, 20 Apr 2005, Martin Uecker wrote:
The other thing I don't like is the use of a sha1
for a complete file. Switching to some kind of hash
tree would allow to introduce chunks later. This has
two advantages:
You can (and my code demonstrates/will demonstrate) still use a whole-file
hash to us
On Wed, 20 Apr 2005, Linus Torvalds wrote:
- _keep_ the same compression format, but notice that we already have an
object by looking at the uncompressed one.
With a chunked file, you can also skip writing certain *subtrees* of the
file as soon as you notice it's already present on disk. I can
On Wed, Apr 20, 2005 at 09:49:48AM +0200, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > perhaps having a new 'immutable hardlink' feature in the Linux VFS
> > would help? I.e. a hardlink that can only be readonly followed, and
> > can be removed, but cannot be chmod-ed to a
On Thu, 21 Apr 2005, David Woodhouse wrote:
>
> The reason for doing this is that without it, we can't ever have a full
> history actually connected to the current trees. There'd always be a
> break at 2.6.12-rc2, at which point you'd have to switch to an entirely
> different git repository.
Qu
On Wed, Apr 20, 2005 at 10:30:15AM -0400, C. Scott Ananian wrote:
Hi,
your code looks pretty cool. thank you!
> On Wed, 20 Apr 2005, Martin Uecker wrote:
>
> >The other thing I don't like is the use of a sha1
> >for a complete file. Switching to some kind of hash
> >tree would allow to introduc
On Wednesday 20 April 2005 02:43, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > I'll finish off the patch once you ok the basics below. My current code
> > works like this:
>
> Chris, before you do anything further, let me re-consider.
>
> Assuming that the real cost of write
On Wed, 20 Apr 2005, Martin Uecker wrote:
You can (and my code demonstrates/will demonstrate) still use a whole-file
hash to use chunking. With content prefixes, this takes O(N ln M) time
(where N is the file size and M is the number of chunks) to compute all
hashes; if subtrees can share the same
On Tue, 19 Apr 2005, Junio C Hamano wrote:
>
> This patch lifts the tree-from-tree-or-commit logic from
> diff-cache.c and moves it to sha1_file.c, which is a common
> library source for the SHA1 storage part.
I don't think that's a good interface. It changes the sha1 passed into it:
that may
On Wed, 20 Apr 2005, Chris Mason wrote:
With the basic changes I described before, the 100 patch time only goes down
to 40s. Certainly not fast enough to justify the changes. In this case, the
bulk of the extra time comes from write-tree writing the index file, so I
split write-tree.c up into li
On Wed, 20 Apr 2005, Chris Mason wrote:
>
> Thanks for looking at this. Your new tree is faster, it gets the commit 100
> patches time down from 1m5s to 50s.
It really _shouldn't_ be faster. It still does the compression, and throws
the end result away.
To actually go faster, it _should_ nee
On Wed, 20 Apr 2005, C. Scott Ananian wrote:
>
> Hmm. Are our index files too large, or is there some other factor?
They _are_ pretty large, but they have to be,
For the kernel, the index file is about 1.6MB. That's
- 17,000+ files and filenames
- stat information for all of them
- the s
On Wed, 20 Apr 2005, Linus Torvalds wrote:
I was considering using a chunked representation for *all* files (not just
blobs), which would avoid the original 'trees must reference other trees
or they become too large' issue -- and maybe the performance issue you're
referring to, as well?
No. The mos
On Wed, Apr 20, 2005 at 11:28:20AM -0400, C. Scott Ananian wrote:
Hi,
> A merkle-tree (which I think you initially pointed me at) makes the hash
> of the internal nodes be a hash of the chunk's hashes; ie not a straight
> content hash. This is roughly what my current implementation does, but
On 4/20/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> It really _shouldn't_ be faster. It still does the compression, and throws
> the end result away.
Am I misunderstanding or is the proglem that doing:
-> compress -> sha1 -> compare with existing hash
is expensive?
What about doing:
-> unc
On Wed, 20 Apr 2005, C. Scott Ananian wrote:
>
> OK, sure. But how 'bout chunking trees? Are you grown happy with the new
> trees-reference-other-trees paradigm, or is there a deep longing in your
> heart for the simplicity of 'trees-reference-blobs-period'?
I'm pretty sure we do better chu
On Wed, 20 Apr 2005, Linus Torvalds wrote:
>
> To actually go faster, it _should_ need this patch. Untested. See if it
> works..
NO! Don't see if this works. For the "sha1 file already exists" file, it
forgot to return the SHA1 value in "returnsha1", and would thus corrupt
the trees it wrote
On Wed, Apr 20, 2005 at 05:57:34PM +0200, Martin Uecker wrote:
> On Wed, Apr 20, 2005 at 11:28:20AM -0400, C. Scott Ananian wrote:
>
> > Yes, I guess this is the detail I was going to abandon. =)
> >
> > I viewed the fact that the top-level hash was dependent on the exact chunk
> > makeup a 'mis
On Wednesday 20 April 2005 11:40, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > Thanks for looking at this. Your new tree is faster, it gets the commit
> > 100 patches time down from 1m5s to 50s.
>
> It really _shouldn't_ be faster. It still does the compression, and throws
>
On Wed, 20 Apr 2005, Linus Torvalds wrote:
>
> NO! Don't see if this works. For the "sha1 file already exists" file, it
> forgot to return the SHA1 value in "returnsha1", and would thus corrupt
> the trees it wrote.
Proper version with fixes checked in. For me, it brings down the time to
writ
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Real merges have no patches taking place _anywhere_. And they take about
> half a second. Doing an "update" of your tree should _literally_ boil down
> to
>
> #
> # "repo" needs to point to the repo we update from
> #
> rsync -
On Wed, Apr 20, 2005 at 08:41:15AM -, [EMAIL PROTECTED] wrote:
> [A discussion on the git list about how to provide a hardlinked file
> that *cannot* me modified by an editor, but must be replaced by
> a new copy.]
Some time ago there was somebody working on copy-on-write links: once
you modif
On Wed, 20 Apr 2005, Chris Mason wrote:
>
> At any rate, the time for a single write-tree is pretty consistent. Before
> it
> was around .5 seconds, and with this change it goes down to .128s.
Oh, wow.
I bet your SHA1 implementation is done with hand-optimized and scheduled
x86 MMX code or
Hi
I'm starting to write some docs...
Comments... even "yep, looks OK, carry on" :)
I plan on putting the 'git command' ones into the 'git help ...'
structure once Petr accepts it.
I guess the low level ones go into a README.reference until they
stabilise and become man pages...
In doing this I
On Wed, 20 Apr 2005, Zlatko Calusic wrote:
>
> I see this -avz incantation mentioned everytime when rsync is
> involved. But, is the -z part (compression) really necessary knowing
> that we're dealing with an already compressed tree? Doesn't it put
> additional strain on the rsync server without
Hi Ray,
> Give me a case where assuming it's a replace will do the wrong thing,
> for C code, where it's a variable or function name.
How about two patches.
1. s/foo/bar/ throughout file because foo() has been decided upon
as the name of a new globally visible forthcoming function but
Petr Baudis graced us with:
> Dear diary, on Tue, Apr 19, 2005 at 02:36:32PM CEST, I got a letter
> where Klaus Robert Suetterlin <[EMAIL PROTECTED]> told me that...
> > 1) There is no clear (e.g. by name) distinction between ``git as done
> > by Linus'', which is a kind of content addressable data
Ingo Molnar <[EMAIL PROTECTED]> writes:
> TREE1=$(cat-file commit 2>/dev/null $1 | head -4 | grep ^tree | cut -d' ' -f2)
--
And to make it easier on your eyes, you can always rewrite stuff like
that (mentioned everywhere
On Wed, 20 Apr 2005, David Greaves wrote:
In doing this I noticed a couple of points:
* update-cache won't accept ./file or fred/./file
The comment in update-cache.c reads:
/*
* We fundamentally don't like some paths: we don't want
* dot or dot-dot anywhere, and in fact, we don't even want
* any
Hi Tom,
just as a datapoint, here is an experiment I carried out. I wanted to evaluate
how much overhead is incurred by using several levels of directories to
implement a discrimating index. I used the key format you specified:
SHA1,SIZE
As data, I used my /usr/src/linux which uses 301
On Wednesday 20 April 2005 13:06, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > At any rate, the time for a single write-tree is pretty consistent.
> > Before it was around .5 seconds, and with this change it goes down to
> > .128s.
>
> Oh, wow.
>
> I bet your SHA1 implementa
C. Scott Ananian wrote:
On Wed, 20 Apr 2005, David Greaves wrote:
In doing this I noticed a couple of points:
* update-cache won't accept ./file or fred/./file
The comment in update-cache.c reads:
/*
* We fundamentally don't like some paths: we don't want
* dot or dot-dot anywhere, and in fact,
Here's a quick rev of the chunking code. This is compatible with
git-current, where the hashes are of the *uncompressed* file.
The 'chunk' file gets dropped in at the same SHA1 filename as the
'blob' file, as it represents identical contents. Martin won't like
this (because of how the hash is co
On Wed, 20 Apr 2005, Chris Mason wrote:
>
> The patch below with your current tree brings my 100 patch test down to 22
> seconds again.
If you ever have a cache_entry bigger than 16384, your code will write
things out in the wrong order (write the new cache without flushing the
old buffer).
I've hacked together a prototype SCM that I think you folks might be
interested in. The announcement is here:
http://selenic.com/mercurial/announce.txt
It's at a very early stage right now and is likely to break if you
look at it wrong, but I have sucessfully managed to check in kernel
trees, do
On Wed, 20 Apr 2005 10:06:15 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I bet your SHA1 implementation is done with hand-optimized and scheduled
> x86 MMX code or something, while my poor G5 is probably using some slow
> generic routine. As a result, it only improved by 33% for me sin
On Tue, Apr 19, 2005 at 06:48:57PM -0400, C. Scott Ananian wrote:
> On Tue, 19 Apr 2005, David Meybohm wrote:
>
> >But doesn't this require assuming the distribution of MD5 is uniform,
> >and don't the papers finding collisions in less show it's not? So, your
> >birthday-argument for calculating t
On Wednesday 20 April 2005 13:52, Linus Torvalds wrote:
> On Wed, 20 Apr 2005, Chris Mason wrote:
> > The patch below with your current tree brings my 100 patch test down to
> > 22 seconds again.
>
> If you ever have a cache_entry bigger than 16384, your code will write
> things out in the wrong or
On Wed, 20 Apr 2005, Chris Mason wrote:
>
> Well, the difference there should be pretty hard to see with any benchmark.
> But I was being lazy...new patch attached. This one gets the same perf
> numbers, if this is still wrong then I really need some more coffee.
I did my preferred version. M
On Wed, 20 Apr 2005, Linus Torvalds wrote:
>
> It would be nicer for the cache to make the index file "header" be a
> "footer", and write it out last - that way we'd be able to do the SHA1 as
> we write rather than doing a two-pass thing. That's for another time.
That other time was now.
The
Dear diary, on Wed, Apr 20, 2005 at 12:08:24PM CEST, I got a letter
where Ingo Molnar <[EMAIL PROTECTED]> told me that...
> * Petr Baudis <[EMAIL PROTECTED]> wrote:
> > just FYI, Olivier Andrieu was kind enough to port his monotone-viz
> > tool to git (http://oandrieu.nerim.net/monotone-viz/ - u
Hello, Petr and everybody!
gittrack.sh allows abbreviated branch names, e.g. it's possible to run
"git track lin" when there is a branch called "linus".
I believe it's a bug, not a feature. Please look at this line from
gittrack.sh:
grep -q $(echo -e "^$name\t" | sed 's/\./\\./g') .git/remotes
> Ingo Molnar <[EMAIL PROTECTED]> [Wed, 20 Apr 2005]:
>
> * Petr Baudis <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > just FYI, Olivier Andrieu was kind enough to port his monotone-viz
> > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one
> > from the monotone repo
Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
where Ingo Molnar <[EMAIL PROTECTED]> told me that...
> [...]
> fatal: unable to execute 'gitmerge-file.sh'
> fatal: merge program failed
Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of
scripts which get
On Wed, 20 Apr 2005, David Greaves wrote:
>
> So maybe it's left as documented behaviour and higher level tools must
> manage the data they feed to it...
That was the plan.
I agree that "find . -type f | xargs update-cache --add --" in _theory_ is
a nice thing to do. But in practice, you want
* Petr Baudis <[EMAIL PROTECTED]> wrote:
> > yet another thing: what is the canonical 'pasky way' of simply nuking
> > the current files and checking out the latest tree (according to
> > .git/HEAD). Right now i'm using a script to:
> >
> > read-tree $(tree-id $(cat .git/HEAD))
> > checkou
* Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
> where Ingo Molnar <[EMAIL PROTECTED]> told me that...
> > [...]
> > fatal: unable to execute 'gitmerge-file.sh'
> > fatal: merge program failed
>
> Pure stupidity of mine, I forgot
Hello,
so I've "released" git-pasky-0.6.2 (my SCMish layer on top of Linus
Torvalds' git tree history storage system), find it at the usual
http://pasky.or.cz/~pasky/dev/git/
git-pasky-0.6 has couple of big changes; mainly enhanced git diff,
git patch (to be renamed to cg mkpatch),
Dear diary, on Wed, Apr 20, 2005 at 10:56:33PM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> cg pull will now always only pull, never merge.
>
> cg update will do pull + merge.
Note that what you will probably do _most_ by far is cg update.
You generally do cg p
Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter
where Ingo Molnar <[EMAIL PROTECTED]> told me that...
>
> * Petr Baudis <[EMAIL PROTECTED]> wrote:
>
> > > yet another thing: what is the canonical 'pasky way' of simply nuking
> > > the current files and checking out the latest
On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
> The short command version will change from 'git' to 'cg', which should
> be shorter to type and free the 'git' command for possible eventual
> entry gate for the git commands (so that they are more
> namespace-friendly, and it might m
Hey,
The following is a copy of the terminal session in question:
[EMAIL PROTECTED]:~/repo/tmp.repo$ ls
[EMAIL PROTECTED]:~/repo/tmp.repo$ init-db
defaulting to local storage area
[EMAIL PROTECTED]:~/repo/tmp.repo$ ls -l .git
total 4
drwxr-xr-x 258 rhys rhys 4096 2005-04-20 20:52 objects
[EMAIL
Dear diary, on Wed, Apr 20, 2005 at 11:28:35PM CEST, I got a letter
where Rhys Hardwick <[EMAIL PROTECTED]> told me that...
> Hey,
Hi,
> [EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
> c80156fafbac377ab35beb076090c8320f874f91
> Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
>
Cheers for the help!
Rhys
On Wednesday 20 Apr 2005 22:35, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 11:28:35PM CEST, I got a letter
> where Rhys Hardwick <[EMAIL PROTECTED]> told me that...
>
> > Hey,
>
> Hi,
>
> > [EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
> > c80156fafbac377a
On Wed, 20 Apr 2005, Rhys Hardwick wrote:
>
> [EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
> c80156fafbac377ab35beb076090c8320f874f91
> Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
>
> At this point, the command seems to be just waiting.
That's _exactly_ what it's doing
Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
where Greg KH <[EMAIL PROTECTED]> told me that...
> On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
> > The short command version will change from 'git' to 'cg', which should
> > be shorter to type and free the 'git'
I keep thinking perversely that we need something as obtuse as possible
in the unix tradition, but easy to type... git requires that the fingers
move off the home row...
how about "asdf" or "jkl"? :)
cg is singularly uncomfortable to type. I think that's why it isn't
commonly used.
Greg KH w
On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:
| Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
| where Greg KH <[EMAIL PROTECTED]> told me that...
| > On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
| > > The short command version will change from 'git'
On 20 April 2005 17:51, Mike Taht wrote:
> I keep thinking perversely that we need something as obtuse as possible
> in the unix tradition, but easy to type... git requires that the fingers
> move off the home row...
>
> how about "asdf" or "jkl"? :)
>
> cg is singularly uncomfortable to type. I t
Dear diary, on Wed, Apr 20, 2005 at 12:00:36PM CEST, I got a letter
where Tom Lord <[EMAIL PROTECTED]> told me that...
> >From the /Arch/ perspective: `git' technology will form the
> basis of a new archive/revlib/cache format and the basis
> of new network transports.
I think one thing git's obje
On Wed, 20 Apr 2005, Petr Baudis wrote:
>
> Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
> Configurator. CGT are Chimera Grid Tools, but I think we can clash
> with those - at least *I* wouldn't mind. ;-)
I realize that there is probably a law that there has to be a space,
Randy.Dunlap wrote:
On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:
| Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
| where Greg KH <[EMAIL PROTECTED]> told me that...
| > On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
| > > The short command version will
Linus Torvalds wrote:
On Wed, 20 Apr 2005, Rhys Hardwick wrote:
[EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
c80156fafbac377ab35beb076090c8320f874f91
Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
At this point, the command seems to be just waiting.
That's _exactly_ what it's
Linus,
I think you have made a mistake by moving the sha1 checksum from the
zipped form to the inflated form. Here is why:
What you have set in motion with `git' is an ad-hoc p2p network for
sharing filesystem trees -- a global distributed filesystem. I
believe your starter here has a good c
Dear diary, on Thu, Apr 21, 2005 at 12:09:06AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it
> be cool to just write "cg-" and see the command choices? Or
> "cg-up" and get cg-update done f
On Wed, 2005-04-20 at 07:59 -0700, Linus Torvalds wrote:
> external-parent
> comment for this parent
>
> and the nice thing about that is that now that information allows you to
> add external parents at any point.
>
> Why do it like this? First off, I think that the "
On Wed, 20 Apr 2005, Tom Lord wrote:
>
> I think you have made a mistake by moving the sha1 checksum from the
> zipped form to the inflated form. Here is why:
I'd have agreed with you (and I did, violently) if it wasn't for the
performance issues. It makes a huge difference for write-tree, and
On Wed, 2005-04-20 at 19:15 +0200, [EMAIL PROTECTED] wrote:
...
> As data, I used my /usr/src/linux which uses 301M and contains 20753 files and
> 1389 directories. To compute the key for a directory, I considered that its
> contents were a mapping from names to keys.
I suppose if you used the blo
1 - 100 of 154 matches
Mail list logo
