* Re: [PATCH] Add "git push"
From: Petr Baudis @ 2005-04-21 20:41 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421124333.AB2CE7F887@smurf.noris.de>
Dear diary, on Thu, Apr 21, 2005 at 02:43:33PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> This patch adds the ability to "git push", as the obvious converse of
> "git pull".
While lack of locking is a problem for git-pasky too, for this git push
it is a downright disaster waiting to happen. It might be also a good
idea to check for remote 'blocked' file, which must exist and contain
only a "pushtree" line. This is so that no (sensible) real working tree
is attached to it, which would be a disaster for it too.
You probably don't want to allow pushing if your local tree is blocked.
And you want to allow pushing only when HEAD is your ancestor. (Helper
tool wanted for this - we need this in git merge badly too.)
BTW, it contains some unrelated and seemingly irrelevant tracking stuff.
--
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 20:43 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <42680FCC.6030901@dgreaves.com>
Dear diary, on Thu, Apr 21, 2005 at 10:40:44PM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> @@ -156,3 +317,23 @@
> unpack-file
> unpack-file.c <sha1>
>
> +
> +
> +git Environment Variables
> +GIT_CACHE_DIRECTORY
> +AUTHOR_NAME
> +AUTHOR_EMAIL
> +AUTHOR_DATE
> +RSYNC_FLAGS
> +GIT_INDEX_FILE
> +
> +
> +.git Repository Files
> +
> +.git/HEAD
> +This file always contains the last (head) commit object created for this branch of the repository.
> +(Usually symlinked to a file in .git/heads/)
> +
> +.git/heads/
> +This directory contains a file for each branch of the .git repository.
> +The name of the file is the friendly name of the branch (eg pasky)
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).
--
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: Pasky problem with 'git init URL'
From: Martin Schlemmer @ 2005-04-21 21:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050421202928.GH7443@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 3595 bytes --]
On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Hi,
>
> Hi,
>
> > Just pulled linux-2.6.git, and got this:
> >
> > ----
> > New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > Tracked branch, applying changes...
> > Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -> 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > to a2755a80f40e5794ddc20e00f781af9d6320fafb...
> >
> > Enter commit message, terminated by ctrl-D on a separate line:
> > Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > ----
> >
> > Weird thing was that I made no changes.
>
> did you compensate for the renamed hashes? Didn't you before update from
> some very old git-pasky version?
>
> Actually, did you do that git init _after_ the unsuccessful pull, or
> before?
>
I re-pulled it from scratch after the sha1 changes, so not that. Just
the next pull that went wonky.
> > Digging a bit deeper, I saw that .git/HEAD was a symlink
> > to .git/heads/master, and the tracked branch was 'origin'. Due to the
> > fact that Linus only have a .git/heads/master on his rsync, and this
> > thus updated to the new sha1, but the 'origin' (and tracked) head is
> > still pointing to an older sha1 caused this confusion.
>
> Duh. The remote branch always grabs the HEAD over there; you don't need
> to care about the various branches over there, and you really do not
> *want* to care. Actually I might add some ^branchname to the rsync URL,
> to be able to refer to particular branches inside of the repository.
>
Well, I just did a quick peek. I thought it just changed the local head
to the sha1 of the remote, and then updated the local files - haven't
yet looked at gitmerge.sh.
> > I replicated the linux tree via:
> >
> > ----
> > git init URL
> > ----
> >
> > So I had a look at gitinit.sh, which first creates the .git/heads/master
> > and symlinks HEAD to it, then on seeing a URL was supplied, creates
> > a .git/heads/origin, track it, but do *not* change the .git/HEAD
> > symlink ... Is this intended? I see also that gittrack.sh do not update
> > the HEAD symlink ... Is this also intended?
>
> Yes.
>
> You never work directly on the remote branch. Ever. That's what this
> tracking stuff is for; you set up a local branch which follows the
> remote one.
>
Ok, but for some weird reason it wanted to commit the merge between
remote and local.
> Otherwise, you fork to two trees, one is remote branch, second is local
> branch, and you do git pull remotebranch in the second. You are in
> trouble now. Also, if you do some local commit on the remote branch,
> what would happen? This kind of stuff is why I decided that you just
> cannot work on remote branches directly.
>
> > The last option however brings a problem or two. First, how do you do
> > the multi-head thing? Maybe add a command 'git lsheads' (and while at
> > it, also add 'git lstags'?)? Secondly, if there was more than one head,
>
> Perhaps it would be useful to have some "command classes" (with at least
> cg-*-(add|ls|rm)), like:
>
> cg-branch-ls
> cg-remote-rm
> cg-tag-add
>
Might make things more sane.
> > the local copy needs to be checked out ... don't know if 'git cancel' is
> > the logical thing the user will think to do ('git clone' perhaps?) ...
>
> I don't know what do you mean here.
>
Don't worry, no biggy.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pasky problem with 'git init URL'
From: John Stoffel @ 2005-04-21 21:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Schlemmer, GIT Mailing Lists
In-Reply-To: <20050421202928.GH7443@pasky.ji.cz>
>>>>> "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? Something like:
git lsbranch
git lstag
...
Or something mildly along those lines. I don't even care what ORDER
they are, whether the 'ls' comes before or after the object type it
works on. But make it the same every where, so that ls, rm, add,
check, foo, barzle, ... all use the same format.
Makes it much much easier to extrapolate what command syntax to use
when new objects to be acted upon are added.
Does a standard like:
git <objecttype> <command> <args> [<obj> ...]
make sense? Easy to script, easy to remember. Even munging
<objtype><command> into a single word is ok.
John
^ 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
* 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: 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: 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: 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: [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: [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: 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: [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: 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
* 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: 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
* 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: 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
* [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: [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
* 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: 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: 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: [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: [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
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