* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-22 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504221632.26278.mason@suse.com>
On Friday 22 April 2005 16:32, Chris Mason wrote:
> If I pack every 64k (uncompressed), the checkout-tree time goes down to
> 3m14s. That's a very big difference considering how stupid my code is .git
> was only 20% smaller with 64k chunks. I should be able to do better...I'll
> do one more run.
>
This run also packed tree files together (everything produced by write-tree
went into a packed file), but not the commits. I estimate I could save about
another 168m by packing the tree files and commits into the same file with
the blobs, but this wouldn't make any of the times below faster.
git - original (28k commits) packed
FS size 2,675,408k 1,723,820k
read-tree 24.45s 18.9s
checkout-cache 4m30s 3m5s
patch time 2h30m 1h55m
The format for the packed files could be smarter, such that it didn't require
decompressing the whole packed file to read one item. I would guess I could
get another 20% checkout-cache performance out of it via more tuning, and
probably another 10% of space savings.
Of course, none of this is likely to convince you ;) If you decide later on
it's worthwhile, I don't think it would be difficult to add then.
-chris
^ permalink raw reply
* git remote repositories
From: Dan Weber @ 2005-04-22 23:38 UTC (permalink / raw)
To: Git Mailing List
Hi,
It wasn't that long ago that the pasky git tree was relocated. This
required a modification to the .git directory in a local pull. A dns
system could be built to ensure the following:
A) quick easy lookup of archive locations
B) handle changes of repository location
C) add mirror support
So heres the plan...
I do a lot of work in sip/voip field, and our approach to handling backup
proxies and routers is to use a dns srv record.
Here's how it works for voip/sip.
_{protocol}._{transport}.{name}.hostname.org
A sample lookup:
dig SRV _sip._udp.proxy-dca.broadvoice.com
;; QUESTION SECTION:
;_sip._udp.proxy-dca.broadvoice.com. IN SRV
;; ANSWER SECTION:
_sip._udp.proxy-dca.broadvoice.com. 86400 IN SRV 1 0 5060
proxy.mia.broadvoice.com.
_sip._udp.proxy-dca.broadvoice.com. 86400 IN SRV 0 0 5060
proxy.dca.broadvoice.com.
Now of course we could null out some of those fields and swap sip for git
and udp for rsync, then replace proxy.foo to rsync://host/path/to/git.
Since we're using rsync, mirroring is simplified by just rsyncing the
trees.
Dan
^ permalink raw reply
* RE: [3/5] Add http-pull
From: Luck, Tony @ 2005-04-22 23:34 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: Brad Roberts, git
>But if you download 1000 files of the 1010 you need, and then your network
>goes down, you will need to download those 1000 again when it comes back,
>because you can't save them unless you have the full history.
So you could make the temporary object repository persistant between pulls
to avoid reloading them across the wire. Something like:
get_commit(sha1)
{
if (sha1 in real_repo) -> done
if (!(sha1 in tmp_repo))
load sha1 to tmp_repo
get_tree(sha1->tree)
for each parent
get_commit(sha1->parent)
move sha1 from tmp_repo to real_repo
}
get_tree(sha1)
{
if (sha1 in real_repo) -> done
if (!(sha1 in tmp_repo))
load sha1 to tmp repo
for_each (sha1->entry) {
case blob: if (!sha1 in real_repo) load to real_repo
case tree: get_tree()
}
move sha1 from tmp_repo to real_repo
}
The "load sha1 to xxx_repo" needs to be smarter than my dumb wget
based script ... it must confirm the sha1 of the object being loaded
before installing (even into the tmp_repo).
-Tony
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Andy Isaacson @ 2005-04-22 23:30 UTC (permalink / raw)
To: Kyle Hayes; +Cc: azarah, git
In-Reply-To: <1114186599.31076.409.camel@axer.marchex.com>
On Fri, Apr 22, 2005 at 09:16:39AM -0700, Kyle Hayes wrote:
> if(comma)
> if(semi)
> /* lastname, firstname; room #; phone # format */
> *semi = 0;
> else
> *comma = 0;
> else if(semi)
> *semi = 0;
That's a really complicated way of writing
if(semi) *semi = 0;
else if(comma) *comma = 0;
(The two code fragments are precisely identical. Mmmm, strength
reduction.)
-andy
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <20050422224358.GF21204@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 05:24:27PM CEST, I got a letter
> where Rhys Hardwick <rhys@rhyshardwick.co.uk> told me that...
>
>>>Seems your /bin/sh do not support 'echo -e' ... Know what provides
>>>your /bin/sh (I think ash at least do support it)?
>>>
>>>Petr, I think you should really start to consider going full bash?
>>
>>I use dash...
>
>
> FYI, I've succumbed to the real world out there and switched the whole
> thing to use bash.
>
Thanks for that Petr. I am wondering, what do you and the other
developers use? When I apt-get install ash (debian unstable), which I
tried to do to fix this problem, all it did was add a symlink to dash!!
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Linus Torvalds @ 2005-04-22 23:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Greg KH, git
In-Reply-To: <20050422230551.GI21204@pasky.ji.cz>
On Sat, 23 Apr 2005, Petr Baudis wrote:
>
> Just FYI, this is bug in core git's diff-cache;
Nice find.
Yes, I told you guys I hadn't tested it well ;)
"diff-cache" does the same "diff trees in lockstep" thing that "diff-tree"
does, but it's actually more complex, since the _tree_ part always needs
to be recursively followed, while the _cache_ part is this linear list
that is already expanded.
Which just made the whole algorithm very messy.
Once I found out how nasty it was to do that compare, I was actually
planning to re-write the thing using the same approach that "read-tree -m
<tree>" does - ie move the tree information _into_ the in-memory cache, at
which point it should be absolutely trivial to compare the two. But since
the horrid algorithm seemed to end up working, I never did.
I'm not even going to debug this bug. I'm just going to rewrite diff-cache
to do what I should have done originally, ie use the power of the
in-memory cache. That's also automatically going to properly warn about
unmerged files.
Give me five minutes ;)
Linus
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Martin Schlemmer @ 2005-04-22 23:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, tony.luck, Brad Roberts, git
In-Reply-To: <Pine.LNX.4.21.0504221911340.30848-100000@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
On Fri, 2005-04-22 at 19:12 -0400, Daniel Barkalow wrote:
> On Sat, 23 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sat, Apr 23, 2005 at 01:00:33AM CEST, I got a letter
> > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > > On Sat, 23 Apr 2005, Petr Baudis wrote:
> > >
> > > > Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter
> > > > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > > >
> > > > Huh. Why? You just go back to history until you find a commit you
> > > > already have. If you did it the way as Tony described, if you have that
> > > > commit, you can be sure that you have everything it depends on too.
> > >
> > > But if you download 1000 files of the 1010 you need, and then your network
> > > goes down, you will need to download those 1000 again when it comes back,
> > > because you can't save them unless you have the full history.
> >
> > Why can't I? I think I can do that perfectly fine. The worst thing that
> > can happen is that fsck-cache will complain a bit.
>
> Not if you're using the fact that you don't have them to tell you that you
> still need the other 10, which is what tony's scheme would do.
>
Any way (like maybe extending one of the web interfaces already around)
to first get a list of all the sha1's you need, and then starting from
the bottom like Tony/Petr wants you to do?
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-22 23:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: tony.luck, Brad Roberts, git
In-Reply-To: <20050422230855.GJ21204@pasky.ji.cz>
On Sat, 23 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 23, 2005 at 01:00:33AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Sat, 23 Apr 2005, Petr Baudis wrote:
> >
> > > Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter
> > > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > >
> > > Huh. Why? You just go back to history until you find a commit you
> > > already have. If you did it the way as Tony described, if you have that
> > > commit, you can be sure that you have everything it depends on too.
> >
> > But if you download 1000 files of the 1010 you need, and then your network
> > goes down, you will need to download those 1000 again when it comes back,
> > because you can't save them unless you have the full history.
>
> Why can't I? I think I can do that perfectly fine. The worst thing that
> can happen is that fsck-cache will complain a bit.
Not if you're using the fact that you don't have them to tell you that you
still need the other 10, which is what tony's scheme would do.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re:
From: Martin Schlemmer @ 2005-04-22 23:16 UTC (permalink / raw)
To: atani; +Cc: GIT Mailing List
In-Reply-To: <1114208394.7623@tsunami.he.net>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Fri, 2005-04-22 at 15:19 -0700, atani wrote:
<snip>
> Martin Schlemmer, I ran "emerge sync" today and found git has been
> added to portage, version 0.5. Also note that there are now two "git"
> entries within portage app-misc/git and dev-util/git. app-misc/git is
> GNU Interactive Tools
>
Yeah, I know - that is actually why I complained to r3pek, as most of
the guys interested in doing patches, etc will prob pull and build
themselfs, but the user that just want to get the latest kernel, will
rather want cogito (or git-pasky). So basically the git I mentioned
that I wanted added (or maybe replace the current one in the tree
depending on what r3pek do), was Petr's stuff ...
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Petr Baudis @ 2005-04-22 23:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: tony.luck, Brad Roberts, git
In-Reply-To: <Pine.LNX.4.21.0504221844420.30848-100000@iabervon.org>
Dear diary, on Sat, Apr 23, 2005 at 01:00:33AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sat, 23 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter
> > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> >
> > Huh. Why? You just go back to history until you find a commit you
> > already have. If you did it the way as Tony described, if you have that
> > commit, you can be sure that you have everything it depends on too.
>
> But if you download 1000 files of the 1010 you need, and then your network
> goes down, you will need to download those 1000 again when it comes back,
> because you can't save them unless you have the full history.
Why can't I? I think I can do that perfectly fine. The worst thing that
can happen is that fsck-cache will complain a bit.
--
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: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Petr Baudis @ 2005-04-22 23:05 UTC (permalink / raw)
To: Greg KH; +Cc: torvalds, git
In-Reply-To: <20050422064936.GA10854@kroah.com>
Dear diary, on Fri, Apr 22, 2005 at 08:49:37AM CEST, I got a letter
where Greg KH <greg@kroah.com> told me that...
> On Fri, Apr 22, 2005 at 05:09:31AM +0200, Petr Baudis wrote:
> > Hello,
> >
> > FYI, I've released git-pasky-0.6.3 earlier in the night.
>
> Hm, fun thing to try:
> go into a kernel git tree.
> rm Makefile
> git diff
>
> Watch it as it thinks that every Makefile in the kernel tree is now
> gone...
Just FYI, this is bug in core git's diff-cache; also, when you update
the cache properly (either do
git rm Makefile
or
update-cache --remove Makefile
), it works fine. diff-cache should still not fail so horribly, though.
Unfortunately, I don't have time to debug it now. I will look at it
tomorrow if noone will fix it before. ;-)
--
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: [git pasky] tarball question
From: Martin Schlemmer @ 2005-04-22 23:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050422224251.GE21204@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
On Sat, 2005-04-23 at 00:42 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 04:31:43PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Hi,
>
> Hi,
>
> > I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
> > the .git database included as well (btw, great stuff renaming it to
> > something more distributable), but its going to be a pita for users of
> > source based distro's like us (Gentoo), as well as our mirrors if it
> > gets much bigger. (Already asked r3pek to add it to portage).
>
> yes; that was actually the plan, it's just that my memory is so
> volatile...
>
Yep, saw before you posted about the change in URL, thanks.
> > How about ripping the .git directory from the next release, and just
> > have a un-numbered tarball (like you used to) that have the latest
> > snapshot of the .git directory for those that want to do git-pasky
> > development? Should even make things easier your side, as you could
> > just do a cron to update it one a day/whatever.
>
> Does it actually make sense to keep a tarball with history? Just build
> git-pasky and do git init. (Or rsync it manually.)
>
Well, I did not know about kernel.org hosting it, so I thought it might
help due to your reasons for initially tarballing the whole thing =)
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-22 23:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: tony.luck, Brad Roberts, git
In-Reply-To: <20050422224008.GD21204@pasky.ji.cz>
On Sat, 23 Apr 2005, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> Huh. Why? You just go back to history until you find a commit you
> already have. If you did it the way as Tony described, if you have that
> commit, you can be sure that you have everything it depends on too.
But if you download 1000 files of the 1010 you need, and then your network
goes down, you will need to download those 1000 again when it comes back,
because you can't save them unless you have the full history.
There's also no way to say, give me just the head and the tree associated
with it, let me check it out, next download the commit history so I can do
my merge most correctly, let me do that, finally download the intermediate
blobs and trees so that I can track down where something broke.
Ideally, you'd be able to put the latest head and tree into your database,
and it would know that you just hadn't gotten the ancestor yet, and would
be able to determine from your personal metadata (rather than based on
what you had or lacked) that you believe you have all ancestors of the
previous time you pulled, you don't want the trees that Linus merged in
midway through, but everything else you just don't have yet.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: First web interface and service API draft
From: Petr Baudis @ 2005-04-22 22:57 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114176579.3233.42.camel@localhost>
Dear diary, on Fri, Apr 22, 2005 at 03:29:39PM CEST, I got a letter
where Christian Meder <chris@absolutegiganten.org> told me that...
> > > /<project>
> > >
> > > Ok. The URI should start by stating the project name
> > > e.g. /linux-2.6. This does bloat the URI slightly but I don't think
> > > that we want to have one root namespace per git archive in the long
> > > run. Additionally you can always put rewriting or redirecting rules at
> > > the root level for additional convenience when there's an obvious
> > > default project.
> > >
> > > Should provide some meta data, stats, etc. if available.
> >
> > I don't think this makes much sense. I think you should just apply -p1
> > to all the directories, and define that there should be some / page
> > which should contain some metadata regarding the repository you are
> > accessing (probably branches, tags, and such).
>
> Hi,
Hi,
> remember that I want to stay stateless as long as possible so everything
> important has to be encoded in the url. So somewhere in the url the git
> archive to show has to be encoded. If I remove the <project> portion how
> do I know on the server side which repo to show ?
since you are configured appropriately.
You need to be anyway. Someone needs to tell you or your web server
"this lives at http://pasky.or.cz/wit/". So you bind "this" to the
given repository.
No problem with an additional configuration possibility to say "at that
place, clone your life place for the given repositories", but if I want
to have just a single repository at a given URL, it should be possible.
I'm just trying to argue that having it _forced_ to have <project> as
the part of the URL is useless; this is matter of configuration.
> > > * Blob data should be probably binary ?
> >
> > What do you mean by binary?
>
> content-type: binary/octet-stream
Ah. So just as-is, you mean?
> > Anything wrong with putting ls-tree output there?
>
> ls-tree output should be in .html (see below)
What if I actually want to process it by a script?
> > > -------
> > > /<project>/tree/<tree-sha1>
> > >
> > > Tree objects are served in binary form. Primary audience are scripts,
> > > etc. Human beings will probably get a heart attack when they
> > > accidentally visit this URI.
> >
> > Binary form is unusable for scripts.
>
> Why should it be unusable for a downloading script. It's just the raw
> git object.
>
> > We should also have /gitobj/<sha1> for fetching the raw git objects.
>
> Everything above is supposed to be raw git objects. No special encoding
> whatever.
You have a consistency problem here.
Raw git objects as in database contain the leading object type at the
start, then possibly some more stuff, then '\0' and then compressed
binary stuff. You mean you are exporting _this_ stuff through this?
That's not very useful except for http-pull, if you as me. It also does
not blend well with the fact that you say commits are in text or so.
> > > -------
> > > /<project>/tree/<tree-sha1>/diff/<ancestor-tree-sha1>/html
> > >
> > > Non recursive HTML view of the objects which are contained in the diff
> > > fully linked with the individual HTML views.
> >
> > Why not .html?
>
> I think .html isn't very clear because it would
> be ..../<ancestor-tree-sha1>.html which somehow looks like it has
> anything to do with the ancestor-tree. But it's the html version of the
> _diff_ and not the ancestor-tree.
Perhaps /tree/<sha1>.html/diff/<ancestor> ?
I'd lend to ?diff=<ancestor> more and more. The path part of URI is
there to express _hierarchy_, I think you are abusing that when there is
no hierarchy.
> > For consistency, I'd stay with the plaintext output by default, .html if
> > requested.
>
> Remember that I'm just sitting on top of git and not git-pasky right
> now. So there's no canonical changelog plaintext output for me. But I'm
> not religious about that.
But there is canonical HTML output for you? ;-)
> > OTOH, I'd use
> >
> > /log/<commit>
> >
> > to specify what commit to start at. It just does not make sense
> > otherwise, you would not know where to start
>
> Start for the changelog is always head, but I guess that's pretty
> standard. With git log you always start at the head too.
If you are sitting on top of git and not git-pasky, you have no assured
HEAD information at all.
> If you want to start at a specific commit. Why not start
> at /linux-2.6/commit/<sha1>.html ?
And how does that give me the changelog?
> > I think the <commit> should follow the same or similar rules as Cogito
> > id decoding. E.g. to get latest Linus' changelog, you'd do
> >
> > /log/linus
>
> Like I said above I think the shown head should be encoded in the
> project id.
I thought the project was mapped to repository? But I might just have
blindly assumed that. ;-) (That does not make me like your approach
more, 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: "GIT_INDEX_FILE" environment variable
From: Linus Torvalds @ 2005-04-22 22:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20050422223341.GC21204@pasky.ji.cz>
On Sat, 23 Apr 2005, Petr Baudis wrote:
>
> Note that Cogito almost actually does not use show-diff anymore.
> I'm doing diff-cache now, since that is what matters to me.
Indeed. "diff-tree" (between releases) and "diff-cache" (between a
release and the current state) are clearly much more fundamental
operations.
Also, they have absolutely zero policy, and they're designed to be used
with the same scripting engines (ie hopefully you can use just one tool to
show the output of either in whatever format you want).
They show you what the canonical names and associated information is, and
that's it. What you _do_ with them ends up being outside the scope of git,
exactly like it should be. Details like "what format of diff" to produce
should be left to the tools around it.
In contrast, "show-diff" was _literally_ written to check what the
difference between the "real" file and a "sha1" file was, back when I
couldn't write the sha1 files correctly (ie I corrupted anything that
didn't fit in the first "[un]compression block", and then calling "diff"
to show the difference between the original and the regenerated data was
very important).
So "show-diff" just kind of expanded from an early debugging tool to
something that _almost_ looks like a real tool. But it's absolutely the
right thing to use "diff-tree" and "diff-cache" instead.
Linus
^ permalink raw reply
* wit suggestion
From: David Greaves @ 2005-04-22 22:46 UTC (permalink / raw)
To: Christian Meder; +Cc: GIT Mailing Lists
Hi Christian
Can I suggest a 'summary diff' option
It's basically a diff between the tree of the commit and the tree of the
parent commit
It would show what files have changed rather than the diff of the files
that have changed. (kinda like diffstat without the ++++++++ for now)
(or maybe just do a diffstat if it's easier)
Of course you could click through to a per-file diff eventually...
David
--
^ permalink raw reply
* Re: First web interface and service API draft
From: Petr Baudis @ 2005-04-22 22:45 UTC (permalink / raw)
To: Christian Meder, git
In-Reply-To: <20050422142342.GG30915@delft.aura.cs.cmu.edu>
Dear diary, on Fri, Apr 22, 2005 at 04:23:42PM CEST, I got a letter
where Jan Harkes <jaharkes@cs.cmu.edu> told me that...
> On Fri, Apr 22, 2005 at 12:41:56PM +0200, Christian Meder wrote:
> > -------
> > /<project>/blob/<blob-sha1>
> > /<project>/commit/<commit-sha1>
>
> It is trivial to find an object when given a sha, but to know the object
> type you'd have to decompress it and check inside. Also the way git
> stores these things you can't have both a blob and a commit with the
> same sha anyways.
>
> So why not use,
> /<project/<hexadecimal sha1 representation>
> will give you the raw object.
>
> /<project/<hexadecimal sha1 representation>.html (.xml/.txt)
> will give you a parsed version for user presentation
Because this gives you more type control, and type control is good where
it makes sense (i.e. the types are completely orthogonal). It makes
sense here - either you _know_ your sha1 is of given type, or you don't
know at all what are you doing.
Also, when looking at an URI, you can immediately say what type of
object does it point at. I actually consider that a pretty important
property.
--
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: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Petr Baudis @ 2005-04-22 22:43 UTC (permalink / raw)
To: Rhys Hardwick; +Cc: git
In-Reply-To: <200504221624.27769.rhys@rhyshardwick.co.uk>
Dear diary, on Fri, Apr 22, 2005 at 05:24:27PM CEST, I got a letter
where Rhys Hardwick <rhys@rhyshardwick.co.uk> told me that...
> > Seems your /bin/sh do not support 'echo -e' ... Know what provides
> > your /bin/sh (I think ash at least do support it)?
> >
> > Petr, I think you should really start to consider going full bash?
>
> I use dash...
FYI, I've succumbed to the real world out there and switched the whole
thing to use bash.
--
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: [git pasky] tarball question
From: Petr Baudis @ 2005-04-22 22:42 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists
In-Reply-To: <1114180303.29271.25.camel@nosferatu.lan>
Dear diary, on Fri, Apr 22, 2005 at 04:31:43PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Hi,
Hi,
> I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
> the .git database included as well (btw, great stuff renaming it to
> something more distributable), but its going to be a pita for users of
> source based distro's like us (Gentoo), as well as our mirrors if it
> gets much bigger. (Already asked r3pek to add it to portage).
yes; that was actually the plan, it's just that my memory is so
volatile...
> How about ripping the .git directory from the next release, and just
> have a un-numbered tarball (like you used to) that have the latest
> snapshot of the .git directory for those that want to do git-pasky
> development? Should even make things easier your side, as you could
> just do a cron to update it one a day/whatever.
Does it actually make sense to keep a tarball with history? Just build
git-pasky and do git init. (Or rsync it manually.)
--
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: [3/5] Add http-pull
From: Petr Baudis @ 2005-04-22 22:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: tony.luck, Brad Roberts, git
In-Reply-To: <Pine.LNX.4.21.0504221532120.30848-100000@iabervon.org>
Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Thu, 21 Apr 2005 tony.luck@intel.com wrote:
>
> > 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).
>
> The problem with this general scheme is that it means that you have to
> start over if something goes wrong, rather than resuming from where you
> left off (and being able to use what you got until then).
Huh. Why? You just go back to history until you find a commit you
already have. If you did it the way as Tony described, if you have that
commit, you can be sure that you have everything it depends on too.
--
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] update-cache.c ignore directories
From: atani @ 2005-04-22 22:34 UTC (permalink / raw)
To: GIT Mailing List
> Am Samstag, 23. April 2005 00:25 schrieb atani:
>
> > Now it spits out:
> > -------------
> > 'plx' is a directory, ignoring
> > -------------
>
> I saw that you spit this out to stdout. Wouldn't it be better to
spit it out
> to stderr (even if its just a warning)?
Sure. I do not know of the current conventions on where the output
should go, or which methods to use for said output. Is there a
standard method for handling "warnings"? I saw there is the "die"
method but that is not what should be used here as implies a "fatal"
error.
Mike
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Petr Baudis @ 2005-04-22 22:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504221503270.2344@ppc970.osdl.org>
Dear diary, on Sat, Apr 23, 2005 at 12:14:16AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> (And I personally think that "show-diff" is really part of the "wrapper
> scripts" around git. I wrote it originally just because I needed something
> to verify the index file handling, not because it's "core" like the other
> programs. I do _not_ consider "show-diff" to be part of the core git code,
> really. Same goes for "git-export", btw - for the same reasons. It's not
> "fundamental").
Note that Cogito almost actually does not use show-diff anymore.
I'm doing diff-cache now, since that is what matters to me.
--
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: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-22 22:34 UTC (permalink / raw)
To: tony.luck, Git Mailing List
In-Reply-To: <200504222203.j3MM3fV17003@unix-os.sc.intel.com>
On Fri, 22 Apr 2005 tony.luck@intel.com wrote:
>
> "git log" seems to have problems interpreting the dates ... looking at the
> commit entries, the time is right ... but it appears that git log applies
> the timezone correction twice, so the changes I just applied at 14:46 PDT
> look like I made them at quarter to five tomorrow morning (+14 hours from
> when I did).
Looks like you are right.
The seconds are already in UTC format, so I think "git log" is wrong to
pass the UTC seconds in to "date", and then tell date that it was done in
the original timezone.
I think it would be nice to use the TZ data to show the thing in the
timezone of the committer, though. Dunno how to do that, maybe something
like
TZ=$tz date -d "1970-01-01 + $sec sec"
or whatever. Sadly, it looks like "date" doesn't understand timezone
syntax like that - looks like TZ has to be in the long machine-unreadable
format like "US/Pacific" etc. Stupid (either TZ or me - maybe I just
don't know what the right format is).
Linus
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Junio C Hamano @ 2005-04-22 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504221503270.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Fri, 22 Apr 2005, Junio C Hamano wrote:
>>
>> Almost, with a counter-example. Please try this yourself:
LT> I agree that what git outputs is always "based on the archive base". But
LT> that's an independent issue from "where is the working directory".
I am not talking about output, but the input. I do not mind
(and I rather prefer) the output is always canonical.
^ permalink raw reply
* Re: [PATCH] update-cache.c ignore directories
From: Fabian Franz @ 2005-04-22 22:27 UTC (permalink / raw)
To: atani; +Cc: GIT Mailing List
In-Reply-To: <1114208707.12699@tsunami.he.net>
Am Samstag, 23. April 2005 00:25 schrieb atani:
> Now it spits out:
> -------------
> 'plx' is a directory, ignoring
> -------------
I saw that you spit this out to stdout. Wouldn't it be better to spit it out
to stderr (even if its just a warning)?
cu
Fabian
^ 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