* Re: [PATCH] Add --show-size to git log to print message size
From: Sean @ 2007-07-15 12:35 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150529l7e9bdd9fu253d38f99d4d2ed7@mail.gmail.com>
On Sun, 15 Jul 2007 14:29:04 +0200
"Marco Costalba" <mcostalba@gmail.com> wrote:
> To further push for git patch, please check this from current linux tree:
>
> git log --parents --pretty=raw -z -r -p c4201214
>
> As you can see the diff contains a '\0' value (actually removed by the patch).
>
> qgit of course fails, as any tool based on parsing '\0' delimiting
> character records. If the size of the patch was explicitly given
> instead no fail will occur.
>
If you only look for ^\0 (ie. first position only) the parsing should
be okay. Not that it helps with the performance issue you're trying
to address.
Sean
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 12:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150432v780d8361yba2fc729504d5b73@mail.gmail.com>
To further push for git patch, please check this from current linux tree:
git log --parents --pretty=raw -z -r -p c4201214
As you can see the diff contains a '\0' value (actually removed by the patch).
qgit of course fails, as any tool based on parsing '\0' delimiting
character records. If the size of the patch was explicitly given
instead no fail will occur.
Marco
^ permalink raw reply
* [PATCH] Minor addition to git-check-ref-format man page
From: Sean @ 2007-07-15 12:18 UTC (permalink / raw)
To: git
Mention that refname must include at least one slash to
be considered valid.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Documentation/git-check-ref-format.txt | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 13a5f43..4f80053 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -11,11 +11,13 @@ SYNOPSIS
DESCRIPTION
-----------
-Checks if a given 'refname' is acceptable, and exits non-zero if
-it is not.
+Checks if a given 'refname' is acceptable and exits with zero if
+it is all right. To be considered acceptable, the refname must
+contain at least one slash '/' character (eg. heads/master).
A reference is used in git to specify branches and tags. A
-branch head is stored under `$GIT_DIR/refs/heads` directory, and
+branch head is stored under `$GIT_DIR/refs/heads` directory, a
+remote-branch head is stored under `$GIT_DIR/refs/remotes`, and
a tag is stored under `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how refs are named:
@@ -32,7 +34,7 @@ imposes the following rules on how refs are named:
. It cannot end with a slash `/`.
-These rules makes it easy for shell script based tools to parse
+These rules make it easy for shell script based tools to parse
refnames, pathname expansion by the shell when a refname is used
unquoted (by mistake), and also avoids ambiguities in certain
refname expressions (see gitlink:git-rev-parse[1]). Namely:
--
1.5.2.2
^ permalink raw reply related
* Re: CVS -> SVN -> Git
From: Michael Haggerty @ 2007-07-15 12:04 UTC (permalink / raw)
To: esr; +Cc: Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <20070715013949.GA20850@thyrsus.com>
Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
>> The CVS history *does*
>> have to be deformed a bit to fit into SVN, and an svn2xxx converter
>> would have to undo the deformation.
>
> Then perhaps the right thing to think about is this: how exactly does
> CVS history need to be deformed, and is there some way to express the
> lost information as conventional properties or tags?
Hmmm, perhaps "deformed" was not the best word. "Reorganized" is a
better description.
For example, cvs2svn internally deduces which files should be added to a
given branch in a given commit. But the information cannot be output to
SVN in that form. Instead, cvs2svn has to figure out which
*directories* to copy to the branch directory, then which files to
remove from the copied directory (because they shouldn't have been
tagged), and which other files to copy from other sources. This extra
work, which is quite time- and space-consuming, is worse than pointless
when converting to git, because git has to invert the process to figure
out which individual files have to be tagged!
>> My idea is not to built (for example) cvs2git; rather, I'd like cvs2svn
>> to be split conceptually into two tools:
>
> Well, that makes more sense. But how would whatever the first half outputs
> be different from an svn dump file?
The interface between the two halves does not necessarily need to be a
serialized data stream; it could just as well be via the Python API that
is used internally by cvs2svn to access the reconstructed commits and
supporting databases. This would require the second half to be written
in Python, but otherwise would be very flexible and would avoid the need
to find a be-all serialized format.
Michael
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 11:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: VMiklos, git
In-Reply-To: <20070715104712.GF2568@steel.home>
On Sun, Jul 15, 2007 at 12:47:12PM +0200, Alex Riesen wrote:
> Count me out. Junio convinced me instead and having tried the
> subprojects I find it really convenient: I can choose when and what
> should be updated and I can see what _can_ be updated, iff I decide
> to. Subprojects defined in such a loosely way are more flexible then
> having git-pull fetch subprojects by default.
I agree that fetching should probably be left as a separate operation,
but if you have all the data, then I find it very inconvenient that
every time you switch to a different commit you have to update
all the subprojects separately too.
Did you change your mind about this part too?
> Sometimes I even want be
> _sure_ the subprojects are completely untouched (I have some critical
> parts in them).
The update in the superproject would fail if the subproject is dirty
(just as with files.)
skimo
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Michael Haggerty @ 2007-07-15 11:48 UTC (permalink / raw)
To: David Frech; +Cc: esr, Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <7154c5c60707141623s3f70e967s226e5da29965a173@mail.gmail.com>
David Frech wrote:
> I have a modest svn repo (about 800 commits) that contains fifteen or
> so small projects. It started life as a CVS repo, and as the projects
> grew and changed, and as I learned more about CVS, things got moved
> around. Later, when I got interested in svn (in 2005) I converted the
> repo, using cvs2svn. It got a few things wrong - mostly, that it
> thought there was one project in the repo, and created toplevel
> trunk/, branches/, and tags/ directories, and lumped everything below
> these.
I know this tangential to the main point of your post, but BTW
multiproject conversions were added to cvs2svn in release 1.5.
> It took a day and half to get the svn dump parsing right (it's an
> egregiously bad format) but only a couple of hours to write the
> fast-import backend.
I'm surprised you think that; I find the svn dump format quite easy and
straightforward. (Of course it assumes some Subversionisms, like easy
deep directory copies, which I can imagine would be annoying in other
contexts.) What don't you like about the format?
> Having done all this, I realized that this is a good way to go.
> Separating, as Michael suggests, the "parsing" part from the "commit
> generating" part, not only makes the tools easier to write, but makes
> them more flexible. If hg or bzr had a git-like fast-import (maybe
> they do) it would take me about 35 minutes to target that instead. And
> in the process I came across some "missing features" in fast-import,
> which Shawn Pearce was able to quickly add.
Yes, fast-import is a very easy-to-write format and looks to be very
well documented. I don't think that having to write output in
fast-import format would be any kind of a hindrance for such a tool.
Michael
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 11:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070715104858.GG2568@steel.home>
On 7/15/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Marco Costalba, Sun, Jul 15, 2007 12:06:53 +0200:
> >
> > Hope this clears any doubts regarding (supposed) slowness of Qt classes.
>
> No, it does not. Look at the implementation of memchr.
>
If this is the implementation you refer:
http://www.google.com/codesearch?hl=it&q=+lang:c+license:gpl+package:libc+memchr+show:6Tvt4_C8w_Q:Sdpf5XO0rrM:Emqlj8d07Ns&sa=N&cd=4&ct=rc&cs_p=http://ftp.gnu.org/gnu/glibc/glibc-2.2.1.tar.gz&cs_f=glibc-2.2.1/sysdeps/i386/bits/string.h#a0
I would say that I would prefer to avoid assemply and Qt libs seems to
do the same, perhaps for portability, but it's only a guess.
Anyway with the proposed patch to git you don't need assembly at all
(to me it's would seem an overkill)
Marco
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 10:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, git
In-Reply-To: <20070715104712.GF2568@steel.home>
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 12:47:12PM +0200, Alex Riesen <raa.lkml@gmail.com> pisal(a):
> to. Subprojects defined in such a loosely way are more flexible then
> having git-pull fetch subprojects by default. Sometimes I even want be
> _sure_ the subprojects are completely untouched (I have some critical
> parts in them).
Okay, but where can you overwrite that default? It would be nice to have
a config variable for this or something like that.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Alex Riesen @ 2007-07-15 10:48 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150306t3196f723ia3071ac301fb3f24@mail.gmail.com>
Marco Costalba, Sun, Jul 15, 2007 12:06:53 +0200:
>
> Hope this clears any doubts regarding (supposed) slowness of Qt classes.
No, it does not. Look at the implementation of memchr.
^ permalink raw reply
* Re: question about git-submodule
From: Alex Riesen @ 2007-07-15 10:47 UTC (permalink / raw)
To: skimo; +Cc: VMiklos, git
In-Reply-To: <20070715083959.GC999MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, Jul 15, 2007 10:39:59 +0200:
> On Fri, Jul 13, 2007 at 11:46:30PM +0200, VMiklos wrote:
> > i mean, first i thought that after configuring a submodule under libfoo,
> > then a git pull will update libfoo's repo under libfoo, too. or
> > something like that.
>
> Unless I've missed something, it doesn't.
> Some of use would like git to do just that (at least Alex Riesen,
> Martin Waitz and myself have sent in patches to that effect),
> but we haven't been able to convince Junio yet.
Count me out. Junio convinced me instead and having tried the
subprojects I find it really convenient: I can choose when and what
should be updated and I can see what _can_ be updated, iff I decide
to. Subprojects defined in such a loosely way are more flexible then
having git-pull fetch subprojects by default. Sometimes I even want be
_sure_ the subprojects are completely untouched (I have some critical
parts in them).
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 10:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070715093529.GD2568@steel.home>
On 7/15/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Marco Costalba, Sat, Jul 14, 2007 22:46:39 +0200:
> > Finding the delimiting '\0' it means to loop across the whole buffers
> > and _this_ is the expensive and not needed part. If just after the
>
> It is _not_ expensive. It could be made expensive, though. By using
> QString and QByteArray, for instance.
>
The searching we are talking about is this (Rev::indexData() in
git_startup.cpp):
int end = ba.indexOf('\0', idx); // this is the slowest find
the starting point 'idx' is at the beginning of the log message.
Qt implemantation of indexOf() is this (src/corelib/tools/qbytearray.cpp):
int QByteArray::indexOf(char ch, int from) const
{
if (from < 0)
from = qMax(from + d->size, 0);
if (from < d->size) {
const char *n = d->data + from - 1;
const char *e = d->data + d->size;
while (++n != e)
if (*n == ch)
return n - d->data;
}
return -1;
}
Hope this clears any doubts regarding (supposed) slowness of Qt classes.
> > first line would be possible to point to the beginning of the next
> > revision this seeking for '\0' would be not necessary anymore.
>
> But this will make your reading different: you have to handle the case
> when the next revision is not _fully_ read in yet, but you already
> know its size.
>
Reading and creating revision is made as a streaming, it means that
when there is new data from git a new Rev struct (well it's a class
indeed, but there's no diference) is created and populated with index
data: offset of the rev, parents number, offset of log message and so
on.
If, *while parsing the data* a truncated rev is found (we are at EOF
and no '\0' is found) the whole rev is discarded and deleted, we wait
for some more data and restart the process.
Because the above event is quite rare given the size of the buffers
where git row data is stored, no really loss of speed occurs and we
have the (big) advantage of indexing *while* searching for '\0', so to
scan data only once.
This is how it works now.
With the proposed patch will be easier to find a truncated rev,
because as soon as we know the rev size, after reading it from the
stream, we check:
if (revision_offset + size > byte_array_size)
truncated_rev;
>
> P.S. BTW, why do you have some 20 source files marked executable in
> your qgit4 repository?
>
Importing from Windows: ntfs does not handles file attributes
correctly, I should clean up permissions but I'm lazy ;-)
Marco
P.S: I have an experimental branch where the above is implemented, I
cannot publish now because it requires the --show-size change in git,
but after initial testing I have found that with the above applied the
overhead of qgit on git-log it's about of only 16%.
It means that if git-log runs in say 3 seconds (warm cache), qgit with
the same git log arguments runs in about 3.5 seconds.
With cold cache overhead is also less because disk access is accounted
on the git side ;-)
^ permalink raw reply
* Re: Confusing language in man page
From: Alex Riesen @ 2007-07-15 9:40 UTC (permalink / raw)
To: Satyam Sharma; +Cc: git
In-Reply-To: <a781481a0707141327k5b6f8f43sc6330ff8cc504dd1@mail.gmail.com>
Satyam Sharma, Sat, Jul 14, 2007 22:27:52 +0200:
> * On my system, doing:
>
> $ git diff
>
> with no outstanding changes in my current working tree produces some
> bogus newlines, throwing the prompt to the bottom of the xterm window.
> This sounds like weird / undesirable behaviour and I have a feeling must
> already be fixed in latest git (?)
It is not git. It is the program less which git uses. The problem is
known to the author of less.
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Alex Riesen @ 2007-07-15 9:35 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707141346q2eba4ab8ka1c85e8b5a2c1b1d@mail.gmail.com>
Marco Costalba, Sat, Jul 14, 2007 22:46:39 +0200:
> Finding the delimiting '\0' it means to loop across the whole buffers
> and _this_ is the expensive and not needed part. If just after the
It is _not_ expensive. It could be made expensive, though. By using
QString and QByteArray, for instance.
> first line would be possible to point to the beginning of the next
> revision this seeking for '\0' would be not necessary anymore.
But this will make your reading different: you have to handle the case
when the next revision is not _fully_ read in yet, but you already
know its size.
> Hope I have explained clearly enough, I have some problems writing in
> at late evening ;-)
P.S. BTW, why do you have some 20 source files marked executable in
your qgit4 repository?
^ permalink raw reply
* Re: Exporting a tree from a repository
From: Alex Riesen @ 2007-07-15 9:15 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Julian Phillips, Junio C Hamano, git
In-Reply-To: <8e04b5820707150012r13c5db69g96b97d910dc1b137@mail.gmail.com>
Ciprian Dorin Craciun, Sun, Jul 15, 2007 09:12:08 +0200:
> Now for the export thing... I know that I can just clone the
> remote repository and then remove the .git folder, but for my purpose
> I just want to have the HEAD tree downloaded, without any history...
> And by using git clone I end up downloading much more than I actually
> need.
Well, if you have a ssh access to remote repository, you can run
git-archive there:
$ ssh -n 'cd /dir/repo/.git && git --bare archive --prefix=<local-path> <tree>' |tar xf -
or even simplier:
$ git archive --remote=<remote-host:remote-path> --prefix=<local-path>/ <tree> |tar xf -
(for whatever reason it does not work with just git-daemon).
^ permalink raw reply
* [PATCH] Fix whitespace in "Format of STDIN stream" of fast-import
From: Alex Riesen @ 2007-07-15 8:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
Something probably assumed that HT indentation is 4 characters.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
fast-import.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 99a19d8..25877e8 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -11,7 +11,7 @@ Format of STDIN stream:
;
new_blob ::= 'blob' lf
- mark?
+ mark?
file_content;
file_content ::= data;
@@ -42,7 +42,7 @@ Format of STDIN stream:
new_tag ::= 'tag' sp tag_str lf
'from' sp (ref_str | hexsha1 | sha1exp_str | idnum) lf
- 'tagger' sp name '<' email '>' when lf
+ 'tagger' sp name '<' email '>' when lf
tag_msg;
tag_msg ::= data;
@@ -56,9 +56,9 @@ Format of STDIN stream:
# note: the first idnum in a stream should be 1 and subsequent
# idnums should not have gaps between values as this will cause
# the stream parser to reserve space for the gapped values. An
- # idnum can be updated in the future to a new object by issuing
+ # idnum can be updated in the future to a new object by issuing
# a new mark directive with the old idnum.
- #
+ #
mark ::= 'mark' sp idnum lf;
data ::= (delimited_data | exact_data)
lf;
@@ -68,7 +68,7 @@ Format of STDIN stream:
# delim.
delimited_data ::= 'data' sp '<<' delim lf
(data_line lf)*
- delim lf;
+ delim lf;
# note: declen indicates the length of binary_data in bytes.
# declen does not include the lf preceeding the binary data.
@@ -78,10 +78,10 @@ Format of STDIN stream:
# note: quoted strings are C-style quoting supporting \c for
# common escapes of 'c' (e..g \n, \t, \\, \") or \nnn where nnn
- # is the signed byte value in octal. Note that the only
+ # is the signed byte value in octal. Note that the only
# characters which must actually be escaped to protect the
# stream formatting is: \, " and LF. Otherwise these values
- # are UTF8.
+ # are UTF8.
#
ref_str ::= ref;
sha1exp_str ::= sha1exp;
@@ -104,9 +104,9 @@ Format of STDIN stream:
lf ::= # ASCII newline (LF) character;
# note: a colon (':') must precede the numerical value assigned to
- # an idnum. This is to distinguish it from a ref or tag name as
+ # an idnum. This is to distinguish it from a ref or tag name as
# GIT does not permit ':' in ref or tag strings.
- #
+ #
idnum ::= ':' bigint;
path ::= # GIT style file path, e.g. "a/b/c";
ref ::= # GIT ref name, e.g. "refs/heads/MOZ_GECKO_EXPERIMENT";
@@ -115,9 +115,9 @@ Format of STDIN stream:
hexsha1 ::= # SHA1 in hexadecimal format;
# note: name and email are UTF8 strings, however name must not
- # contain '<' or lf and email must not contain any of the
+ # contain '<' or lf and email must not contain any of the
# following: '<', '>', lf.
- #
+ #
name ::= # valid GIT author/committer name;
email ::= # valid GIT author/committer email;
ts ::= # time since the epoch in seconds, ascii base10 notation;
--
1.5.3.rc1.36.ga297
^ permalink raw reply related
* Re: Restoring files from old commits
From: Alex Riesen @ 2007-07-15 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nikodemus Siivola, martin f krafft
In-Reply-To: <7vbqeeizue.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Jul 14, 2007 20:50:49 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> >
> > It does not work for directories, though.
>
> Are you sure about that? I just did this in my git.git workspace:
>
> $ mv Documentation Documentation-
> $ git checkout HEAD Documentation/
> $ diff -r Documentation- Documentation
>
Missed it. Happy now :)
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 8:39 UTC (permalink / raw)
To: VMiklos; +Cc: git
In-Reply-To: <20070713214630.GB7106@genesis.frugalware.org>
On Fri, Jul 13, 2007 at 11:46:30PM +0200, VMiklos wrote:
> i mean, first i thought that after configuring a submodule under libfoo,
> then a git pull will update libfoo's repo under libfoo, too. or
> something like that.
Unless I've missed something, it doesn't.
Some of use would like git to do just that (at least Alex Riesen,
Martin Waitz and myself have sent in patches to that effect),
but we haven't been able to convince Junio yet.
skimo
^ permalink raw reply
* Re: [PATCH] lockfile.c: schedule remove_lock_file only once.
From: Sven Verdoolaege @ 2007-07-15 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabu0noxg.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 13, 2007 at 11:23:07AM -0700, Junio C Hamano wrote:
> The reason we do not use lk->next but instead check lk->on_list,
> and the reason why we do not remove the lock from the list, are
> described in 1084b845.
I'm afraid I'm still missing something:
1084b845 commit message:
We cannot remove the list element in commit_lock_file(); if we
are interrupted in the middle of list manipulation, the call to
remove_lock_file_on_signal() will happen with a broken list
structure pointed by lock_file_list, which would cause the cruft
to remain, so not removing the list element is the right thing
to do. Instead we should be reusing the element already on the
list.
We have a list
list--->A--->B--->C
and we overwrite one next pointer to remove an element, say B
list--->A-------->C
At what point is the list structure broken?
If you are worried that the interrupt could happen in the middle
of writing the pointer (could it?), then shouldn't you worry
about adding elements too?
skimo
^ permalink raw reply
* Re: Exporting a tree from a repository
From: martin f krafft @ 2007-07-15 7:17 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: git
In-Reply-To: <8e04b5820707141325o400e170bu9eb80b304cae506b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 674 bytes --]
also sprach Ciprian Dorin Craciun <ciprian.craciun@gmail.com> [2007.07.14.2225 +0200]:
> Now I know that I can use "git archive | tar -x"... I am looking
> for the same functionality but without the intermediary file... Maybe
> something like "git archive --format=tree <branch>"...
There is no intermediary file.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"when I was a boy I was told
that anybody could become president.
now i'm beginning to believe it."
-- clarence darrow
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Exporting a tree from a repository
From: Ciprian Dorin Craciun @ 2007-07-15 7:12 UTC (permalink / raw)
To: Julian Phillips, Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707142237190.13310@beast.quantumfyre.co.uk>
On 7/15/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Sat, 14 Jul 2007, Ciprian Dorin Craciun wrote:
>
> > Hello all!
> >
> > I am a new GIT user, I like it, so I started playing with it for
> > different projects I work on.
> >
> > Currently I am playing with "Linux from Scratch", and I have
> > written some scripts to automatize the build process -- kind of
> > install scripts...
> >
> > For this I use GIT to store all the source packages -- each inside
> > it's own branch :).
> >
> > My question is the following: How can I export an entire tree
> > without using a working directory, or cloning the repository. (Because
> > from what I have seen so far there is no way to use the same
> > repository with many working directories...)
>
> You can have as many working directories as you want from one repository
> using the git-new-workdir script from contrib/workdir. You do need to be
> careful when updating references though (you basically want to avoid
> updating a reference that you are using in another working directory).
>
> You should also be able to use this to get an "export" - simply create the
> new workdir and then remove the .git (being careful not to accidentally do
> this in your actual repository). However I expect there is a better way
> to do this ...
>
> --
> Julian
>
> ---
> Quark! Quark! Beware the quantum duck!
Thank you for the hint about git-new-workdir! I will try it.
Now for the export thing... I know that I can just clone the
remote repository and then remove the .git folder, but for my purpose
I just want to have the HEAD tree downloaded, without any history...
And by using git clone I end up downloading much more than I actually
need.
I am looking for a feature like 'svn export <repo+tree_path>
<destination_path>'...
Ciprian.
^ permalink raw reply
* Re: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Junio C Hamano @ 2007-07-15 6:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Simon Hausmann, Alex Riesen, Marius Storm-Olsen, git
In-Reply-To: <20070715024928.GY4436@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Thanks. Marius' patch was whitespace damaged in the context lines,
> but it was easily repaired. I've got a couple of other small items
> in my fastimport repository that I'm going to ask Junio to include
> in 1.5.3 shortly.
Thanks for taking care of this. I have pulled gfi master into
'master'. Perhaps we would want to tag -rc2 this weekend, run
with it for a week or so and see if we need -rc3 before the
final.
^ permalink raw reply
* Re: Mistake in manpage for git-commit-tree?
From: Junio C Hamano @ 2007-07-15 6:12 UTC (permalink / raw)
To: Geoff Richards; +Cc: git
In-Reply-To: <20070714224752.GD9011@ungwe.org>
Thanks.
^ permalink raw reply
* Re: Exporting a tree from a repository
From: Junio C Hamano @ 2007-07-15 6:12 UTC (permalink / raw)
To: Julian Phillips; +Cc: Ciprian Dorin Craciun, git
In-Reply-To: <Pine.LNX.4.64.0707142237190.13310@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> You should also be able to use this to get an "export" - simply create
> the new workdir and then remove the .git (being careful not to
> accidentally do this in your actual repository). However I expect
> there is a better way to do this ...
You meant "git-archive" perhaps.
^ permalink raw reply
* Re: [PATCH] Make every builtin-*.c file #include "builtin.h"
From: Junio C Hamano @ 2007-07-15 6:12 UTC (permalink / raw)
To: Peter Hagervall; +Cc: git
In-Reply-To: <20070714231445.GA21180@scanner.cs.umu.se>
Makes sense, thanks.
^ permalink raw reply
* [PATCH] Teach fast-import to recursively copy files/directories
From: Shawn O. Pearce @ 2007-07-15 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some source material (e.g. Subversion dump files) perform directory
renames by telling us the directory was copied, then deleted in the
same revision. This makes it difficult for a frontend to convert
such data formats to a fast-import stream, as all the frontend has
on hand is "Copy a/ to b/; Delete a/" with no details about what
files are in a/, unless the frontend also kept track of all files.
The new 'C' subcommand within a commit allows the frontend to make a
recursive copy of one path to another path within the branch, without
needing to keep track of the individual file paths. The metadata
copy is performed in memory efficiently, but is implemented as a
copy-immediately operation, rather than copy-on-write.
With this new 'C' subcommand frontends could obviously implement an
'R' (rename) on their own as a combination of 'C' and 'D' (delete),
but since we have already offered up 'R' in the past and it is a
trivial thing to keep implemented I'm not going to deprecate it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This and the following changes since commit 9d6f220cc8ffbd71b4c68765b52c3a7c41dd729b:
Josh Triplett (1):
Remove useless uses of cat, and replace with filename arguments
are available in the git repository at:
repo.or.cz:/srv/git/git/fastimport.git master
Marius Storm-Olsen (1):
Fix git-p4 on Windows to not use the Posix sysconf function.
Shawn O. Pearce (2):
Correct trivial typo in fast-import documentation
Teach fast-import to recursively copy files/directories
Documentation/git-fast-import.txt | 40 +++++++++++++++--
contrib/fast-import/git-p4 | 6 ++-
fast-import.c | 81 ++++++++++++++++++++++++++++++++++--
t/t9300-fast-import.sh | 83 +++++++++++++++++++++++++++++++++++++
4 files changed, 200 insertions(+), 10 deletions(-)
Hopefully this stuff will make it into 1.5.3 final. This should
be the last fastimport update before then.
--
Documentation/git-fast-import.txt | 40 +++++++++++++++--
fast-import.c | 81 ++++++++++++++++++++++++++++++++++--
t/t9300-fast-import.sh | 83 +++++++++++++++++++++++++++++++++++++
3 files changed, 195 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index bf1ba67..30ee98d 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -302,7 +302,7 @@ change to the project.
data
('from' SP <committish> LF)?
('merge' SP <committish> LF)?
- (filemodify | filedelete | filerename | filedeleteall)*
+ (filemodify | filedelete | filecopy | filerename | filedeleteall)*
LF
....
@@ -325,13 +325,13 @@ commit message use a 0 length data. Commit messages are free-form
and are not interpreted by Git. Currently they must be encoded in
UTF-8, as fast-import does not permit other encodings to be specified.
-Zero or more `filemodify`, `filedelete`, `filerename` and
-`filedeleteall` commands
+Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`
+and `filedeleteall` commands
may be included to update the contents of the branch prior to
creating the commit. These commands may be supplied in any order.
However it is recommended that a `filedeleteall` command preceed
-all `filemodify` and `filerename` commands in the same commit, as
-`filedeleteall`
+all `filemodify`, `filecopy` and `filerename` commands in the same
+commit, as `filedeleteall`
wipes the branch clean (see below).
`author`
@@ -497,6 +497,27 @@ here `<path>` is the complete path of the file or subdirectory to
be removed from the branch.
See `filemodify` above for a detailed description of `<path>`.
+`filecopy`
+^^^^^^^^^^^^
+Recursively copies an existing file or subdirectory to a different
+location within the branch. The existing file or directory must
+exist. If the destination exists it will be completely replaced
+by the content copied from the source.
+
+....
+ 'C' SP <path> SP <path> LF
+....
+
+here the first `<path>` is the source location and the second
+`<path>` is the destination. See `filemodify` above for a detailed
+description of what `<path>` may look like. To use a source path
+that contains SP the path must be quoted.
+
+A `filecopy` command takes effect immediately. Once the source
+location has been copied to the destination any future commands
+applied to the source location will not impact the destination of
+the copy.
+
`filerename`
^^^^^^^^^^^^
Renames an existing file or subdirectory to a different location
@@ -517,6 +538,15 @@ location has been renamed to the destination any future commands
applied to the source location will create new files there and not
impact the destination of the rename.
+Note that a `filerename` is the same as a `filecopy` followed by a
+`filedelete` of the source location. There is a slight performance
+advantage to using `filerename`, but the advantage is so small
+that it is never worth trying to convert a delete/add pair in
+source material into a rename for fast-import. This `filerename`
+command is provided just to simplify frontends that already have
+rename information and don't want bother with decomposing it into a
+`filecopy` followed by a `filedelete`.
+
`filedeleteall`
^^^^^^^^^^^^^^^
Included in a `commit` command to remove all files (and also all
diff --git a/fast-import.c b/fast-import.c
index a1cb13f..99a19d8 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -26,10 +26,16 @@ Format of STDIN stream:
lf;
commit_msg ::= data;
- file_change ::= file_clr | file_del | file_rnm | file_obm | file_inm;
+ file_change ::= file_clr
+ | file_del
+ | file_rnm
+ | file_cpy
+ | file_obm
+ | file_inm;
file_clr ::= 'deleteall' lf;
file_del ::= 'D' sp path_str lf;
file_rnm ::= 'R' sp path_str sp path_str lf;
+ file_cpy ::= 'C' sp path_str sp path_str lf;
file_obm ::= 'M' sp mode sp (hexsha1 | idnum) sp path_str lf;
file_inm ::= 'M' sp mode sp 'inline' sp path_str lf
data;
@@ -623,6 +629,31 @@ static void release_tree_entry(struct tree_entry *e)
avail_tree_entry = e;
}
+static struct tree_content *dup_tree_content(struct tree_content *s)
+{
+ struct tree_content *d;
+ struct tree_entry *a, *b;
+ unsigned int i;
+
+ if (!s)
+ return NULL;
+ d = new_tree_content(s->entry_count);
+ for (i = 0; i < s->entry_count; i++) {
+ a = s->entries[i];
+ b = new_tree_entry();
+ memcpy(b, a, sizeof(*a));
+ if (a->tree && is_null_sha1(b->versions[1].sha1))
+ b->tree = dup_tree_content(a->tree);
+ else
+ b->tree = NULL;
+ d->entries[i] = b;
+ }
+ d->entry_count = s->entry_count;
+ d->delta_depth = s->delta_depth;
+
+ return d;
+}
+
static void start_packfile(void)
{
static char tmpfile[PATH_MAX];
@@ -1273,6 +1304,43 @@ del_entry:
return 1;
}
+static int tree_content_get(
+ struct tree_entry *root,
+ const char *p,
+ struct tree_entry *leaf)
+{
+ struct tree_content *t = root->tree;
+ const char *slash1;
+ unsigned int i, n;
+ struct tree_entry *e;
+
+ slash1 = strchr(p, '/');
+ if (slash1)
+ n = slash1 - p;
+ else
+ n = strlen(p);
+
+ for (i = 0; i < t->entry_count; i++) {
+ e = t->entries[i];
+ if (e->name->str_len == n && !strncmp(p, e->name->str_dat, n)) {
+ if (!slash1) {
+ memcpy(leaf, e, sizeof(*leaf));
+ if (e->tree && is_null_sha1(e->versions[1].sha1))
+ leaf->tree = dup_tree_content(e->tree);
+ else
+ leaf->tree = NULL;
+ return 1;
+ }
+ if (!S_ISDIR(e->versions[1].mode))
+ return 0;
+ if (!e->tree)
+ load_tree(e);
+ return tree_content_get(e, slash1 + 1, leaf);
+ }
+ }
+ return 0;
+}
+
static int update_branch(struct branch *b)
{
static const char *msg = "fast-import";
@@ -1658,7 +1726,7 @@ static void file_change_d(struct branch *b)
free(p_uq);
}
-static void file_change_r(struct branch *b)
+static void file_change_cr(struct branch *b, int rename)
{
const char *s, *d;
char *s_uq, *d_uq;
@@ -1694,7 +1762,10 @@ static void file_change_r(struct branch *b)
}
memset(&leaf, 0, sizeof(leaf));
- tree_content_remove(&b->branch_tree, s, &leaf);
+ if (rename)
+ tree_content_remove(&b->branch_tree, s, &leaf);
+ else
+ tree_content_get(&b->branch_tree, s, &leaf);
if (!leaf.versions[1].mode)
die("Path %s not in branch", s);
tree_content_set(&b->branch_tree, d,
@@ -1874,7 +1945,9 @@ static void cmd_new_commit(void)
else if (!prefixcmp(command_buf.buf, "D "))
file_change_d(b);
else if (!prefixcmp(command_buf.buf, "R "))
- file_change_r(b);
+ file_change_cr(b, 1);
+ else if (!prefixcmp(command_buf.buf, "C "))
+ file_change_cr(b, 0);
else if (!strcmp("deleteall", command_buf.buf))
file_change_deleteall(b);
else
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index bf3720d..4b920be 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -648,4 +648,87 @@ test_expect_success \
git diff-tree -M -r M3^ M3 >actual &&
compare_diff_raw expect actual'
+###
+### series N
+###
+
+test_tick
+cat >input <<INPUT_END
+commit refs/heads/N1
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+file copy
+COMMIT
+
+from refs/heads/branch^0
+C file2/newf file2/n.e.w.f
+
+INPUT_END
+
+cat >expect <<EOF
+:100755 100755 f1fb5da718392694d0076d677d6d0e364c79b0bc f1fb5da718392694d0076d677d6d0e364c79b0bc C100 file2/newf file2/n.e.w.f
+EOF
+test_expect_success \
+ 'N: copy file in same subdirectory' \
+ 'git-fast-import <input &&
+ git diff-tree -C --find-copies-harder -r N1^ N1 >actual &&
+ compare_diff_raw expect actual'
+
+cat >input <<INPUT_END
+commit refs/heads/N2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+clean directory copy
+COMMIT
+
+from refs/heads/branch^0
+C file2 file3
+
+commit refs/heads/N2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+modify directory copy
+COMMIT
+
+M 644 inline file3/file5
+data <<EOF
+$file5_data
+EOF
+
+INPUT_END
+
+cat >expect <<EOF
+:100644 100644 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 C100 newdir/interesting file3/file5
+:100755 100755 f1fb5da718392694d0076d677d6d0e364c79b0bc f1fb5da718392694d0076d677d6d0e364c79b0bc C100 file2/newf file3/newf
+:100644 100644 7123f7f44e39be127c5eb701e5968176ee9d78b1 7123f7f44e39be127c5eb701e5968176ee9d78b1 C100 file2/oldf file3/oldf
+EOF
+test_expect_success \
+ 'N: copy then modify subdirectory' \
+ 'git-fast-import <input &&
+ git diff-tree -C --find-copies-harder -r N2^^ N2 >actual &&
+ compare_diff_raw expect actual'
+
+cat >input <<INPUT_END
+commit refs/heads/N3
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+dirty directory copy
+COMMIT
+
+from refs/heads/branch^0
+M 644 inline file2/file5
+data <<EOF
+$file5_data
+EOF
+
+C file2 file3
+D file2/file5
+
+INPUT_END
+
+test_expect_success \
+ 'N: copy dirty subdirectory' \
+ 'git-fast-import <input &&
+ test `git-rev-parse N2^{tree}` = `git-rev-parse N3^{tree}`'
+
test_done
--
1.5.3.rc0.900.ge7568
^ permalink raw reply related
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