* 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: cygwin: t3200-branch.sh fails with "List form of pipe open not implemented at -e line 22."
From: Junio C Hamano @ 2005-10-16 7:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051015211808.GA3497@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
>> >The message comes from one of the hooks, which are executed even
>> >though they never meant to, because cygwin apparently uses file
>> >content or name to detect executability (on FAT).
Is this one of the hooks we ship as examples? If so, that
means worse brokenness than just test failing. It means that
the hook is not usable in your environment.
I presume it is this line in pre-commit sample hook:
open $fh, "-|", qw(git-diff-index -p -M --cached HEAD);
Is Perl on Cygwin incapable of handle this in general, or is it
just what is on your machine being behind?
In the meantime, I've changed two things:
- Earlier, tests run in a trash/ repository that was
initialized with user's random templates. This was *wrong*.
It now uses freshly built templates that came from the
source.
- Further, hooks are disabled in the trash/ repository used for
tests. When we later add tests for hooks (HINTS, anybody
;-)), they can add their own anyway.
^ permalink raw reply
* GIT 0.99.8d
From: Junio C Hamano @ 2005-10-16 5:41 UTC (permalink / raw)
To: git; +Cc: linux-kernel
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.
^ permalink raw reply
* Re: What's in git.git repository
From: Junio C Hamano @ 2005-10-16 2:20 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90510151734k141f218crc2ccfbb78769e518@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> One thought I had this morning is that given that the
> tree->commit->tagobj relation is unique and stable, it'd be a valid
> strategy to have files in .git/refs/tags/ optionally contain the 3
> identifiers. It is plainly safe to cache this permamently, the only
> pain now is to deal with teaching all the porcelains about it.
>
> What do you think?
Many ref readers read just the first 40 bytes and ignore the
rest, so storing "tag-SHA1 followed by optional information"
there would not hurt them that much. But the question now is
what optional information to place there?
Obviously, we could do:
echo '5dc01c59... tree=c39ae07f...' >.git/refs/tags/v2.6.11
echo '26791a8b... commit=9ee1c9... tree=e4660ac...' >.git/refs/tags/v2.6.12
echo '0918385d... blob=b92c9c0...' >.git/refs/tags/junio-gpg-pub
But, then we could also do:
(
echo '5dc01c59...'
git-cat-file tag v2.6.11
) >.git/refs/tags/v2.6.11
There is no need to read 'tag' object separately -- it is all
there. The same thing can be said for a tag that refers to
another tag that refers to a commit that contains a tree. So
the question becomes "where to stop?".
I suspect the answer to that question is "it depends". And I
also suspect "sed -e '...' <.git/refs/tags/v2.6.11" after we add
minimum optional information (not tag text but only commit and
perhaps tree object name) to these files would not be that much
cheaper than doing "git-cat-file commit v2.6.11 | sed -e '...'".
In other words, my gut feeling tells me that it would not buy us
that much.
I've also thought about showing v2.6.12^{tree} in addition to
v2.6.12^{} from ls-remote, and showing v2.6.12^{commit} instead
of v2.6.12^{}, to make the type of what it dereferences to more
explicit. I did not do things that way because I was not quite
sure how much the additional complexity and additional output
from ls-remote would buy us.
^ permalink raw reply
* cg-fetch auto-following tags
From: Junio C Hamano @ 2005-10-16 0:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In cg-fetch, you have some code at the bottom starting with:
$get -i -s -u -d "$uri/refs/tags" "$_git/refs/tags" || rsyncerr=1
Under http, I presume get is get_http which is recursive wget to
slurp all tags to .git/refs/tags?
Earlier you were talking about fetching tags automatically as
the user follows a branch (or multiple branches) development,
but the current git-http-fetch's semantics of making sure the
repository has all the reachable objects when slurping from a
ref makes it impossible, and you are playing things safer by
essentially cloning the remote repository.
The latest "master" branch of git-core sends unwrapped tag
information to make this easier to implement. I think you
should be able to do something like this (between "FIXME: Warn
about conflicting tag names?" and "rm fetch-$name-dirty").
git-ls-remote --tags $uri/ |
# SHA1 refs/tags/v0.99.8^{} --> SHA1 tags/v0.99.8
# where SHA1 is the object v0.99.8 tag points at.
sed -ne 's:\([^ ]\) refs/\(tags/.*\)^{}$:\1 \2:p' |
while read sha1 tagname
do
# do we have the object pointed at by the tag?
git-cat-file -t "$sha1" >/dev/null 2>&1 ||
continue
# if so, fetch the tag -- which should be a
# cheap operation -- to complete the chain.
$fetch "$tagname" "$uri" "$tagname"
done
This sample code assumes your $fetch implements the same
semantics for various transports ($1 is the ref to fetch, $2 is
the repo url, $3 is the local ref to write into); I only checked
http transport in your code.
^ permalink raw reply
* Re: What's in git.git repository
From: Junio C Hamano @ 2005-10-15 23:48 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90510142340r2fe24ce6j5d0d96535fbb2517@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
>> I'd have this graduate to the "master" branch after some more
>> testing, only if people are interested in it; otherwise I'm
>> thinking about dropping this (I am not particularly interested
>> in this enhancement myself).
>
> Fair enough -- it simplifies (and speeds up) the git-findtags script I
> posted. Actually, it makes it redundant. But if it's not
> elegant/needed/wanted in the C core, git-findtags can deal with it in
> the soft and sloppy sphere of perl scripts.
> Most people don't need this at all, and I guess that's why we managed
> so long without it. But I think it's a basic plumbing service.
Oh, I did not mean that I did not *like* the implementation or
feature. I just was unsure if that was what you and Pasky would
find useful.
I was trying to add something that would be useful in general,
but if what I did was missing the mark and wasn't something you
two found useful, there was no need to add it.
So, thanks for the feedback and background rationale. Let's
have it in "master" then.
^ permalink raw reply
* Re: getting rid of extra directories
From: Junio C Hamano @ 2005-10-15 22:34 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20051015192720.GA11364@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
>> I do not know exactly what Cogito "seek back and forth" does,
>
> It means to "cg-seek" back to an earlier state of the repo, and forward to a
> more recent state of the repo. "seeking back and forth" means doing a lot of
> "cg-seek" commands. Sorry that wasn't clear.
>
>> but updating to git-core "master" branch may help.
>
> I already use that branch.
I usually do not use Cogito, so I updated to the latest and
tried it myself. No wonder.
cg-seek does not use "git-read-tree -m -u $old $new", which was
updated by that commit I mentioned to remove the empty
directories. It does "git-read-tree -m $new" and does the
removal part manually by reading from diff-tree $old $new. I
suspect the code was there before the two-tree read-tree was
invented.
A similar sequence as you did, in pure git, would remove empty
directory d/ when switching branches between.
$ mkdir junkproj
$ cd junkproj
$ git-init-db
$ ls >a
$ git-add a
$ git-commit -a -m 'Add a'
$ git-checkout -b adddir
$ mkdir d
$ mv a d/a
$ git-add d
$ git-commit -a -m 'Move a to d/a'
$ git-checkout master
I suspect cg-Xlib::tree_timewarp, which currently does
"git-read-tree -m $branch" followed by diff-tree piped to xargs,
can be taught to use "git-read-tree -m -u $base $branch" (and
lose the git-checkout-index -f -a immediately after that while
we are at it), but I do not do Porcelain, so...
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Randal L. Schwartz @ 2005-10-15 22:04 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20051015215754.GD5509@reactrix.com>
>>>>> "Nick" == Nick Hengeveld <nickh@reactrix.com> writes:
Nick> On Sat, Oct 15, 2005 at 06:03:00AM -0700, Randal L. Schwartz wrote:
>> OK, it happened this morning. While syncing to update from
>> yesterday's version, I got:
>> ...
>> Definitely broken. But I can "rsync" just fine.
Nick> Which version of curl did you build with?
curl 7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7g zlib/1.2.3
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Nick Hengeveld @ 2005-10-15 21:57 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <863bn3lypn.fsf@blue.stonehenge.com>
On Sat, Oct 15, 2005 at 06:03:00AM -0700, Randal L. Schwartz wrote:
> OK, it happened this morning. While syncing to update from
> yesterday's version, I got:
> ...
> Definitely broken. But I can "rsync" just fine.
Which version of curl did you build with?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Nick Hengeveld @ 2005-10-15 21:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0510151502290.23242@iabervon.org>
On Sat, Oct 15, 2005 at 03:41:35PM -0400, Daniel Barkalow wrote:
> > BTW, I do not think this is related to git.git repository
> > problem, but I wonder why we do not do fetch_object() against
> > each altbase in http-fetch.c::fetch(); nobody said you cannot
> > borrow unpacked object from your neighbour.
>
> I believe the code is doing that, but elsewhere.
Er, never mind what I said in my previous message. Daniel is correct,
process_curl_messages() will try the next altbase if a request 404s.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Nick Hengeveld @ 2005-10-15 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git, Daniel Barkalow
In-Reply-To: <7v1x2mpx6m.fsf@assigned-by-dhcp.cox.net>
On Sat, Oct 15, 2005 at 09:22:25AM -0700, Junio C Hamano wrote:
> More interesting is this "error:" without error message.
> "Getting pack list" is a signal that we fell back to
> fetch_pack(), so this is coming from fetch_object().
I've seen that happen before fetch_pack used the active queue; open object
requests in the active queue would not be processed while fetch_pack was
transferring the pack, and in some cases a server had timed out a connection
from one of these requests by the time the active queue started processing
again. I worked around this at one point by detecting an empty server
response and retrying the request.
Changing all requests to run through the active queue seemed to fix the
problem, but it's possible that something is still holding up processing
long enough to cause a server timeout.
> BTW, I do not think this is related to git.git repository
> problem, but I wonder why we do not do fetch_object() against
> each altbase in http-fetch.c::fetch(); nobody said you cannot
> borrow unpacked object from your neighbour.
It doesn't look like there are any alternates defined in the git.git
repository. I've seen alternates used during testing when I deliberately
removed objects and packs from the primary repository.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: cygwin: t3200-branch.sh fails with "List form of pipe open not implemented at -e line 22."
From: Alex Riesen @ 2005-10-15 21:18 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <434FF189.3080806@zytor.com>
H. Peter Anvin, Fri, Oct 14, 2005 19:57:29 +0200:
> >Now, how broken is that:
> >
> >The message comes from one of the hooks, which are executed even
> >though they never meant to, because cygwin apparently uses file
> >content or name to detect executability (on FAT).
> >
> >I just remove the hooks from repositories atm.
>
> I think the bottom line is "don't use FAT".
>
I'm afraid I have to. NTFS isn't much better (newly created files
still have no correct attribute) and is slower (sometimes much
slower). Not that I have a choice, anyway: it's a typical corporate
workstation locked as down as possible.
^ permalink raw reply
* svnimport: fixed Makefile entry
From: Kalle Valo @ 2005-10-15 20:44 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <878xwuldvx.fsf@litku.valo.iki.fi>
Makefile entry for git-svnimport contained a small typo.
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: b5467f815f8de270a755099df924bff5ed98512e
bce2921cf6fe774ba4f8edffe35ef914c2a836e6
diff --git a/Makefile b/Makefile
index 8f2dfb2..1cca928 100644
--- a/Makefile
+++ b/Makefile
@@ -94,7 +94,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \
- git-findtags.perl git-svnimport-perl
+ git-findtags.perl git-svnimport.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
---
0.99.8.GIT
^ permalink raw reply related
* Re: SVN import
From: Kalle Valo @ 2005-10-15 20:32 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.10.09.45.00.468989@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
>> Quick note: I'm working on importing from SVN.
>
> The first version seems to be finished.
>
> http:/netz/smurf.noris.de/git/git.git, branch "svn".
>
> Should be ready for merging, though I wouldn't say no to a few testers
> before that happens. ;-)
After fixing a conflict and a typo in Makefile (patch coming soon) I
tested this with the bcm43xx driver from
svn://svn.berlios.de/bcm43xx/trunk. It seems to work fine.
Only a minor problem was that I immediately didn't realize the 100
commit limit was intentional. Maybe the error message could improved a
bit. Now it says:
Exiting due to a memory leak. Repeat, please.
Maybe something like this would be more informative:
Subversion commit limit reached (to avoid SVN library memory
leaks). Exiting, but please repeat the command and it will
continue safely.
But in overall this is a really useful addition to git, I hope it will
be merged soon.
--
Kalle Valo
^ permalink raw reply
* Re: gitweb
From: Nico -telmich- Schottelius @ 2005-10-15 19:37 UTC (permalink / raw)
To: git
In-Reply-To: <20051015193146.GK12774@schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
Nico -telmich- Schottelius [Sat, Oct 15, 2005 at 09:31:46PM +0200]:
> 1. problems getting gitweb
>
> [21:26] creme:build% cg-clone http://www.kernel.org/pub/scm/git/gitweb.cgi
oops, my fault: s/cgi/git/
3. Problem with "+" in filenames still exists:
http://linux.schottelius.org/cgi-bin/gitweb.cgi?p=cLinux/cinit.git;a=tree;h=45484bc0aa87c816bfe18e5eea3cddba1bddf966;hb=2c2ae29df1471b6542476fb720da5b55dc149718;f=contrib+tools
4. another error happens:
----------------------------------------------------------------------
[...]
walk d8d17b5debd37a3f0e42eba2d69d375b74f20fe9
progress: 55 objects, 248306 bytes
walk f7ab660c15b5e3cb7fee035191e0cd5160bf8299
progress: 58 objects, 262710 bytes
walk e4669df9a6f638299ebab57cc87318a2a9e24b0c
progress: 61 objects, 276940 bytes
walk f5dfb3f6a6655d4d60fdd0aaeef7b5b14226147f
progress: 63 objects, 290809 bytes
error: The requested URL returned error: 404
Getting pack list
error: The requested URL returned error: 404
Getting alternates list
error: Unable to find d263a6bd453df849c9f9211f1966c830c3cf913a under http://www.kernel.org/pub/scm/git/gitweb.git/
Cannot obtain needed commit d263a6bd453df849c9f9211f1966c830c3cf913a
while processing commit f5dfb3f6a6655d4d60fdd0aaeef7b5b14226147f.
cg-fetch: objects fetch failed
cg-clone: fetch failed
----------------------------------------------------------------------
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Daniel Barkalow @ 2005-10-15 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nick Hengeveld, Randal L. Schwartz, git
In-Reply-To: <7v1x2mpx6m.fsf@assigned-by-dhcp.cox.net>
On Sat, 15 Oct 2005, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > merlyn@stonehenge.com (Randal L. Schwartz) writes:
> >
> >> OK, it happened this morning. While syncing to update from
> >> yesterday's version, I got:
> >
> > Thanks.
> >
> >> localhost:~/MIRROR/git-GIT % git-pull
> >> Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
> >> Getting alternates list
> >> got 4546738b58a0134eef154231b07d60fc174d56e3
> >> walk 4546738b58a0134eef154231b07d60fc174d56e3
> >> got d402d5566fdf226697a386dfb9858e5d954e9b91
> >> got 873d8e5652c06c3891278f33546c437efc209c2d
> >> walk d402d5566fdf226697a386dfb9858e5d954e9b91
> >> error:
> >> Getting pack list
> >> got 0207ab18a3876249a928e7539d8f594a4f6921f1
>
> More interesting is this "error:" without error message.
> "Getting pack list" is a signal that we fell back to
> fetch_pack(), so this is coming from fetch_object().
>
> I see this line could emit an empty error message, if errorstr
> is empty.
>
> if (request->curl_result != CURLE_OK && request->http_code != 416) {
> ret = error("%s", request->errorstr);
> release_request(request);
> return ret;
> }
>
> So if that is the case maybe my previous speculation that we
> sometimes forget to issue a necessary request was wrong. We
> asked for that object and got an error from cURL library...
It looks like we didn't get an error from the cURL library, actually, or
it would have printed something. My guess is that it is getting to the
point about while the request is still in progress, but I'm not seeing how
that could happen.
> BTW, I do not think this is related to git.git repository
> problem, but I wonder why we do not do fetch_object() against
> each altbase in http-fetch.c::fetch(); nobody said you cannot
> borrow unpacked object from your neighbour.
I believe the code is doing that, but elsewhere.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* gitweb
From: Nico -telmich- Schottelius @ 2005-10-15 19:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
1. problems getting gitweb
[21:26] creme:build% cg-clone http://www.kernel.org/pub/scm/git/gitweb.cgi
defaulting to local storage area
http://www.kernel.org/pub/scm/git/gitweb.cgi/HEAD:
21:27:01 FEHLER 404: Not Found.
cg-fetch: unable to get the HEAD branch
cg-clone: fetch failed
2. mysterious commit
http://www.kernel.org/git/?p=git/gitweb.git;a=commitdiff;h=0c3eb45fa414326564cb1a9692c7a22319939fc0;hp=d8f1c5c2f37433ef9ce56847d81314ea2798ac3c
Not many changes for a new release imho ;-)
[well, perhaps the release change was for the head<->branches change before]
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: getting rid of extra directories
From: Zack Brown @ 2005-10-15 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0fimzhn.fsf@assigned-by-dhcp.cox.net>
On Sat, Oct 15, 2005 at 11:00:52AM -0700, Junio C Hamano wrote:
> Zack Brown <zbrown@tumblerings.org> writes:
>
> > I've been using the latest Cogito. When I seek back and forth in a git repo,
> > directories I've created tend to persist backward in time, cluttering up
> > earlier versions.
> >
> > By the discussions on this list, I'm pretty sure there's a way to stop this,
> > but I don't know clearly what it is, and I'm worried about trying things
> > that might corrupt my repository. Could someone spell it out for me please?
>
> I do not know exactly what Cogito "seek back and forth" does,
It means to "cg-seek" back to an earlier state of the repo, and forward to a
more recent state of the repo. "seeking back and forth" means doing a lot of
"cg-seek" commands. Sorry that wasn't clear.
> but updating to git-core "master" branch may help.
I already use that branch.
Here's some commands that reproduce the problem:
$ mkdir tmpproj
$ cd tmpproj
$ cg-init
give the initial commit message and save
$ ls > a
$ cg-add a
$ cg-commit
give the commit message and save
$ cg-tag nodirs
$ mkdir d
$ mv a d/a
$ cg-rm a
$ cg-add d/a
$ cg-commit
give the commit message and save
$ cg-seek nodirs
now I would expect to see the original directory, with no 'd' subdirectory, and
just the 'a' file sitting there.
$ ls -F
a d/
$
See the problem? The 'd' directory did not exist in this version of the
repository, but it's there anyway.
Be well,
Zack
>
> Specifically, this commit intends to remove empty directory from
> the working tree, where previously checked out tree object had
> files/directories inside while newly checked out tree does not.
>
> commit 340e4f88c083b0692e6554b1c2c27fd43c7cc8d3
> Author: Junio C Hamano <junkio@cox.net>
> Date: Mon Oct 10 17:34:08 2005 -0700
>
> Remove empty directories after read-tree -u.
>
> This fixes everybody's favorite gripe that switching branch
> with 'git checkout' leaves empty directories.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: getting rid of extra directories
From: Junio C Hamano @ 2005-10-15 18:00 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20051015174103.GA2609@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
> I've been using the latest Cogito. When I seek back and forth in a git repo,
> directories I've created tend to persist backward in time, cluttering up
> earlier versions.
>
> By the discussions on this list, I'm pretty sure there's a way to stop this,
> but I don't know clearly what it is, and I'm worried about trying things
> that might corrupt my repository. Could someone spell it out for me please?
I do not know exactly what Cogito "seek back and forth" does,
but updating to git-core "master" branch may help.
Specifically, this commit intends to remove empty directory from
the working tree, where previously checked out tree object had
files/directories inside while newly checked out tree does not.
commit 340e4f88c083b0692e6554b1c2c27fd43c7cc8d3
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Oct 10 17:34:08 2005 -0700
Remove empty directories after read-tree -u.
This fixes everybody's favorite gripe that switching branch
with 'git checkout' leaves empty directories.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* getting rid of extra directories
From: Zack Brown @ 2005-10-15 17:41 UTC (permalink / raw)
To: git
Hi folks,
I've been using the latest Cogito. When I seek back and forth in a git repo,
directories I've created tend to persist backward in time, cluttering up
earlier versions.
By the discussions on this list, I'm pretty sure there's a way to stop this,
but I don't know clearly what it is, and I'm worried about trying things
that might corrupt my repository. Could someone spell it out for me please?
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Junio C Hamano @ 2005-10-15 17:13 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Daniel Barkalow, git
In-Reply-To: <863bn3lypn.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Daniel" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> Daniel> Can you give a general description of what happens? I've
> Daniel> noticed that I sometimes get spurious error messages that
> Daniel> don't actually affect the download, which I haven't tracked
> Daniel> down yet.
>
> OK, it happened this morning. While syncing to update from
> yesterday's version, I got:
>
> localhost:~/MIRROR/git-GIT % git-pull
> Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
> Getting alternates list
> got 4546738b58a0134eef154231b07d60fc174d56e3
> walk 4546738b58a0134eef154231b07d60fc174d56e3
> got d402d5566fdf226697a386dfb9858e5d954e9b91
> got 873d8e5652c06c3891278f33546c437efc209c2d
> walk d402d5566fdf226697a386dfb9858e5d954e9b91
> error:
> Getting pack list
Sorry for an empty message.
Could you do the following to establish a reliable way to
reproduce this problem in your setup, so we can diagnose it
better?
First please apply this patch to http-fetch.c and rebuild your
git.
diff --git a/http-fetch.c b/http-fetch.c
index 784aedf..2c1f72c 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1009,7 +1009,10 @@ static int fetch_object(struct alt_base
}
if (request->curl_result != CURLE_OK && request->http_code != 416) {
- ret = error("%s", request->errorstr);
+ ret = error("%s (curl_result = %d, http_code = %ld, sha1 = %s)",
+ request->errorstr, request->curl_result,
+ request->http_code,
+ sha1_to_hex(request->sha1));
release_request(request);
return ret;
}
Then, using that:
$ cd ~/MIRROR
$ rm -fr git-BROKEN
$ git-clone -n http://www.kernel.org/pub/scm/git/git.git git-BROKEN
If you got any error here, then we know we already have a way
to reproduce. Please give us a log.
If the above succeeds, then please run
$ git-fsck-objects --full
to make sure we got things OK. This should not report
anything.
Now, I'd like to make this repository as close as I can make it
to "after yesterday's pull", by rewining its top commit back to
this one:
commit f7aac2eac96b637755c89c2405a41749c8f6033a
Author: Linus Torvalds <torvalds@osdl.org>
Date: Thu Oct 13 15:38:29 2005 -0700
Add "-l" flag for repacking only local packs
$ git-reset --hard f7aac2eac96b637755c89c2405a41749c8f6033a
$ git-update-ref refs/heads/origin f7aac2eac96b637755c89c2405a41749c8f6033a
Since proposed updates (pu) branch usually contains everything
that is in the master, we need to get rid of it for this
experiment:
$ rm -f .git/refs/heads/pu
and the we get rid of objects that were added since then:
$ git-prune
$ git-fsck-objects --full
Now we are hopefully as close as "after yesterday's pull" state.
$ git-http-fetch -a -v heads/master http://www.kernel.org/pub/scm/git/git.git/
This will start with something like:
Getting alternates list
got 4546738b58a0134eef154231b07d60fc174d56e3
walk 4546738b58a0134eef154231b07d60fc174d56e3
got d402d5566fdf226697a386dfb9858e5d954e9b91
got 873d8e5652c06c3891278f33546c437efc209c2d
walk d402d5566fdf226697a386dfb9858e5d954e9b91
...
if you see the same error, instead of the empty "error:" up
above, we may see a bit more information.
^ permalink raw reply related
* Re: maybe breakage with latest git-pull and http protocol
From: Junio C Hamano @ 2005-10-15 16:37 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Daniel Barkalow, git
In-Reply-To: <863bn3lypn.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Daniel" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> Daniel> Can you give a general description of what happens? I've
> Daniel> noticed that I sometimes get spurious error messages that
> Daniel> don't actually affect the download, which I haven't tracked
> Daniel> down yet.
>
> OK, it happened this morning. While syncing to update from
> yesterday's version, I got:
>
> localhost:~/MIRROR/git-GIT % git-pull
> Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
> Getting alternates list
> got 4546738b58a0134eef154231b07d60fc174d56e3
> walk 4546738b58a0134eef154231b07d60fc174d56e3
> got d402d5566fdf226697a386dfb9858e5d954e9b91
> got 873d8e5652c06c3891278f33546c437efc209c2d
> walk d402d5566fdf226697a386dfb9858e5d954e9b91
> error:
> Getting pack list
> got 0207ab18a3876249a928e7539d8f594a4f6921f1
> got 9f7534accdf34b980a2de670cb1009dd84ee56c4
> error: Unable to find 5ad4a2766d34569f3a1278544ab64978fab14cc8 under http://www.kernel.org/pub/scm/git/git.git/
>
> Cannot obtain needed blob 5ad4a2766d34569f3a1278544ab64978fab14cc8
> while processing commit d402d5566fdf226697a386dfb9858e5d954e9b91.
>
> Definitely broken. But I can "rsync" just fine.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Junio C Hamano @ 2005-10-15 16:22 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Randal L. Schwartz, git, Daniel Barkalow
In-Reply-To: <7vd5m6py11.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
>> OK, it happened this morning. While syncing to update from
>> yesterday's version, I got:
>
> Thanks.
>
>> localhost:~/MIRROR/git-GIT % git-pull
>> Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
>> Getting alternates list
>> got 4546738b58a0134eef154231b07d60fc174d56e3
>> walk 4546738b58a0134eef154231b07d60fc174d56e3
>> got d402d5566fdf226697a386dfb9858e5d954e9b91
>> got 873d8e5652c06c3891278f33546c437efc209c2d
>> walk d402d5566fdf226697a386dfb9858e5d954e9b91
>> error:
>> Getting pack list
>> got 0207ab18a3876249a928e7539d8f594a4f6921f1
More interesting is this "error:" without error message.
"Getting pack list" is a signal that we fell back to
fetch_pack(), so this is coming from fetch_object().
I see this line could emit an empty error message, if errorstr
is empty.
if (request->curl_result != CURLE_OK && request->http_code != 416) {
ret = error("%s", request->errorstr);
release_request(request);
return ret;
}
So if that is the case maybe my previous speculation that we
sometimes forget to issue a necessary request was wrong. We
asked for that object and got an error from cURL library...
BTW, I do not think this is related to git.git repository
problem, but I wonder why we do not do fetch_object() against
each altbase in http-fetch.c::fetch(); nobody said you cannot
borrow unpacked object from your neighbour.
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Junio C Hamano @ 2005-10-15 16:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Randal L. Schwartz, git
In-Reply-To: <863bn3lypn.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> OK, it happened this morning. While syncing to update from
> yesterday's version, I got:
Thanks.
> localhost:~/MIRROR/git-GIT % git-pull
> Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
> Getting alternates list
> got 4546738b58a0134eef154231b07d60fc174d56e3
> walk 4546738b58a0134eef154231b07d60fc174d56e3
> got d402d5566fdf226697a386dfb9858e5d954e9b91
> got 873d8e5652c06c3891278f33546c437efc209c2d
> walk d402d5566fdf226697a386dfb9858e5d954e9b91
> error:
> Getting pack list
> got 0207ab18a3876249a928e7539d8f594a4f6921f1
Here is the beginning of a session that succeeded:
: siamese; GIT_DIR=. git-http-fetch -v -a heads/master \
http://www.kernel.org/pub/scm/git/git.git/
Getting alternates list
got 4546738b58a0134eef154231b07d60fc174d56e3
walk 4546738b58a0134eef154231b07d60fc174d56e3
got d402d5566fdf226697a386dfb9858e5d954e9b91
got 873d8e5652c06c3891278f33546c437efc209c2d
got 5ad4a2766d34569f3a1278544ab64978fab14cc8
walk d402d5566fdf226697a386dfb9858e5d954e9b91
...
The difference is that this log gets 5ad4a2 blob, before it
starts walking d402d5 commit, while Merlyn's log shows we tried
to walk that commit before getting the blob. I think what is
happening is:
- we request 454673 commit, and get it.
- we start requesting trees, blobs, and parent commit
reachable from it. Especially, 5ad4a2 blob and d402d5
commit are asked.
- as soon as d402d5 commit arrives we walk and find out we
need 5ad4a2 blob. In the case that happened to work, that
blob has already arrived because it was also part of the
454673 commit, but in Merlyn's case that blob has not
arrived yet. "Getting pack list" on the next line is an
indication that the fetch_object incorrectly decided that
the object we are waiting for is not available unpacked,
which does not (and should not) happen in the case we got
the blob object in time.
I have a suspicion that the recent multi-fetch work has some
interesting interaction with the assumption Sergey's fetch.c
optimization makes.
^ permalink raw reply
* Re: maybe breakage with latest git-pull and http protocol
From: Randal L. Schwartz @ 2005-10-15 13:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510141543030.23242@iabervon.org>
>>>>> "Daniel" == Daniel Barkalow <barkalow@iabervon.org> writes:
Daniel> Can you give a general description of what happens? I've
Daniel> noticed that I sometimes get spurious error messages that
Daniel> don't actually affect the download, which I haven't tracked
Daniel> down yet.
OK, it happened this morning. While syncing to update from
yesterday's version, I got:
localhost:~/MIRROR/git-GIT % git-pull
Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
Getting alternates list
got 4546738b58a0134eef154231b07d60fc174d56e3
walk 4546738b58a0134eef154231b07d60fc174d56e3
got d402d5566fdf226697a386dfb9858e5d954e9b91
got 873d8e5652c06c3891278f33546c437efc209c2d
walk d402d5566fdf226697a386dfb9858e5d954e9b91
error:
Getting pack list
got 0207ab18a3876249a928e7539d8f594a4f6921f1
got 9f7534accdf34b980a2de670cb1009dd84ee56c4
error: Unable to find 5ad4a2766d34569f3a1278544ab64978fab14cc8 under http://www.kernel.org/pub/scm/git/git.git/
Cannot obtain needed blob 5ad4a2766d34569f3a1278544ab64978fab14cc8
while processing commit d402d5566fdf226697a386dfb9858e5d954e9b91.
Definitely broken. But I can "rsync" just fine.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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