* Re: Seeing added and removed files between two tree states
From: Junio C Hamano @ 2006-12-04 21:18 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <1165253146.32764.3.camel@okra.transitives.com>
Alex Bennee <kernel-hacker@bennee.com> writes:
> In there a way to see just what files where added between two points in
> the tree? I want something better than parsing the diffstat.
>
> I thought git-ls-files -ad comittish..comitishb would do the trick but
> it seems not.
$ git diff-tree --name-status --diff-filter=A HEAD~64 HEAD
Variants of the above are possible. If you want to see addition
and deletion, use --diff-filter=AD.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Jakub Narebski @ 2006-12-04 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <87bqmj2zit.wl%cworth@cworth.org>
Carl Worth wrote:
> But what might be very interesting is a modified "git-apply --index"
> that would not fail in this case, but would instead do the following:
>
> 1. Apply the patch to the working tree
>
> 2. Apply the patch to the index
>
> And of course, if either fails then the entire apply operation fails,
> leaving no changes to working tree or to the index.
Or even new option to git-apply, namely --index-only, which would apply
patch to index only.
BTW. With git-apply we have three possibilities to apply patch to:
HEAD, index and working tree version, and three possibilities to
store result in: working tree only, working tree and index both,
and index only.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-04 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612041114240.3476@woody.osdl.org>
Hi,
On Mon, 4 Dec 2006, Linus Torvalds wrote:
> On Mon, 4 Dec 2006, Johannes Schindelin wrote:
> >
> > On Mon, 4 Dec 2006, Jakub Narebski wrote:
> >
> > > Johannes Schindelin wrote:
> > >
> > > > On Mon, 4 Dec 2006, Jakub Narebski wrote:
> > > >
> > > >> [...] git should acquire core.filesystemEncoding configuration variable
> > > >> which would encode from filesystem encoding used in working directory
> > > >> and perhaps index to UTF-8 encoding used in repository (in tree objects)
> > > >> and perhaps index.
> > > >
> > > > So, you want to pull in all thinkable encodings? Of course, you could rely
> > > > on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
> > > > uses it already. But I never use mailinfo, so I do not need libiconv.)
> > >
> > > A conditional dependency. If you don't have libiconv, this feature wouldn't
> > > be available.
> >
> > You are speaking as somebody compiling git from source. We are a minority.
>
> You guys are ignoring the _real_ problem.
>
> It has nothing at all to do with dependencies on external packages. The
> REAL problem is that if you do locale-dependent trees and other git
> objects, git will STOP WORKING.
The issue was _not_ locale-dependent trees, but file systems which
_change_ the encoding. And even then, Jakub's proposition reencoding could
work, because it is an _encoding_ after all, i.e. bijective (reversable
mapping for you non-Math guys). Not at all comparable to cases
insensitivity, which _loses_ information.
But for reasons described in another mail, there are more fundamental
problems with encodings, especially with MacOSX which (braindeadly)
encodes _differently_ when writing and reading.
So, we reach the same conclusion, but for different reasons.
Ciao,
^ permalink raw reply
* Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-04 21:01 UTC (permalink / raw)
To: Wolfgang Fischer; +Cc: Jakub Narebski, git
In-Reply-To: <7617FA7E-D49A-4A4C-B033-C2CB20623F5F@wf227.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1855 bytes --]
Hi,
thank you, Wolfgang, for back Cc'ing me (Jakub never does that...), but I
am Cc'ing the git list here, also. Hope both of you don't mind.
On Mon, 4 Dec 2006, Wolfgang Fischer wrote:
> On 04.12.2006, at 20:37, Jakub Narebski wrote:
>
> > And HFS+ is on MacOS X / Darwin, without iconv in libc...
>
> And, what is even worse, is the fact that HFS+ uses an encoding, which is not
> represented in libiconv.
>
> If you CREATE a file, you can use UTF8-NFC
> (Normalization-Form-Composed), but if you later READDIR a directory, you
> will get the very same name back in the encoding used by HFS+, which is
> UTF8-NFD Normalization-Form-Decomposed. The difference is noticeable for
> some non-ASCII characters like e.g.
>
> LATIN SMALL LETTER A WITH DIAERESIS U+00E4 or U+0061 U+0308 in Unicode.
>
> If you need a sane backward mapping, one has to use some CoreFoundation
> interface, for which I removed the details out of my brain, in order to
> reclaim that memory area (garbage collection!). But I can help you with
> some details and probably code, if you really need that conversion
> direction.
Yes. When my iBook was still alive, I saw that problem, too: writing and
reading filenames were completely different issues.
Worse, you can experience the same on USB-Sticks when accessing them with
different OSes. For example, when checking out a git repo on a stick with
Linux, and then calling git-status on the same stick with Windows XP, you
see an issue with the file "Märchen", like you did on MacOSX.
So, please, please, please do not try to be smart about filename encodings
in git, but just DO NOT USE ANYTHING BUT ASCII IN FILENAMES IF THE
REPOSITORY IS GOING TO BE PUT ON DIFFERENT OPERATING SYSTEMS/FILE SYSTEMS.
(Wow, the Caps Lock key is _not_ dead after all. I must have been infected
by Linus...)
Ciao,
Dscho
^ permalink raw reply
* Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-04 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0612041114240.3476@woody.osdl.org>
Dnia poniedziałek 4. grudnia 2006 21:26, Linus Torvalds napisał:
>>>> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>>>>
>>>>> [...] git should acquire core.filesystemEncoding configuration variable
>>>>> which would encode from filesystem encoding used in working directory
>>>>> and perhaps index to UTF-8 encoding used in repository (in tree objects)
>>>>> and perhaps index.
> You guys are ignoring the _real_ problem.
>
> It has nothing at all to do with dependencies on external packages. The
> REAL problem is that if you do locale-dependent trees and other git
> objects, git will STOP WORKING.
>
> A filename in a tree object _has_ to be see as a pure 8-bit character
> stream. They _have_ to be compared with "memcmp()", and they have to sort
> the same way and mean EXACTLY the same thing for everybody.
What I propose is having filename in tree object UTF-8 encoded. I don't
know if git relies heavily that filename encoding on filesystem (in working
area) is the same as in the index, is the same as in a tree object.
Although I'm not sure what is the problem. You checkout non US-ASCII filename
out of git; the file can have strange characters in a name, but should
encode to the filename as is in git. The problem migh be some forbidden by
filesystem characters in a filename perhaps.
Although Wolfgang Fischer wrote (to me and Johannes Schindelin) that HFS+
uses UTF8-NFC (Normalization-Form-Composed) when creating a file, while
readdir returns encoding used by HFS+, which is UTF8-NFD (Normalization-Form-
Decomposed). [Explitive censored]
> If a filesystem cannot represent that name AS THAT BYTE SEQUENCE then the
> filesystem is broken. No ifs, buts, maybes about it. I'm sorry, but that's
> how it is.
We have some configuration variables to work around broken filesystems,
like core.ignoreStat, so why not core.filesystemEncoding.
--
Jakub Narebski
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Shawn Pearce @ 2006-12-04 20:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612041114240.3476@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> You guys are ignoring the _real_ problem.
>
> It has nothing at all to do with dependencies on external packages. The
> REAL problem is that if you do locale-dependent trees and other git
> objects, git will STOP WORKING.
Yes!
In jgit I assumed all tree entry names were encoded in UTF8.
Then I later learned they aren't. Foolish me.
As Linus points out its a HUGE problem that the caller of
git-write-tree gets to decide what encoding should be used for
that tree. Especially if someone else wants to use a different
encoding for the same filename (think ISO-8859-1 vs. UTF-8)!
I'd rather just force the tree entry names to be encoded in UTF-8
always, as its compact for most western texts (which many filenames
are), and at least degrades to supporting the non western texts.
A per-project setting is essentially impossible as we have
no such concept today, and a per-repository setting (like
i18n.commitEncoding) lets two different users encode the same
filename differently, which means two different tree SHA1s with
the exact same content... not correct!
> This is true for all levels of the git archive. It's true for blob
> content, it's true for filenames in trees, and it is true for commits. The
> commit message is actually somewhat easier (because we have nothing to
> "compare" it to afterwards in the checked-out tree), so the commit message
> is the _one_ thing we can kind of play games with, but even there, once
> it's done, it's done, and it's just a stream of bytes.
Commit encoding is a problem. Clearly the "header parts"
(tree, parent) are US-ASCII but the author and committer lines
can be anything. So can the body. And we have no way of knowing
what encoding was used years later, we can only guess and display
it wrong.
We really should either normalize all commit messages to a single
encoding (again, UTF-8) or embed the encoding as part of the headers
somehow (e.g. look at how XML embeds the document encoding in the
start of the document).
--
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-04 20:51 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86odqjl8vp.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>
> Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
> >>
> Eric> Can you try:
> >>
> Eric> git update-ref refs/remotes/git-svn \
> Eric> <last commit successfully imported from git-svn>
> >>
> Eric> and running rebuild again?
> >>
> >> Yes, and now after seeing 14000 lines scroll by, I tried again:
>
> Eric> <snip>
>
> >> Anything you want me to try now? I'm not in a fast net place (at
> >> least not for a week), so I can't rebuild from scratch.
>
> Eric> Which version of the SVN libraries are you using?
>
> SVN::Core is 1.4.2 - not sure what distro that comes from.
Same here.. I'm still waiting for it to fetch and will try to reproduce
it here.
Meanwhile, can you re-run and use Data::Dumper to dump out $fb right
before it dies with "no blob information"? (in
close_file() of SVN::Git::Fetcher).
Also, can you put some trace messages and dump arguments to add_file()
and open_file() in that package, too?
Thanks.
--
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Linus Torvalds @ 2006-12-04 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612041114240.3476@woody.osdl.org>
On Mon, 4 Dec 2006, Linus Torvalds wrote:
>
> If a filesystem cannot represent that name AS THAT BYTE SEQUENCE then the
> filesystem is broken. No ifs, buts, maybes about it. I'm sorry, but that's
> how it is.
Btw, what this means in practice is that when git creates a file with a
certain sequence of bytes, then
(a) readdir had better return _that_ sequence of bytes, or git will see
it as somethign else.
(b) opening it with that same sequence of bytes had better work.
This does not mean that a filesystem may not internally use some other
encoding. It just means that if the filesystem - when converting back and
forth between the internal encoding and the one it shows to user space -
had better convert back to the exact same thing.
Also, note that for most projects, even a broken filesystem doesn't
actually matter - it's enough that the filesystem gets the conversions
right for the particular set of names in a particular project. So any
project that just has 7-bit filenames will obviously never even see any
issues at all, even if the filesystem it runs on then does something
strange with 8-bit filenames.
This is one reason why UNIX's "everything is a stream of bytes" is so
important, and whyprograms should generally work with byte streams, not
"wide strings" or similar. It's the only way that you can reliably work
across different locales. Use wide strings and locale-specific stuff
_only_ for actually showing users something on the tty, for example.
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Jakub Narebski @ 2006-12-04 20:46 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20061204202102.GH940MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Mon, Dec 04, 2006 at 07:05:04PM +0100, Jakub Narebski wrote:
>>
>> If this [dirdiff] has support for git, could you add it to GitWiki:
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>
> Well, it's not exactly user friendly at the moment.
> Plus, it's not my tool. I just made a couple of changes to get
> it to work for me.
>
> I noticed Paul was working on a different tool lately, but I haven't
> had time to check it out. Maybe it does the same and more.
If it is GPL, you can post it anyway. As I understand from log
you have added git interface, isn't it? You are then perfectly
in the right to post info at GitWiki about this tool.
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-12-04 20:41 UTC (permalink / raw)
To: Torgil Svensson; +Cc: sf-gmane, sf, git, Martin Waitz
In-Reply-To: <e7bda7770612041226j4d4a5584m279afa9a2d7dfe74@mail.gmail.com>
On Mon, 4 Dec 2006, Torgil Svensson wrote:
>
> Okay, missed that part. I wasn't familiar with contents of the CVS
> modules files and misinterpreted your suggestion.
>
> MODULE [OPTIONS] [&OTHERMODULE...] [DIR] [FILES]
>
> So all this is UI only and the "normal" operations on the supermodule
> will just ignore what's behind the commit-links?
Right. That's how CVS modules work (although in the case of CVS modules,
the "dir" thing is obviously there in the "modules" file, so it's not
_purely_ UI in CVS - this would likely be different in a git
implementation, because the "tree" object ends up telling not just the
exact version, but the location too).
So my suggestion basically boils down to:
- "fetch" and "clone" etc will just look at the "modules" file, and
recursively fetch/clone whatever the module files talks about. This is
the "thin veneer to make it _look_ like git actually understands
submodules" part. It woudln't really - they're very much tacked on.
- the tree entries are what makes the "once you have all the submodule
objects, this is how you can do 'diff' and 'checkout' on them, and this
is what tells you the exact version that goes along with a particular
supermodule version".
In other words, the simple and stupid way to do this is to just consider
these two things two totally independent issues, and have different
mechanisms for telling different operations what to do.
Is it "pretty"? No. The whole sub-module thing wouldn't be a tightly
integrated low-level thing, it would very much be all about tracking
multiple _separate_ git repositories, and just make them work well
together. They'd very much still be separate, with just some simple
infrastructure glue to make them look somewhat integrated.
So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
actually think that users _want_ hacky. Exactly because "deep integration"
ends up having so many _bad_ features, so it's better to have a thin and
simple layer that you can actually see past if you want to.
^ permalink raw reply
* Re: jgit performance update
From: Juergen Stuber @ 2006-12-04 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <200612040039.00315.robin.rosenberg.lists@dewire.com>
Hej Robin,
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> söndag 03 december 2006 23:42 skrev Juergen Stuber:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > GitWiki tells us about egit/jgit repository at
>> > http://www.spearce.org/projects/scm/egit.git
>>
>> I tried to access that with git 1.4.4.1 from Debian but
>>
>> % git clone http://www.spearce.org/projects/scm/egit.git
>>
>> hangs, the first time after "walk
>> e339766abc2b919e7bb396cae22ddef065821381", the second time after "walk
>> 9eec90ec5da239e063eaff6305d77294dc03396e" which is the "walk" line just
>> before it.
> Works fine here. (git 1.4.4.gf05d).
now it works fine for me, too.
Tack
Jürgen
--
Jürgen Stuber <juergen@jstuber.net>
http://www.jstuber.net/
gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Linus Torvalds @ 2006-12-04 20:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0612042009590.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 4 Dec 2006, Johannes Schindelin wrote:
>
> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>
> > Johannes Schindelin wrote:
> >
> > > On Mon, 4 Dec 2006, Jakub Narebski wrote:
> > >
> > >> [...] git should acquire core.filesystemEncoding configuration variable
> > >> which would encode from filesystem encoding used in working directory
> > >> and perhaps index to UTF-8 encoding used in repository (in tree objects)
> > >> and perhaps index.
> > >
> > > So, you want to pull in all thinkable encodings? Of course, you could rely
> > > on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
> > > uses it already. But I never use mailinfo, so I do not need libiconv.)
> >
> > A conditional dependency. If you don't have libiconv, this feature wouldn't
> > be available.
>
> You are speaking as somebody compiling git from source. We are a minority.
You guys are ignoring the _real_ problem.
It has nothing at all to do with dependencies on external packages. The
REAL problem is that if you do locale-dependent trees and other git
objects, git will STOP WORKING.
A filename in a tree object _has_ to be see as a pure 8-bit character
stream. They _have_ to be compared with "memcmp()", and they have to sort
the same way and mean EXACTLY the same thing for everybody.
If a filesystem cannot represent that name AS THAT BYTE SEQUENCE then the
filesystem is broken. No ifs, buts, maybes about it. I'm sorry, but that's
how it is.
This is _exactly_ the same issue as case independence. Git does not ignore
case, and it really CANNOT ignore case. Ignoring case would cause horrible
and deep problems, and it has nothing to do with dependencies on libraries
(although it _would_ get much much worse from locale settings, and again
having different locales compare the same name differently because case
rules are different).
So it really boils down to one one: git saves a byte stream. Not text.
This is true for all levels of the git archive. It's true for blob
content, it's true for filenames in trees, and it is true for commits. The
commit message is actually somewhat easier (because we have nothing to
"compare" it to afterwards in the checked-out tree), so the commit message
is the _one_ thing we can kind of play games with, but even there, once
it's done, it's done, and it's just a stream of bytes.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-04 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf-gmane, sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612030946150.3476@woody.osdl.org>
On 12/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> > If you have an old irrelevant submodule in the history that happens to
> > have the same name as one of them you are interested in, do you get
> > this as well?
>
> It could be "solved" by simply having the requirement that all modules
> need to be named differently (notice that "module name" is _not_ the same
> thing as "the directory name where the module shows up".
Okay, missed that part. I wasn't familiar with contents of the CVS
modules files and misinterpreted your suggestion.
MODULE [OPTIONS] [&OTHERMODULE...] [DIR] [FILES]
So all this is UI only and the "normal" operations on the supermodule
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-04 20:10 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061204200844.GC30316@hand.yhbt.net>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>>
Eric> Can you try:
>>
Eric> git update-ref refs/remotes/git-svn \
Eric> <last commit successfully imported from git-svn>
>>
Eric> and running rebuild again?
>>
>> Yes, and now after seeing 14000 lines scroll by, I tried again:
Eric> <snip>
>> Anything you want me to try now? I'm not in a fast net place (at
>> least not for a week), so I can't rebuild from scratch.
Eric> Which version of the SVN libraries are you using?
SVN::Core is 1.4.2 - not sure what distro that comes from.
Eric> Also, are you
Eric> tracking https://svn.perl.org/parrot/trunk or just
Eric> https://svn.perl.org/parrot (top-level)
http://svn.perl.org/parrot
--
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.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-04 20:10 UTC (permalink / raw)
To: git
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
> So, if I could do:
>
> git apply --index
> git commit-index-content <files that add the test case>
> git commit-index-content
>
> Then this would do exactly what I want. I wouldn't even have
> to think about whether my local modifications are to any of
> the same paths as touched by the patch.
BTW, the current "apply --index" doesn't allow what I imagined in the
scenario above. It notices that the affected file is different in the
working tree compared to the index and just refuses to do anything.
Given that safety-valve in git-apply, the current behavior of "git
commit paths" would allow for splitting a submitted patch into two
commits.
The difference is that it only works if the local modifications do not
affect any of the same paths as the patch. The user is freed from
worrying about this somewhat, since if it's not the case, then
git-apply just complains and doesn't do anything.
But what might be very interesting is a modified "git-apply --index"
that would not fail in this case, but would instead do the following:
1. Apply the patch to the working tree
2. Apply the patch to the index
And of course, if either fails then the entire apply operation fails,
leaving no changes to working tree or to the index.
With that new git-apply behavior, then the scenario I outlined above
would work, and would work in spite of any changes to the same file in
both the working tree and the index. It would also require the
separate commands for commit-index-content vs.
commit-working-tree-content as described in my original message above.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-04 20:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slfvl95j.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>
> Eric> Can you try:
>
> Eric> git update-ref refs/remotes/git-svn \
> Eric> <last commit successfully imported from git-svn>
>
> Eric> and running rebuild again?
>
> Yes, and now after seeing 14000 lines scroll by, I tried again:
<snip>
> Anything you want me to try now? I'm not in a fast net place (at
> least not for a week), so I can't rebuild from scratch.
Which version of the SVN libraries are you using? Also, are you
tracking https://svn.perl.org/parrot/trunk or just
https://svn.perl.org/parrot (top-level)
--
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-04 20:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061204195452.GB27342@soma>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> Can you try:
Eric> git update-ref refs/remotes/git-svn \
Eric> <last commit successfully imported from git-svn>
Eric> and running rebuild again?
Yes, and now after seeing 14000 lines scroll by, I tried again:
localhost.local:..RROR/parrot-GITSVN % git-svn multi-fetch
Fetching git-svn
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/RequirePortableShebang.pm
M trunk/compilers/past-pm/POST/Compiler.pir
M trunk/compilers/past-pm/PAST/Compiler.pir
M trunk/compilers/past-pm/PAST-pm.pir
M trunk/languages/perl6/src/quote.pir
M trunk/languages/perl6/src/classes/Str.pir
M trunk/languages/perl6/src/classes/Code.pir
M trunk/languages/perl6/src/classes/Num.pir
M trunk/languages/plumhead/t/selection.txt
M trunk/languages/plumhead/t/superglobals.t
M trunk/languages/plumhead/t/strings.t
M trunk/languages/tcl/runtime/builtin/clock.pir
no blob information
512 at /opt/git/bin/git-svn line 457
main::fetch_lib() called at /opt/git/bin/git-svn line 328
main::fetch() called at /opt/git/bin/git-svn line 973
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
512 at /opt/git/bin/git-svn line 980
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
Anything you want me to try now? I'm not in a fast net place (at
least not for a week), so I can't rebuild from scratch.
--
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.
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-04 19:54 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86zma3lahj.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>
> Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
> >>
> Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >> >>
> >> >> Does this ring a bell?
> >>
> Eric> Nope.
> >>
> Eric> This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
> Eric> to reproduce this with git svn fetch -r15940:15941
> >>
> >> No, and that worked for me as well. Apparently, I might have corrupted my
> >> metadata because I updated git-svn while I was using it. Is there any way to
> >> reset the metadata without having to re-fetch 15000 revisions?
>
> Eric> rm .git/refs/remotes/$GIT_SVN_ID .git/svn/$GIT_SVN_ID/.rev_db
> Eric> git svn -i $GIT_SVN_ID rebuild
>
> That's not working:
>
> localhost.local:..RROR/parrot-GITSVN % git-svn -i git-svn rebuild
> fatal: 'origin': unable to chdir or not a git archive
> fatal: unexpected EOF
> Failed to find remote refs
> 256 at /opt/git/bin/git-svn line 2151
> main::safe_qx('git-ls-remote', 'origin', 'refs/remotes/git-svn') called at /opt/git/bin/git-svn line 3404
> main::copy_remote_ref() called at /opt/git/bin/git-svn line 226
> main::rebuild() called at /opt/git/bin/git-svn line 187
Can you try:
git update-ref refs/remotes/git-svn \
<last commit successfully imported from git-svn>
and running rebuild again?
--
^ permalink raw reply
* Re: [ANNOUNCE] gitfs pre-release 0.04
From: Jakub Narebski @ 2006-12-04 19:54 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: git
In-Reply-To: <20061204200349.GX47959@gaz.sfgoth.com>
Mitchell Blank Jr wrote:
> Jakub Narebski wrote:
>
>> Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
>> configuration variable.
>
> Yes, but it has to be a symlink pointing into "refs/", not just a regular
> file holding a hash value. Which is fine for most purposes but sort of a
> pain for me.
>
> I'll probably have it be a symlink to "refs/gitfs-dynamic" or something and
> then have "refs" be populated with that synthetic file and symlinks to
> any of the normal contents of the refs directory. Not too bad, but will
> take a little bit of code.
You would have to wait a bit. There was talk on git mailing list about
allowing HEAD to point to non-head ref, or even bare sha1, only forbidding
committing to such HEAD (but allowing checkout of arbitrary revision,
not only branch, but also remote branch, tag, or branch~n).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Michael Loeffler @ 2006-12-04 19:49 UTC (permalink / raw)
To: git
In-Reply-To: <1165261102.20055.9.camel@ibook.zvpunry.de>
I used the wrong email-account for this patch, please reply to
zvpunry@zvpunry.de. Sorry.
bye
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Jakub Narebski @ 2006-12-04 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <1165261102.20055.9.camel@ibook.zvpunry.de>
Michael Loeffler wrote:
> The trailing / is enough to decide if this should map everything under
> refs/heads/ to refs/somewhere/.
>
> The "*" should be reserved for the use as regex operator.
>
> Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
> ---
> I want to use regular expressions to match remote refs, so I try to
> implement this. But the current globfetch syntax needs the '*'.
>
> Maybe it is not to late to change the syntax to this:
> Pull: refs/heads/:refs/remotes/origin/
>
> What do you think?
I'm not sure if regexp support is truly better than the usual path globbing,
as in fnmatch / glob.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 3/3] git-fetch: allow regular expressions in the refspec
From: Michael Loeffler @ 2006-12-04 19:45 UTC (permalink / raw)
To: git
This allows the use of regex in refspecs, but it does not support
extended regex because the option -r is a GNU-sed extension.
Now it is possible to write the following refspecs:
Pull: refs/heads/master:refs/remotes/origin/master
Pull: refs/heads/:refs/remotes/origin/
Pull: refs/heads/\(.*fetch.*\):refs/heads/fetch/\1
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
---
This patch has still some problems with MacOS X (I think it is the
sed-script). I will look at it tomorrow.
What do you think about this?
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 38af4cb..0162154 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -100,30 +100,86 @@ expand_refs_wildcard () {
for ref
do
lref=${ref#'+'}
- # a non glob pattern is given back as-is.
- expr "z$lref" : 'zrefs/.*/:refs/.*/$' >/dev/null || {
- echo "$ref"
- continue
- }
-
- from=`expr "z$lref" : 'z\(refs/.*/\):refs/.*/$'`
- to=`expr "z$lref" : 'zrefs/.*/:\(refs/.*/\)$'`
local_force=
test "z$lref" = "z$ref" || local_force='+'
- echo "$ls_remote_result" |
- (
- IFS=' '
- while read sha1 name
- do
- mapped=${name#"$from"}
- if test "z$name" != "z${name%'^{}'}" ||
- test "z$name" = "z$mapped"
- then
- continue
- fi
- echo "${local_force}${name}:${to}${mapped}"
- done
- )
+
+ if expr "z$lref" : 'zrefs/.*/:refs/.*/$' >/dev/null
+ then
+ from=`expr "z$lref" : 'z\(refs/.*/\):refs/.*/$'`
+ to=`expr "z$lref" : 'zrefs/.*/:\(refs/.*/\)$'`
+ echo "$ls_remote_result" |
+ (
+ IFS=' '
+ while read sha1 name
+ do
+ mapped=${name#"$from"}
+ if test "z$name" != "z${name%'^{}'}" ||
+ test "z$name" = "z$mapped"
+ then
+ continue
+ fi
+ echo "${local_force}${name}:${to}${mapped}"
+ done
+ )
+ else
+ local srcref dstref sedscript mapped
+
+ srcref=`expr "z$lref" : "z\(refs/[^:]*\):refs/[^:]*$"`
+ dstref=`expr "z$lref" : "zrefs/[^:]*:\(refs/[^:]*\)$"`
+ sedscript="
+# ignore dereferenced tags
+/\^{}$/{
+ # delete pattern space and start next cycle
+ d
+}
+
+# remove sha1 and the '\t'
+s/^[a-f0-9]\{40\}\t//
+
+# for each matching ref, do the following
+\:${srcref}:{
+ # copy the ref name into the hold space
+ h
+
+ # prepend local_force to the new srcref
+ s/^/${local_force}/
+
+ # append an colon to the new srcref
+ s/$/:/
+
+ # exchange pattern and hold space
+ x
+
+ # do the substitution
+ s:${srcref}:${dstref}:
+
+ # append the new dstref to the hold space
+ H
+
+ # exchange pattern and hold space
+ x
+
+ # remove the embedded newline to build the new refspec
+ s/:\n/:/
+
+ # print the new refspec
+ p
+}
+"
+ mapped=$(echo "$ls_remote_result" | sed -n -e "$sedscript")
+
+ if test "$?" -ne 0
+ then
+ echo "The failed refspec was: ${srcref}:${dstref}" >&2
+ fi
+
+ if test -z "$mapped"
+ then
+ echo "$ref"
+ else
+ echo "$mapped"
+ fi
+ fi
done
}
--
1.4.4
^ permalink raw reply related
* Re: [ANNOUNCE] gitfs pre-release 0.04
From: Mitchell Blank Jr @ 2006-12-04 20:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el1tg0$n07$1@sea.gmane.org>
Jakub Narebski wrote:
> Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
> configuration variable.
Yes, but it has to be a symlink pointing into "refs/", not just a regular
file holding a hash value. Which is fine for most purposes but sort of a
pain for me.
I'll probably have it be a symlink to "refs/gitfs-dynamic" or something and
then have "refs" be populated with that synthetic file and symlinks to
any of the normal contents of the refs directory. Not too bad, but will
take a little bit of code.
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-04 18:12 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86hcwbnb0o.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>
> Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>
> >> Does this ring a bell?
>
> Eric> Nope.
>
> Eric> This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
> Eric> to reproduce this with git svn fetch -r15940:15941
>
> No, and that worked for me as well. Apparently, I might have corrupted my
> metadata because I updated git-svn while I was using it. Is there any way to
> reset the metadata without having to re-fetch 15000 revisions?
rm .git/refs/remotes/$GIT_SVN_ID .git/svn/$GIT_SVN_ID/.rev_db
git svn -i $GIT_SVN_ID rebuild
I don't think that updating git-svn while using it is a problem, because
Perl won't (to my knowledge) reread it after it's loaded, and git-svn
does not re-exec itself (it'll fork, however). Weird... the change
(15941) was a property-only change; however.
--
^ permalink raw reply
* Re: [ANNOUNCE] gitfs pre-release 0.04
From: Jakub Narebski @ 2006-12-04 19:40 UTC (permalink / raw)
To: git
In-Reply-To: <20061204194011.GW47959@gaz.sfgoth.com>
Mitchell Blank Jr wrote:
> * At the top of each tree there's now a synthetic ".git" directory
> which includes some symlinks and a "HEAD" file that points to
> the currently viewed root. The idea is to allow some simple git
> commands to work inside of a gitfs directory. Unfortunately this doesn't
> work yet since git no longer recognizes a non-symbolic ref in "HEAD".
> I'll try to work around this soon.
Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
configuration variable.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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