* Re: SVN import
From: Junio C Hamano @ 2005-10-16 7:48 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git, Kalle Valo
In-Reply-To: <878xwuldvx.fsf@litku.valo.iki.fi>
Kalle Valo <Kalle.Valo@iki.fi> writes:
> But in overall this is a really useful addition to git, I hope it will
> be merged soon.
Matthias, how ready do you feel the code is? Whenever you are
ready, please just holler.
You seem to have a small cvsimport updates in the branch. Mind
feeding it to me independently?
^ permalink raw reply
* Re: GIT 0.99.8d
From: Ed Tomlinson @ 2005-10-16 14:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vachadnmy.fsf@assigned-by-dhcp.cox.net>
Hi,
Debian users beware. This version introduces a dependency - package:
libcurl3-gnutls-dev
is now needed to build git.
Thanks
Ed Tomlinson
On Sunday 16 October 2005 01:41, Junio C Hamano wrote:
> GIT 0.99.8d is available as usual at:
>
> RPMs and tarball: www.kernel.org:/pub/software/scm/git/
> Debs and tarball: www.kernel.org:/pub/software/scm/git/debian/
>
> In addition to accumulated bugfixes, there is one important
> futureproofing changes.
>
> The "master" branch has changes to git-upload-pack (which would
> affect what git-fetch-pack/git-clone-pack see) and
> git-update-server-info (which would affect what fetch and clone
> over http:// transport see) to send extra information about the
> available references, so that the clients can find out what
> objects are referenced by remote tags before downloading them.
> They take the form of "tagname^{}". "git ls-remote $repository"
> command would show something like this:
>
> 7a3ca7d2b5ec31b2cfa594b961d77e68075e33c7 refs/heads/master
> 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11-tree
> c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11-tree^{}
> ...
> c2bbf523f1d454649897b3e4bcd71778e4fa5913 refs/tags/v2.6.14-rc2
> 676d55ae30ea3b688f0386f70553489f25f24d55 refs/tags/v2.6.14-rc2^{}
> f92737b18abac90af30ac26a050fda879c9b238b refs/tags/v2.6.14-rc3
> 1c9426e8a59461688bb451e006456987b198e4c0 refs/tags/v2.6.14-rc3^{}
>
> when the server side updates to the version in the "master"
> branch. These "^{}" entries describe the SHA1 of the object the
> tag object points at (so v2.6.11-tree tag, whose object name is
> 5dc01c... points at a tree object whose object name is
> c39ae0...).
>
> The downloading clients (git-clone and git-fetch) in the
> "master" branch have been taught to recognize these entries;
> after all, these are not real refs and you cannot give them to
> git-http-fetch to fetch from. GIT 0.99.8d clients have the same
> change, so that people staying with the maintenance branch can
> download from the server that already runs the "master" version
> and sends these fake references without getting confused.
>
> upload-pack and update-server-info in GIT 0.99.8d would not show
> these extra "fake refs" when used on the server side. In other
> words, 0.99.8d is to keep the maintenance branch working with
> newer servers.
>
> There will be GIT 0.99.8e at around the time "master" branch
> will get the updated "git-diff-*", for similar purposes. The
> updated "git-diff-*" commands deal with pathnames with funny
> characters (most importantly tabs and newlines) in a way
> compatible with the proposed change to GNU patch, which was
> outlined in:
>
> http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
>
> The change to "git-diff-*", and corresponding change to
> "git-apply" are cooking in the proposed updates branch right
> now. When people start generating diffs with them, patches that
> touch paths that have double-quotes '"' or spaces ' ' in them
> need to be applied with the updated git-apply that knows how new
> "git-diff-*" encodes these funny pathnames. GIT 0.99.8e is
> planned to backport the necessary git-apply changes, in case we
> do not bump the major release number by then.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Dirk Behme @ 2005-10-16 14:33 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510131422161.23590@g5.osdl.org>
> On Thu, 13 Oct 2005, Jeff Garzik wrote:
>
>>I have real users of my git repos who can't just download a 100MB pack file in
>>an hour, it takes them many hours.
Seems that I'm one of these users (but using an other repo).
Pack files are very nice saving bandwith and disk space. But what I
dislike is that I often have to download same information twice: Remote
.git/objects/* repo grows and I update my local repo daily against this.
Then once a month/release/whatever .git/objects/* are packed into one
file. This new pack file then is downloaded as well, but most/all of the
information in this file is already in my local repo and downloaded
again. Something like
- detect that there is new pack file in remote repo
- check what is in this remote pack file
- if in local repo no or only few .git/objects/* are missing, download
the missing ones and create an identical copy of remote pack file using
local .git/objects/*. Don't download remote pack file.
- remove all local .git/objects/* now in pack file
would be nice.
Or is this already possible? Or do I misunderstand anything?
Dirk
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Daniel Barkalow @ 2005-10-16 15:44 UTC (permalink / raw)
To: Dirk Behme; +Cc: Git Mailing List
In-Reply-To: <435264B1.2010204@de.bosch.com>
On Sun, 16 Oct 2005, Dirk Behme wrote:
> > On Thu, 13 Oct 2005, Jeff Garzik wrote:
> >
> > >I have real users of my git repos who can't just download a 100MB pack file
> > >in
> > >an hour, it takes them many hours.
>
> Seems that I'm one of these users (but using an other repo).
>
> Pack files are very nice saving bandwith and disk space. But what I dislike is
> that I often have to download same information twice: Remote .git/objects/*
> repo grows and I update my local repo daily against this. Then once a
> month/release/whatever .git/objects/* are packed into one file. This new pack
> file then is downloaded as well, but most/all of the information in this file
> is already in my local repo and downloaded again. Something like
>
> - detect that there is new pack file in remote repo
> - check what is in this remote pack file
> - if in local repo no or only few .git/objects/* are missing, download the
> missing ones and create an identical copy of remote pack file using local
> .git/objects/*. Don't download remote pack file.
This is the problem: it's impossible to download only a few objects from a
pack file from an HTTP server, because those don't exist on the server as
separate files.
The current HTTP code actually never downloads a pack file unless a needed
object is not anywhere else, at which point it has no choice but to
download the pack.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Nick Hengeveld @ 2005-10-16 16:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Dirk Behme, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0510161122570.23242@iabervon.org>
On Sun, Oct 16, 2005 at 11:44:46AM -0400, Daniel Barkalow wrote:
> This is the problem: it's impossible to download only a few objects from a
> pack file from an HTTP server, because those don't exist on the server as
> separate files.
Is it possible to determine the object locations inside the remote pack
file? If so, it would be possible to use Range: headers to download
selected objects from a pack.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Brian Gerst @ 2005-10-16 16:23 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Daniel Barkalow, Dirk Behme, Git Mailing List
In-Reply-To: <20051016161244.GE5509@reactrix.com>
Nick Hengeveld wrote:
> On Sun, Oct 16, 2005 at 11:44:46AM -0400, Daniel Barkalow wrote:
>
>> This is the problem: it's impossible to download only a few objects from a
>> pack file from an HTTP server, because those don't exist on the server as
>> separate files.
>
> Is it possible to determine the object locations inside the remote pack
> file? If so, it would be possible to use Range: headers to download
> selected objects from a pack.
>
Not possible because the entire pack is compressed.
--
Brian Gerst
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-10-16 16:56 UTC (permalink / raw)
To: git
In-Reply-To: <43527E86.8000907@didntduck.org>
Brian Gerst <bgerst@didntduck.org> writes:
>> Is it possible to determine the object locations inside the remote
>> pack
>> file? If so, it would be possible to use Range: headers to download
>> selected objects from a pack.
That's what the .idx file is for, except that after you fetch
the range, you may find you would need something else that the
object is delta against.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Johannes Schindelin @ 2005-10-16 17:10 UTC (permalink / raw)
To: Brian Gerst; +Cc: Nick Hengeveld, Daniel Barkalow, Dirk Behme, Git Mailing List
In-Reply-To: <43527E86.8000907@didntduck.org>
Hi,
On Sun, 16 Oct 2005, Brian Gerst wrote:
> Nick Hengeveld wrote:
> > On Sun, Oct 16, 2005 at 11:44:46AM -0400, Daniel Barkalow wrote:
> >
> > > This is the problem: it's impossible to download only a few objects from a
> > > pack file from an HTTP server, because those don't exist on the server as
> > > separate files.
> >
> > Is it possible to determine the object locations inside the remote pack
> > file? If so, it would be possible to use Range: headers to download
> > selected objects from a pack.
> >
>
> Not possible because the entire pack is compressed.
Maybe we should introduce an option which only packs objects of a minimal
age (something like "pack only objects 2 days and older")? This could be
used to autopackage as long as HTTP is the preferred protocol, so that if
you update daily, you already have those objects.
Alternatively, git-prune-packed could have an option to prune only those
objects older than 2 days.
Ciao,
Dscho
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Brian Gerst @ 2005-10-16 17:15 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Daniel Barkalow, Dirk Behme, Git Mailing List
In-Reply-To: <43527E86.8000907@didntduck.org>
Brian Gerst wrote:
> Nick Hengeveld wrote:
>
>> On Sun, Oct 16, 2005 at 11:44:46AM -0400, Daniel Barkalow wrote:
>>
>>> This is the problem: it's impossible to download only a few objects
>>> from a pack file from an HTTP server, because those don't exist on
>>> the server as separate files.
>>
>>
>> Is it possible to determine the object locations inside the remote pack
>> file? If so, it would be possible to use Range: headers to download
>> selected objects from a pack.
>>
>
> Not possible because the entire pack is compressed.
I should have looked at the source more closely before stating that.
Each object gets compressed individually, so this would be possible.
--
Brian Gerst
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-16 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kalle Valo
In-Reply-To: <7vy84tdhqv.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hi,
Junio C Hamano:
> Matthias, how ready do you feel the code is? Whenever you are
> ready, please just holler.
>
Hollering now.
There's one small omission, which is that the merge RX for SVN should
optionally recognize the SVN commit number it's merging from and use
the corresponsing git commit as the merge parent, but maybe somebody
else feels motivated to add that (hint, hint) .
> You seem to have a small cvsimport updates in the branch. Mind
> feeding it to me independently?
>
Why? It already is a separate commit (89764f5d..., the one before
I added the svn script).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The Public is merely a multiplied "me."
-- Mark Twain
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-16 17:58 UTC (permalink / raw)
To: Kalle Valo; +Cc: git
In-Reply-To: <878xwuldvx.fsf@litku.valo.iki.fi>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
Hi,
> Maybe something like this would be more informative:
>
Thanks; reworded.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Never put off till run-time what you can do at compile-time.
-- D. Gries
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SVN import
From: Junio C Hamano @ 2005-10-16 18:09 UTC (permalink / raw)
To: git
In-Reply-To: <20051016174210.GA8297@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> Why? It already is a separate commit (89764f5d..., the one before
> I added the svn script).
That was a "just in case you need a bit more time for the full
merge of your SVN work" question. Pulling the whole thing now.
^ permalink raw reply
* Re: GIT 0.99.8d
From: Junio C Hamano @ 2005-10-16 18:22 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: git, linux-kernel
In-Reply-To: <200510161024.37873.tomlins@cam.org>
Ed Tomlinson <tomlins@cam.org> writes:
(Obligatory "do not top post" request omitted)
> Debian users beware. This version introduces a dependency - package:
> libcurl3-gnutls-dev
> is now needed to build git.
Is this really true? The one I uploaded was built on this
machine:
: siamese; dpkg -l libcurl\* | sed -ne 's/^ii //p'
libcurl3 7.14.0-2 Multi-protocol file transfer library, now wi
libcurl3-dev 7.14.0-2 Development files and documentation for libc
Having said that, a tested patch to debian/control to adjust
Build-Depends is much appreciated.
^ permalink raw reply
* Do you use "git-apply --show-files"?
From: Junio C Hamano @ 2005-10-16 18:41 UTC (permalink / raw)
To: torvalds; +Cc: git
As a part of "funny pathname character" updates, I was reviewing
"apply.c" and have two questions on its "--show-files" flag.
* Unlike other informational flags like --stat and --summary,
it does not turn off "apply". Is it intentional?
* Do you (or anybody else) use it, and if so how?
The current code in the proposed updates branch decodes the same
C-style encoded pathnames GNU patch with proposed enhancements
would understand before applying patches, and when it needs to
show pathnames with --index-info, --stat, and --summary, it uses
the same encoded pathname to keep things on one line.
I think --show-files should also do the same for consistency,
but before I update it I wanted to ask the above questions. If
nobody uses it, I can just ignore the issues and probably
remove the flag.
The plan is to backport the git-apply change to the maint branch
to do a 0.99.8e before updated git-diff-* hits the master
branch. The only thing that would make a difference is embedded
SP. Currently they are not quoted, but they will be, like this:
: siamese; git diff
diff --git "a/Read Me" "b/Read Me"
index 3deac99..543a8f0 100644
--- "a/Read Me"
+++ "b/Read Me"
...
^ permalink raw reply
* Re: GIT 0.99.8d
From: Marco Roeland @ 2005-10-16 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ed Tomlinson, git, linux-kernel
In-Reply-To: <7vll0txqwu.fsf@assigned-by-dhcp.cox.net>
On Sunday October 16th 2005 Junio C Hamano wrote:
> > Debian users beware. This version introduces a dependency - package:
> > libcurl3-gnutls-dev
> > is now needed to build git.
>
> Is this really true? The one I uploaded was built on this
> machine:
>
> : siamese; dpkg -l libcurl\* | sed -ne 's/^ii //p'
> libcurl3 7.14.0-2 Multi-protocol file transfer library, now wi
> libcurl3-dev 7.14.0-2 Development files and documentation for libc
>
> Having said that, a tested patch to debian/control to adjust
> Build-Depends is much appreciated.
The present line is correct. In 'debian/control' the line reads
(word-wrapped here):
Build-Depends-Indep: libz-dev, libssl-dev,
libcurl3-dev|libcurl3-gnutls-dev|libcurl3-openssl-dev, asciidoc (>=
6.0.3), xmlto, debhelper (>= 4.0.0), bc
So it works correct on 'stable' versions ('libcurl3-dev') and
latest 'unstable' as well, where you have the choice of either
'libcurl3-gnutls-dev' or 'libcurl3-openssl-dev'.
--
Marco Roeland
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Nick Hengeveld @ 2005-10-16 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmp9xuwe.fsf@assigned-by-dhcp.cox.net>
On Sun, Oct 16, 2005 at 09:56:49AM -0700, Junio C Hamano wrote:
> That's what the .idx file is for, except that after you fetch
> the range, you may find you would need something else that the
> object is delta against.
Would it make sense to load the pack indexes for each base up front,
and then fetch individual objects from a pack if they exist in one of
a base's pack indexes? In such a case, it may not even make sense to
try fetching the object directly first.
What are the circumstances under which it makes more sense to fetch the
whole pack rather than fetching individual objects from it?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Some curl versions lack curl_easy_duphandle()
From: Nick Hengeveld @ 2005-10-16 21:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510151348080.12307@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, Oct 15, 2005 at 01:50:16PM +0200, Johannes Schindelin wrote:
> +#if LIBCURL_VERSION_NUM < 0x070c04
> +#define NO_CURL_EASY_DUPHANDLE
> +#endif
Is that the correct version number? I've been using 7.10.6 and
curl_easy_duphandle() has been working fine.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Some curl versions lack curl_easy_duphandle()
From: Johannes Schindelin @ 2005-10-16 21:58 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051016215018.GG5509@reactrix.com>
Hi,
On Sun, 16 Oct 2005, Nick Hengeveld wrote:
> On Sat, Oct 15, 2005 at 01:50:16PM +0200, Johannes Schindelin wrote:
>
> > +#if LIBCURL_VERSION_NUM < 0x070c04
> > +#define NO_CURL_EASY_DUPHANDLE
> > +#endif
>
> Is that the correct version number? I've been using 7.10.6 and
> curl_easy_duphandle() has been working fine.
I looked into CVS to find when curl_easy_duphandle() was introduced, and
it was Nov 9, 2004. So I looked for the corresponding curl.h and found it
says 0x070c04. I will look again...
Ciao,
Dscho
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-10-16 22:12 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051016213341.GF5509@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> On Sun, Oct 16, 2005 at 09:56:49AM -0700, Junio C Hamano wrote:
>
>> That's what the .idx file is for, except that after you fetch
>> the range, you may find you would need something else that the
>> object is delta against.
>
> Would it make sense to load the pack indexes for each base up front,
> and then fetch individual objects from a pack if they exist in one of
> a base's pack indexes? In such a case, it may not even make sense to
> try fetching the object directly first.
>
> What are the circumstances under which it makes more sense to fetch the
> whole pack rather than fetching individual objects from it?
It would make sense if we end up needing most them anyway, I
think.
We are probably far from this, but ideally, we should be able to
set up something like this.
We encourage the server side to prepare packs this way [*1*].
-- development --> time --> flows --> this --> way -->
(optional)
full ------------------------------------------------
base ---------------
6mo ---------------------------------
3mo -------------------
1mo --------------
2wk ----------
1wk -----
^
last pack optimization
That is, a big base pack (say v2.6.12), and multiple packs to
bring people that were in-sync at various time up-to-date to the
time when the set of packs were last optimized. Any objects
created after the last pack optimization time are left unpacked
until the next pack optimization time. It might not be a bad
idea to also have a "full" pack.
For example, if you were in-sync 5-months ago, fetching 3mo pack
would not be enough and you would need to get 6mo pack to become
up-to-date wrt the last pack optimization (say 3 days ago). You
would have obtained the objects not in pack, created within the
last 3 days, already as individual objects before realizing that
you would need to fetch some pack.
Then, we can teach git-http-fetch to do:
- If an object is unavailable unpacked, get all the indices
from that repository (and probably its alternates while we
are at it).
- Among the set of packs that contain the object we are
currently interested in, try to find the "best" pack. The
definition of "best" would be a balancing act of finding the
one that contains the least number of objects we already
have, and the one that contains the most number of objects we
do not have yet.
The commit walker always goes from present to past, so you would
start from fetching the latest, presumably unpacked objects, and
as soon as you hit the last pack optimization boundary, you have
choices of multiple packs. If you are relatively up-to-date,
you would find that 1mo pack has more things you already have
than 1wk pack, although both of them would fit the bill -- at
that point you choose to download 1wk pack. On the other hand,
if you are behind, you may find that 3mo pack has more things
you do not have than 1wk or 2wk or 1mo pack, and using 3mo pack
would become the right choice for you.
I think most repositories have a few related heads and their
heads almost never rewind, so favoring the pack that contains
the most number of objects we do not have would be the right
strategy in practice for the downloader.
[Footnote]
*1* This is different from a proposal posted on the list earlier
by somebody (I think it was Pasky but I may be mistaken) which
looked like this:
-- development --> time --> flows --> this --> way -->
base ---------------
6mo --------------
3mo -----
1mo ----
2wk -----
1wk -----
The thing is, sum of 3mo+1mo+2wk+1wk packs in the latter scheme
tends to be a lot bigger than the size of 3mo pack in the former
scheme.
^ permalink raw reply
* Re: GIT 0.99.8d
From: Ed Tomlinson @ 2005-10-16 22:15 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <20051016185540.GA27162@fiberbit.xs4all.nl>
Hi,
This explains things. I am not building via the debian package. What happened is that
sid (amd64) dropped libcurl3-dev and I did not add one of the other packages...
Thanks
Ed
On Sunday 16 October 2005 14:55, Marco Roeland wrote:
> On Sunday October 16th 2005 Junio C Hamano wrote:
>
> > > Debian users beware. This version introduces a dependency - package:
> > > libcurl3-gnutls-dev
> > > is now needed to build git.
> >
> > Is this really true? The one I uploaded was built on this
> > machine:
> >
> > : siamese; dpkg -l libcurl\* | sed -ne 's/^ii //p'
> > libcurl3 7.14.0-2 Multi-protocol file transfer library, now wi
> > libcurl3-dev 7.14.0-2 Development files and documentation for libc
> >
> > Having said that, a tested patch to debian/control to adjust
> > Build-Depends is much appreciated.
>
> The present line is correct. In 'debian/control' the line reads
> (word-wrapped here):
>
> Build-Depends-Indep: libz-dev, libssl-dev,
> libcurl3-dev|libcurl3-gnutls-dev|libcurl3-openssl-dev, asciidoc (>=
> 6.0.3), xmlto, debhelper (>= 4.0.0), bc
>
> So it works correct on 'stable' versions ('libcurl3-dev') and
> latest 'unstable' as well, where you have the choice of either
> 'libcurl3-gnutls-dev' or 'libcurl3-openssl-dev'.
^ permalink raw reply
* Re: Do you use "git-apply --show-files"?
From: Linus Torvalds @ 2005-10-17 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek6lxq1d.fsf@assigned-by-dhcp.cox.net>
On Sun, 16 Oct 2005, Junio C Hamano wrote:
>
> As a part of "funny pathname character" updates, I was reviewing
> "apply.c" and have two questions on its "--show-files" flag.
>
> * Unlike other informational flags like --stat and --summary,
> it does not turn off "apply". Is it intentional?
>
> * Do you (or anybody else) use it, and if so how?
As far as I'm concerned, you can remove it.
The point of show-files was to have the index update be based on the files
that were updated, it I was originally not planning to updating the index
directly in git-apply, but instead do something like
files=$(git-apply --show-files)
git-update-cache --add --delete -- $files
but it turned out to be a lot easier to just update the index.
So just remove that flag, I doubt it has ever been used.
Linus
^ permalink raw reply
* LCA2006 Git/Cogito tutorial
From: Martin Langhoff (CatalystIT) @ 2005-10-17 0:48 UTC (permalink / raw)
To: git
Good news! Sounds like I will be hosting a Git/Cogito tutorial in the
upcoming LCA2006 (Dunedin, NZ, Jan 25~28). Given that I do have some
significant holes in my git knowledge (no, really!?) I'll be happy if
other git hackers/users are present at LCA and willing to take part in
the tutorial.
Petr Baudis hinted earlier that he might be coming, as did Linus (but
he was hoping for a sponsor, I'm not sure whether he'll be there or
not). Speak up if you'll be there!
I'll post my slides and presentation plan beforehand to the list, to
avoid spreading misinfirmation/bad practices. They will probably be
based on a recent talk I gave @ Wellington Perl Mongers about
swtiching to Git/Cogito:
http://wellington.pm.org/archive/200510/git/
The feedback (from both non-cogito-users and actual cogito-users) was
that I made it sound too complicated, so the current plan is to focus
on the tutorial part, and leave "under the hood" parts for a rainy day
or for an after tutorial in-the-corridor chat.
cheers,
martin
ps: lately, about 30% of my emails to git@vger from gmail have been
dropped on the floor. This is starting to get annoying, is anyone seeing
similar issues?
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: GIT 0.99.8d
From: David Lang @ 2005-10-17 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ed Tomlinson, git, linux-kernel
In-Reply-To: <7vll0txqwu.fsf@assigned-by-dhcp.cox.net>
when I recently installed git 0.99.8c on my gentoo system it died during
the install without curl installed, but worked once curl was installed. (I
haven't gotten around to reporting th packaging bug to gentoo yet)
David Lang
On Sun,
16 Oct 2005, Junio C Hamano wrote:
> Date: Sun, 16 Oct 2005 11:22:57 -0700
> From: Junio C Hamano <junkio@cox.net>
> To: Ed Tomlinson <tomlins@cam.org>
> Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: GIT 0.99.8d
>
> Ed Tomlinson <tomlins@cam.org> writes:
>
> (Obligatory "do not top post" request omitted)
>
>> Debian users beware. This version introduces a dependency - package:
>> libcurl3-gnutls-dev
>> is now needed to build git.
>
> Is this really true? The one I uploaded was built on this
> machine:
>
> : siamese; dpkg -l libcurl\* | sed -ne 's/^ii //p'
> libcurl3 7.14.0-2 Multi-protocol file transfer library, now wi
> libcurl3-dev 7.14.0-2 Development files and documentation for libc
>
> Having said that, a tested patch to debian/control to adjust
> Build-Depends is much appreciated.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Nick Hengeveld @ 2005-10-17 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtkd6rik.fsf@assigned-by-dhcp.cox.net>
On Sun, Oct 16, 2005 at 03:12:03PM -0700, Junio C Hamano wrote:
> - Among the set of packs that contain the object we are
> currently interested in, try to find the "best" pack. The
> definition of "best" would be a balancing act of finding the
> one that contains the least number of objects we already
> have, and the one that contains the most number of objects we
> do not have yet.
To get a complete list of objects we do not have yet, fetch will need
to walk all the trees first and then make another pass to process
all the missing objects. Is it worth considering a case where the
missing objects are packed along with objects that don't need to be
transferred? From the use cases you described, it's not clear that
situation would ever really happen.
If the blobs have been packed, it seems likely that the tree objects will
also be packed, so fetching them during the first pass will either involve
fetching a pack without being able to determine which is best or fetching
the appropriate ranges from packs to get the tree objects.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-10-17 8:21 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051017060659.GH5509@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> To get a complete list of objects we do not have yet, fetch will need
> to walk all the trees first and then make another pass to process
> all the missing objects.
Notice I did not say "we do not have yet but we will need" -- I
just said "we do not have yet".
The assumption, which is the property the suggested packing
strategy has, is that older objects that are needed to complete
the history leading to the current tip are packed in those
n-month/n-week packs, so if we do not have them we would likely
be needing them, although we might not have walked that far back
in history yet.
The previous "packing strategy" picture was certainly too
simplified. Obviously we would not want to repack everything
every week for different periods all the way back -- we would
want to leave old huge pack untouched to help server side (and
mirroring), so instead of having a single "pack optimization
boundary", we would probably need some staggering as well for
archived material.
This is a revised example.
1yr -----
9mo --------
6mo ----------
3mo ------------------
1mo ------------
2wk --------
1wk ----
We keep track of "the current heads and tags" for each week.
Every week, we can do something like this:
- rotate the record, and create a new one:
mv .save/wk11 .save/wk12
mv .save/wk10 .save/wk11
mv .save/wk9 .save/wk10
...
mv .save/wk0 .save/wk1
find .git/refs -type f -print | xargs cat >.save/wk0
- prepare a pack to allow a single pack fetch to bring a
repository that had everything reachable from wk$N refs
up-to-date to the current, for selected recent weeks (say N=1,
2, 4, 12):
for N in 1 2 4 12
do
name=$(git-rev-list --objects \
$(sed -e 's/^/^/' .save/wk$N) \
$(cat .save/wk0) |
git-pack-object pack-) &&
mv pack-$name.* .git/objects/pack/.
done
remove the pack files that we created this way last week from
the repository (if the repository did not have any activity
during the last week we would have created the same set of
packs. make sure we do not remove them).
- except that, we keep the longest period (i.e. N=12 in this
example) one every N weeks (that's how 1yr, 9mo, 6mo packs in
the picture are kept).
This way, really old stuff (say, older than 3mo) will stay
intact and will not be repacked, so people reasonably up-to-date
(within 12 weeks in the example) need to fetch only one pack
(and unpacked objects since the last pack optimization), but
people without the ancient history need to go further back.
^ 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