Dear diary, on Thu, Apr 21, 2005 at 06:28:34AM CEST, I got a letter
where Daniel Jacobowitz <[EMAIL PROTECTED]> told me that...
> On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
> >
> >
> > On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> > >
> > > My logic: it's a lot more intuit
If we just strip out the setting of $FROM and $MLIST, the script I use
to feed bk-commits-head@vger.kernel.org is perfectly generic. Petr, can
you include it in the tree so it gets updated as things change please?
--
dwmw2
gitfeedmaillist.sh
Description: application/shellscript
On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 20 Apr 2005, Linus Torvalds wrote:
> >
> > Pasky,
> > what do you think about this change to "git log"?
>
> Here's a slightly updated version.
>
> It's identical to the previous one, except that it also feeds the re
On Thu, April 21, 2005 1:14 am, Randy.Dunlap said:
>> In _any_ real system you'll be getting thousands of lines of output.
>> Possibly millions. unpaginated? What the hell are you talking about?
>
> Who in the world would look at thousands or millions of lines on a
> tty using a pager?
>
This con
Don't apply this patch and change GIT_COMPRESSION unless you know what
you are doing and why you are doing it. You will break an older version
of git. You may break a newer version of git. You have been warned.
I also note that there's a bzlib out there.
cache.h: 828d660ab82bb35a1ca632a2ba4620d
Just to clarify this was a git add of the linux-2.6.11.7 sources (sorry,
untimed) , and timing the git commit.
Mo betta data latah.
Mike Taht wrote:
I started rolling a tool to measure various aspects of git performance.
I will start looking at merge next, and at workloads different from the
ke
On Wed, 20 Apr 2005 21:00:44 -0700 (PDT) Linus Torvalds wrote:
|
|
| On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
| >
| > My logic: it's a lot more intuitive to say "cg-log | less" to get
| > paginated output than it is to say "cg-log | cat" to get unpaginated
| > output.
|
| I disagree.
|
|
> "DJ" == Dave Jones <[EMAIL PROTECTED]> writes:
DJ> I used to do 'bk changes | grep \[AGPGART\] -C3 | head' on a
DJ> regular basis, just to be able to answer 'hey, did cset x
DJ> get into tree y?' questions from users. which is the
DJ> probably the closest I came to non-paginated usage.
I a
I started rolling a tool to measure various aspects of git performance.
I will start looking at merge next, and at workloads different from the
kernel (gcc4 anyone?) ...
The only data points worth sharing a this point are:
That doing the compression at a level of 3, rather than the max of 9,
cu
Linus Torvalds wrote:
> I realize that there is probably a law that there has to be a space, but I
> actually personally use tab-completion all the time
You can actually teach bash3 to do that (yes, with space).
In general, though, I tend to agree -- dashes work with more shells and
avoid names
On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> >
> > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > paginated output than it is to say "cg-log | cat" to get unpaginated
> > output.
>
> I disagree.
>
>
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.
You don't know the deepest parents to fetch until you've read everything
more recen
On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
> > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > paginated output than it is to say "cg-log | cat" to get unpaginated
> > output.
> I disagree.
>
> There is _never_ any valid situation where you do "cg
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> And as you can see, the output matches "diff-tree -r" output (we always do
LT> "-r", since the index is always fully populated). All the same rules: "+"
LT> means added file, "-" means removed file, and "*" means changed file. You
LT>
On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
>
> My logic: it's a lot more intuitive to say "cg-log | less" to get
> paginated output than it is to say "cg-log | cat" to get unpaginated
> output.
I disagree.
There is _never_ any valid situation where you do "cg-log" with
unpaginated output t
On Wed, April 20, 2005 11:35 pm, Daniel Jacobowitz said:
> My logic: it's a lot more intuitive to say "cg-log | less" to get
paginated output than it is to say "cg-log | cat" to get unpaginated
output.
>
Daniel,
All you'd have to do is:
$ export PAGER=cat
to get the behavior you want.
Sean
On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
> Here's a slightly updated version.
>
> It's identical to the previous one, except that it also feeds the result
> through "| ${PAGER:-less}" which makes it a lot more useful, in my
> opinion.
>
> If you redirect the output to a n
When I first read about git a few days ago, I was pretty surprised by
how similar it seemed to the project I've been working on for several
years. (Coming off BK, I would have expected a more Darcs/Codeville
kind of change-merging-centric approach.)
Since I don't see any mention of Vesta on this
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Date: Sun, 17 Apr 2005 21:59:00 +0200
> From: Petr Baudis <[EMAIL PROTECTED]>
> To: Daniel Barkalow <[EMAIL PROTECTED]>
> Cc: git@vger.kernel.org
> Subject: Re: [3/5] Add http-pull
>
> Dear diary, on Sun, Apr 17, 2005 at 09:24:27PM CEST, I got a letter
> w
Hi,
I uploaded a new snapshot to http://www.absolutegiganten.org/wit
The changes are
0.0.4:
* c2html usage is configurable now
* add flexible /changelog/, and all
* improve display of dates
* implement all the nice ideas from Kay Sievers gitweb.pl
* try to validate most of the dynamic URIs
* sa
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Petr Baudis wrote:
| 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/
When I run `git pull', I get:
Tr
Usage string fixes to make maintenance easier (only one instance
of a string to update not multiple copies). I've spotted and
corrected inconsistent usage text in diff-tree while doing this.
Also diff-cache and read-tree usage text have been corrected to
match their up-to-date features. Earlier,
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Wed, 20 Apr 2005, Junio C Hamano wrote:
>>
>> Sorry, but the numbering is wrong this should have been [4/5]
>> not [3/4]. The contents should be fine, though.
LT> Applied and pushed out.
Thanks. I have alreay a bugfix and a half
Hello!
Perhaps it's a naive question, but how do I switch between branches? I
mean an equivalent of "svn switch" or "cvs update -r branch" that would
reuse the existing working directory.
I tried to switch a git-pasky working directory to the linus branch.
Here's what I tried:
git track linus
> 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
Hi, Petr!
On Thu, 2005-04-21 at 01:21 +0200, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 09:48:30PM CEST, I got a letter
> where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> > --- a/gittrack.sh
> > +++ b/gittrack.sh
> > @@ -35,7 +35,7 @@ die () {
> > mkdir -p .git/heads
> >
>
On Wed, Apr 20, 2005 at 10:42:53AM +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 w
On Wed, 20 Apr 2005, Linus Torvalds wrote:
>
> Pasky,
> what do you think about this change to "git log"?
Here's a slightly updated version.
It's identical to the previous one, except that it also feeds the result
through "| ${PAGER:-less}" which makes it a lot more useful, in my
opinion.
On Wed, 20 Apr 2005, Junio C Hamano wrote:
>
> Sorry, but the numbering is wrong this should have been [4/5]
> not [3/4]. The contents should be fine, though.
Applied and pushed out.
Btw, I edited your subject lines to make them be more specific
to one particular patch.
Linus
> "JCH" == Junio C Hamano <[EMAIL PROTECTED]> writes:
JCH> Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
JCH> function. The command can take either tree or commit IDs with
JCH> this patch.
Sorry, but the numbering is wrong this should have been [4/5]
not [3/4]. The contents
Updates read-tree to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
The change involves a slight modification of how it recurses down
the tree. Earlier the caller only supplied SHA1 and the recurser
read the object using it, but
On Wednesday 20 April 2005 05:15 pm, Steven Cole wrote:
> On Wednesday 20 April 2005 05:12 pm, Petr Baudis wrote:
> > Dear diary, on Thu, Apr 21, 2005 at 01:06:09AM CEST, I got a letter
> > where Steven Cole <[EMAIL PROTECTED]> told me that...
> > > After getting the latest tarball, and make, make
Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
ls-tree.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
ls-tree.c: c063640c114634
Updates diff-tree.c to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with this patch.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
diff-tree.c | 25 -
1 files changed, 4 insertions(+), 21 deletions(-)
diff-t
Updates diff-cache.c to use read_tree_with_tree_or_commit_sha1()
function. The end-user visible result is the same --- the command
takes either tree or commit ID.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
diff-cache.c | 17 +
1 files changed, 1 insertion(+), 16 del
Linus,
sorry for bringing up an issue that is already 8 hours old.
LT> I don't think that's a good interface. It changes the sha1 passed into it:
LT> that may actually be nice, since you may want to know what it changed to,
LT> but I think you'd want to have that as an (optional) separate
Pasky,
what do you think about this change to "git log"?
It makes it a _lot_ easier to parse the result, as it indents all the
comments by two spaces, meaning that the header is clearly marked, and you
can then do various 'sed'/'grep' things with nice normal regular
expressions like '^parent' w
Tom Lord <[EMAIL PROTECTED]> writes:
> Thank you for your experiment.
you are welcome.
> I think that to a large extent you are seeing artifacts
> of the questionable trade-offs that (reports tell me) the
> ext* filesystems make. With a different filesystem, the
> results would be very differ
Petr Baudis wrote:
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, 20 Apr 2005, Linus Torvalds wrote:
What's the disk usage results? I'm on ext3, for example, which means that
even small files invariably take up 4.125kB on disk (with the inode).
Even uncompressed, most source files tend to be small. Compressed, I'm
seeing the median blob size being ~1.6kB
(I'll have to study/think about that for a while before a proper
reply. Tomorrow, probably.)
Thanks,
-t
-
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
Dear diary, on Tue, Apr 19, 2005 at 09:04:16PM CEST, I got a letter
where David Greaves <[EMAIL PROTECTED]> told me that...
> I don't love the 'require gitadd.pl' but it's a gradual start...
I hate it, for one. ;-)
> Cogito.pm seems to be a good place for the library stuff.
Sounds sensible.
> g
Pavel wrote:
> sed -ne "/^$name\t/p" .git/remotes | grep -q .
Consider using the following to look for a match of $name with
the first tab separated field of the remotes file (and to avoid
using 'grep -q', which is not in all grep's, so far as I know):
cut -f1 .git/remotes | grep -F
Dear diary, on Wed, Apr 20, 2005 at 09:48:30PM CEST, I got a letter
where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> --- a/gittrack.sh
> +++ b/gittrack.sh
> @@ -35,7 +35,7 @@ die () {
> mkdir -p .git/heads
>
> if [ "$name" ]; then
> - grep -q $(echo -e "^$name\t" | sed 's/\./\\./g')
On Wednesday 20 April 2005 05:12 pm, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 01:06:09AM CEST, I got a letter
> where Steven Cole <[EMAIL PROTECTED]> told me that...
> > After getting the latest tarball, and make, make install:
> >
> > Tree change:
> > 55f9d5042603fff4ddfaf4e5f004
Dear diary, on Thu, Apr 21, 2005 at 01:06:09AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> After getting the latest tarball, and make, make install:
>
> Tree change:
> 55f9d5042603fff4ddfaf4e5f004d2995286d6d3:a46844fcb6afef1f7a2d93f391c82f08ea31
> *100755->100
After getting the latest tarball, and make, make install:
[EMAIL PROTECTED] git-pasky-0.6.2]$ git pull pasky
MOTD: Welcome to Petr Baudis' rsync archive.
MOTD:
MOTD: If you are pulling my git branch, please do not repeat that
MOTD: every five minutes or so - new stuff is likely not going to
MOT
On Thu, Apr 21, 2005 at 12:28:15AM +0200, Petr Baudis wrote:
> 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-
From: [EMAIL PROTECTED]
Thank you for your experiment. I'm not surprised by the
result but it is very nice to know that my expectations
are right.
I think that to a large extent you are seeing artifacts
of the questionable trade-offs that (reports tell me) the
ext* filesystems make. Wit
On Wed, 20 Apr 2005, Tom Lord wrote:
>
> How many times per day do you invoke `write-tree' and why?
Every single commit does a write-tree, so when I merge with Andrew, it's
usually a series of 100-250 of them in a row.
(Actually, _usualyl_ it's smaller series, but it's the big series that can
From: Linus Torvalds <[EMAIL PROTECTED]>
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
perf
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
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
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 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 "
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, 20 Apr 2005, C. Scott Ananian wrote:
>
> I'm hoping my 'chunking' patches will fix this. This ought to reduce the
> size of the object store by (in effect) doing delta compression; rsync
> will then Do The Right Thing and only transfer the needed deltas.
> Running some benchmarks right
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
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
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
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,
On Wed, 20 Apr 2005, Petr Baudis wrote:
I think one thing git's objects database is not very well suited for are
network transports. You want to have something smart doing the
transports, comparing trees so that it can do some delta compression;
that could probably reduce the amount of data needed
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
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'
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
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'
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
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
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
>
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
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
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
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
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
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),
* 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
* 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
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
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
> 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
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
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
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
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 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 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 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
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, 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).
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
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,
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
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 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
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
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
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
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
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, 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
1 - 100 of 154 matches
Mail list logo
