* 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: CVS -> SVN -> Git
From: Eric S. Raymond @ 2007-07-15 13:36 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <469A0D54.8010303@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> 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!
OK, that's a fair point. I might have known the showstopper would be
somewhere near Subversion's tags-are-directories assumption. And this
also neatly explains why I didn't see any problems or poor performance
during my recent conversions; the projects I was lifting had no tags.
> 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.
Or...wait for it...the generator for the serialized format could be one
of the back ends! Probably a good idea to have for debugging reasons,
if nothing else.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: question about git-submodule
From: Alex Riesen @ 2007-07-15 13:42 UTC (permalink / raw)
To: skimo; +Cc: VMiklos, git
In-Reply-To: <20070715115148.GD999MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, Jul 15, 2007 13:51:48 +0200:
> 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.
I found I do _not_ need to do it every time I switch to a different
commit.
> Did you change your mind about this part too?
Yep. I have less to transfer (and in fact, the subproject I mentioned
is kind of heavy and has a lot of binary stuff in it).
> > 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.)
Haven't noticed this yet. Merge ignores subprojects. What do you mean?
^ permalink raw reply
* Re: question about git-submodule
From: Alex Riesen @ 2007-07-15 13:50 UTC (permalink / raw)
To: VMiklos; +Cc: skimo, git
In-Reply-To: <20070715105450.GD7106@genesis.frugalware.org>
VMiklos, Sun, Jul 15, 2007 12:54:50 +0200:
> 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.
It is not a default in a sense where it control the behaviour of a git
command. git pull just does not do anything to subprojects and you use
a separate command (git-submodule update, I believe) to update them.
That said, I never used the git-submodule, nor did I have an urge to.
As I said, I find it convenient enough as it is with git-add and
git-diff, checking out the subproject as needed. Have to be careful
about "git commit -a" (which I almost never use anyway) and haven't
had conflicts yet.
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 13:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: VMiklos, git
In-Reply-To: <20070715134212.GH2568@steel.home>
On Sun, Jul 15, 2007 at 03:42:12PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, Jul 15, 2007 13:51:48 +0200:
> > 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.
>
> I found I do _not_ need to do it every time I switch to a different
> commit.
Ok. Then I guess we have different needs and I should only
do it if some config option is set if I ever try to resend
the patch.
> > The update in the superproject would fail if the subproject is dirty
> > (just as with files.)
>
> Haven't noticed this yet. Merge ignores subprojects. What do you mean?
>
I mean that if such a feature would be implemented, then it wouldn't
go ahead with the update if some of the subprojects couldn't be updated.
skimo
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 13:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, git
In-Reply-To: <20070715135057.GI2568@steel.home>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 03:50:57PM +0200, Alex Riesen <raa.lkml@gmail.com> pisal(a):
> It is not a default in a sense where it control the behaviour of a git
> command. git pull just does not do anything to subprojects and you use
> a separate command (git-submodule update, I believe) to update them.
>
> That said, I never used the git-submodule, nor did I have an urge to.
that's what i asked originally :) i believed that one is supposed to use
git-submodule update to pull each submodule, but it does not seems to
do so. my question is still about if it is possible to pull each
submodule using a single command
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] translate bad characters in refnames during git-svn fetch
From: martin f krafft @ 2007-07-15 13:05 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]
Hi,
I am trying to track/convert the Debian pkg-mdadm repository with
git-svn:
svn://svn.debian.org/svn/pkg-mdadm/mdadm/trunk
My problem is that the fetching fails:
fatal: refs/remotes/tags/2.6.1-1~exp.1: cannot lock the ref
update-ref -m r311 refs/remotes/tags/2.6.1-1~exp.1
c6e351ea25dc90714048e33693099595c2d5dab8: command returned error:
128
This is because the ~ character is an invalid character for
a refname (it's used to specify the nth parent).
So I figured that the best way to deal with this is to introduce
a conversion filter to git-svn, but I cannot figure out where it has
to go. My perl is rusty and even after an hour now with the code,
I could not find the right spot.
The following patch works, but I can't really explain why. Moreover,
it does not change the STDERR output, so you'll still get stuff like
r340 = 0dc5693471af9dfdb712c1342071ba1040af8963
(tags/2.6.1-1~exp.3)
which makes me think that it's translating the refname too late.
However, the end result looks sane.
Comments welcome,
m
---
git-check-ref-format(1) documents which characters may be contained in
a refname. Since Subversion has different rules, an import can result in
problems, such as:
fatal: refs/remotes/tags/2.6.1-1~exp.1: cannot lock the ref
update-ref -m r311 refs/remotes/tags/2.6.1-1~exp.1
c6e351ea25dc90714048e33693099595c2d5dab8: command returned error: 128
This patch translates bad characters to valid substitutes to enable imports of
tags/branches/whatever using characters that git does not allow in refnames.
Signed-off-by: martin f. krafft <madduck@piper.oerlikon.madduck.net>
---
git-svn.perl | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 299b40f..de43697 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1239,7 +1239,29 @@ sub new {
$self;
}
-sub refname { "refs/remotes/$_[0]->{ref_id}" }
+sub refname {
+ my ($refname) = $_[0]->{ref_id};
+ ## transform the refname as per rules in git-check-ref-format(1):
+ # no slash-separated omponent can begin with a dot .
+ # /.* becomes /,*
+ $refname =~ s|/\.|/,|g;
+ # It cannot have two consecutive dots .. anywhere
+ # .. becomes ,,
+ $refname =~ s|\.\.|,,|g;
+ # It cannot have ASCII control character space, tilde ~, caret ^,
+ # colon :, question-mark ?, asterisk *, or open bracket[ anywhere
+ # <space> becomes _
+ # ~ becomes =
+ # ^ becomes @
+ # : becomes %
+ # ? becomes $
+ # * becomes +
+ # [ becomes (
+ $refname =~ y| ~^:?*[|_=@%\$+(|;
+ # It cannot end with a slash /
+ $refname =~ s|/$||g;
+ "refs/remotes/$refname";
+}
sub svm_uuid {
my ($self) = @_;
--
1.5.3.rc1.27.ga5e40
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"a warm bed in a house sounds a mite better
than eating a hot dog on a stick
with an old geezer traveling on a lawn mower."
-- alvin straight (the straight story)
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 14:02 UTC (permalink / raw)
To: VMiklos; +Cc: Alex Riesen, git
In-Reply-To: <20070715135453.GE7106@genesis.frugalware.org>
On Sun, Jul 15, 2007 at 03:54:53PM +0200, VMiklos wrote:
> that's what i asked originally :) i believed that one is supposed to use
> git-submodule update to pull each submodule, but it does not seems to
> do so. my question is still about if it is possible to pull each
> submodule using a single command
Maybe you should explain in a bit more detail what you are trying
to do.
skimo
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-15 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v7ip2hjna.fsf@assigned-by-dhcp.cox.net>
On Sat, Jul 14, 2007 at 12:26:01PM -0700, Junio C Hamano wrote:
> But this leads to more fundamental issues. It is not obvious
> from the description what environment rewrite-commits runs in.
I'll try to make that more clear in the next round.
> >> +To move the whole tree into a subdirectory, or remove it from there:
> >> +
> >> +---------------------------------------------------------------
> >> +git rewrite-commits --index-filter \
> >> + 'git ls-files -s | sed "s-\t-&newsubdir/-" |
> >> + GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> >> + git update-index --index-info &&
> >> + mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE'
> >> +---------------------------------------------------------------
>
> I see only one operation in the example, and "or remove it from
> there" confuses the reader.
I found it confusing too (I copied it from the filter-branch manual).
I'll remove it.
skimo
^ permalink raw reply
* Questions about git-fast-import for cvs2svn
From: Michael Haggerty @ 2007-07-15 14:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
I've been reading the documentation for git-fast-import (thanks for the
fine documentation!) as part of determining how much work it would be to
add a git back end to cvs2svn, and I have a few questions.
1. Is it a problem to create blobs that are never referenced? The
easiest point to create blobs is when the RCS files are originally
parsed, but later we discard some CVS revisions, meaning that the
corresponding blobs would never be needed. Would this be a problem?
2. It appears that author/committer require an email address. How
important is a valid email address here?
a. CVS commits include a username but not an email address. If an
email address is really required, then I suppose the person doing the
conversion would have to supply a lookup table mapping username -> email
address.
b. CVS tag/branch creation events do not even include a username.
Any suggestions for what to use here?
3. I expect we should set 'committer' to the value determined from CVS
and leave 'author' unused. But I suppose another possibility would be
to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS
author. Which one makes sense?
4. It appears that a commit can only have a single 'from', which I
suppose means that files can only be added to one branch from a single
source branch/revision in a single commit. But CVS branches and tags
can include files from multiple source branches and/or revisions. What
would be the most git-like way to handle this situation? Should the
branch be created in one commit, then have files from other sources
added to it in other commits? Or should (is this even possible?) all
files be added to the branch in a single commit, using multiple "merge"
sources?
5. Is there any significance at all to the order that commits are output
to git-fast-import? Obviously, blobs have to be defined before they are
used, and '<committish>'s have to be defined before they are referenced.
But is there any other significance to the order of commits?
All in all, I don't think that a git back end for cvs2svn would be very
trick at all. There will be a bit of refactoring work to allow the user
to switch between SVN/git output at runtime, but so far I don't see any
reason that the fundamental algorithms of cvs2svn will have to be changed.
Thanks,
Michael
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 14:26 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070715140244.GF999MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 04:02:44PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> On Sun, Jul 15, 2007 at 03:54:53PM +0200, VMiklos wrote:
> > that's what i asked originally :) i believed that one is supposed to use
> > git-submodule update to pull each submodule, but it does not seems to
> > do so. my question is still about if it is possible to pull each
> > submodule using a single command
>
> Maybe you should explain in a bit more detail what you are trying
> to do.
ok :) so i have a repo and i add a submodule in the libfoo dir. when i
add it, git will clone the repo, that's fine. it would be nice to have a
command (i thought git submodule update would do it for me) which would
pull in the repo _and_ would pull in the libfoo dir, too
currently if you have 10 submodules, you need to updated each of them
manually, and having a feature to all of them at once would be nice (of
course it's fine if this is not the default when using git pull in the
"main" repo)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-15 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0707141140510.14781@racer.site>
On Sat, Jul 14, 2007 at 01:49:59PM +0100, Johannes Schindelin wrote:
> On Thu, 12 Jul 2007, skimo@liacs.nl wrote:
> > +#include "grep.h"
>
> I did not compile test, but do you really need that?
Not anymore.
> > +struct decoration rewrite_decoration = { "rewritten as" };
> > [...]
> > +
> > +struct rewrite_decoration {
> > + struct rewrite_decoration *next;
> > + unsigned char sha1[20];
> > +};
>
> I wonder why you give the instance of a "struct decoration" the same name
> as that of a _different_ struct. IOW it is confusing that there is a
> "struct rewrite_decoration", but the variable "rewrite_decoration" is no
> instance of that struct.
I was just following Linus's example.
> > +static char *add_parents(char *dest, struct commit_list *parents)
>
> Since one commit can be rewritten to multiple commits now, you do not know
> how much space you need to add the parents.
I count them beforehand.
> > + !get_short_sha1(buf, ll, sha1, 1) &&
> > + !get_rewritten_sha1(sha1))
> > + memcpy(dest, sha1_to_hex(sha1), ll);
> > + else
> > + memcpy(dest, buf, ll);
>
> What do you do if the rewritten sha1, truncated to ll characters, is
> ambiguous? Wouldn't you need more than
More than what?
Are you saying I should add some more of it then?
(As you can see, I simply don't consider that case here, so right now
I just leave it possibly ambiguous.)
> > + if (!prefixcmp(ref+5, original_prefix))
>
> Should original_prefix not be "refs/original", then?
The idea was that we could add a command line option later
to override it.
> > +static int is_pruned(struct commit *commit, int path_pruning)
> > +{
> > + if (commit->object.flags & PRUNED)
> > + return 1;
>
> Hmm. I thought about changing get_revision_1() to mark that commit as
> uninteresting, since the parents were already added. But I guess this has
> too much side effect potential.
>
> In any case, I think that "NO_MATCH" would be a more descriptive name.
Right now, it's only set for matching stuff, but it could be set
for other kinds of pruning too.
> > + if (path_pruning &&
> > + !(commit->object.flags & (TREECHANGE | UNINTERESTING)))
> > + return 1;
>
> Why only with "path_pruning"? Ah yes. Because otherwise, you would
> assume "A" in "A..B" to be pruned.
TREECHANGE is only set when path pruning is in effect.
If I didn't check for path_pruning, then all commits would be
considered to have been pruned. (Or am I missing something?
Honestyl, I found all that TREECHANGE stuff difficult to follow.)
revision.c itself is also riddled with "prune_fn && ".
Wouldn't it make sense to invert the meaning of this bit and call
it, say, PRUNED, so that the default is off and you would only
have to check if the bit was set ?
> I wonder why you bother at all: my impression was that the revisions you
> want to filter out here were already filtered out by
> revision.c:rewrite_parents()...
I also want to make reference that pointed to something that has
been pruned (in either way) to now point to something in the new
history.
> > +static void rewrite_sha1(struct object *obj, unsigned char *new_sha1)
> > +{
> > + if (!hashcmp(obj->sha1, new_sha1))
> > + return;
> > +
> > + add_rewrite_decoration(obj, new_sha1);
>
> This is not so much "rewrite_sha1", as "append_rewritten_sha1", right?
Well, it's only called once on each commit.
> > + get_rewritten_sha1(sha1);
> > + if (!is_null_sha1(sha1)) {
> > + hashclr(sha1);
> > + rewrite_sha1(&list->item->object, sha1);
>
> I guess you'll admit that it is unintuitive to read
> "get_rewritten_sha1(sha1); rewrite_sha1(o, sha1);". I thought: "What?
> Again?" IMHO that is a strong hint that "rewrite_sha1" is not an apt name
> for that function.
I guess our brains work in a slightly different way.
> Hmm. When looking at that code, I wonder if
>
> git rewrite-commits A..B
>
> will rewrite C, too, if it happens to lie in A..B. That would be not
> brilliant.
That was the idea. Why is it not brilliant?
What would you like this to do instead?
Assume that in your new history all the commit that used to be pointed
to have been removed. If these pointers are left to point to the
old history, then how are you going to get at the new history?
> > + commit = lookup_commit_reference(sha1);
> > + pruned = is_pruned(commit, !!cb_data);
> > +
> > + hashcpy(new_sha1, sha1);
> > + if (!pruned && get_rewritten_sha1(new_sha1))
> > + return 0;
>
> So if pruned == 1, you _do_ rewrite it? I'm not quite sure. Care to
> explain?
Yes. See above.
> > + cmd.in = open(commit_path, O_RDONLY);
> > + if (cmd.in < 0)
> > + die("Unable to read commit from file '%s'", commit_path);
> > + unlink(commit_path);
>
> This will fail on Windows. You do not catch that error, so it is almost
> fine: just put the file into rewrite_dir, so the leftovers will be removed
> later anyway.
You mean unlinking an opened file?
>
> > + hashclr(sha1);
> > + commit->object.flags |= PRUNED;
> > + /*
> > + * If the filter returns two or more commits,
> > + * we consider the original commit to have been
> > + * removed and put the list in the old commit's
> > + * parent list so that all the old commit's children
> > + * will copy them.
> > + */
> > + if (list) {
> > + free_commit_list(commit->parents);
> > + commit->parents = list;
> > + } else
> > + add_sha1_map(commit->object.sha1, NULL);
>
> That is almost certainly wrong.
What specifically ?
> If you step away from the notion that
> get_rewritten_sha1() returns _one_ SHA-1, all will become clearer. And
> the filters should know about them SHA-1s, too.
The filters do know about them. The corresponding map file contains
all the new SHA1s.
> > + add_sha1_map(commit->object.sha1, sha1);
> > + } else
> > + filter_and_write_commit(buf, p-buf, commit, sha1);
> > + free(buf);
>
> You can really discard the commit->buffer, too, no?
I'm not familiar enough with the internals to say for sure.
> > +static void setup_temp_dir()
> > +{
> > + int aux;
> > +
> > + absolute_git_dir = create_absolute_path(get_git_dir());
> > + setenv(GIT_DIR_ENVIRONMENT, absolute_git_dir, 1);
> > +
> > + if (!rewrite_dir) {
> > + rewrite_dir = xstrdup(git_path("rewrite"));
>
> I might read the code wrong, but this does not guarantee that rewrite_dir
> is an absolute path, right?
It doesn't right now.
> > + if (mkdir(mkpath("%s/map", rewrite_dir), 0777))
> > + die("unable to create map directory '%s/map'", rewrite_dir);
>
> Maybe make this dependent on --write-sha1-mappings, and have a check in
> "map ()"?
I'll leave that to you :-)
> > + while ((commit = get_revision(&rev)) != NULL) {
> > + rewrite_commit(commit, !!rev.prune_fn);
> > + }
>
> Please lose the curly brackets for single lines; otherwise it would look
> too perl like.
That would be
rewrite_commit($commit) while $commit = get_revision;
> > + rm_rf(git_path("refs/%s", original_prefix));
>
> Would it not be better to move refs/original to refs/original/original?
Is that what you want?
You'd end up with refs/original/original/original/original/original/original/original/
pretty quickly.
skimo
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 14:48 UTC (permalink / raw)
To: VMiklos; +Cc: Alex Riesen, git
In-Reply-To: <20070715142624.GF7106@genesis.frugalware.org>
On Sun, Jul 15, 2007 at 04:26:24PM +0200, VMiklos wrote:
> currently if you have 10 submodules, you need to updated each of them
> manually, and having a feature to all of them at once would be nice (of
> course it's fine if this is not the default when using git pull in the
> "main" repo)
Isn't that what "git submodule update" does ?
skimo
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 14:58 UTC (permalink / raw)
To: Sean; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <20070715083529.6855a858.seanlkml@sympatico.ca>
On 7/15/07, Sean <seanlkml@sympatico.ca> wrote:
>
> 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.
>
revisions are streamed, there is only one first revision, all the
others are linked togheter in a big stream.
Actually I ended up looking for the character after the '\0' (if any)
to be 'c' that is the beginning of "commit <sha> ....." but it's a bit
hacky.
Marco
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 15:05 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070715144835.GI999MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 04:48:35PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> Isn't that what "git submodule update" does ?
i can't get it to work, but here is a log:
http://frugalware.org/~vmiklos/logs/git-submodule.log
at the end of it, git submodule update does not pull anything, while
there are changes both in the main and in the libfoo repo, too
have i missed something?
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: Sean @ 2007-07-15 15:04 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150758h7a9e893frb068d4a9508bc3b2@mail.gmail.com>
On Sun, 15 Jul 2007 16:58:16 +0200
"Marco Costalba" <mcostalba@gmail.com> wrote:
> On 7/15/07, Sean <seanlkml@sympatico.ca> wrote:
> >
> > 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.
> >
> revisions are streamed, there is only one first revision, all the
> others are linked togheter in a big stream.
Right, but how does that alter the notion that ^\0 is the safe way to
test for the "real" NUL terminator?
> Actually I ended up looking for the character after the '\0' (if any)
> to be 'c' that is the beginning of "commit <sha> ....." but it's a bit
> hacky.
Much more hacky than just testing for ^\0. AFAIU, the NUL is
guaranteed to come at the start of the line and _all_ other NUL
characters are guaranteed to appear somewhere else. Your current
test will fail if a "c" happens to follow NUL in the patch text.
Sean
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 15:21 UTC (permalink / raw)
To: VMiklos; +Cc: Alex Riesen, git
In-Reply-To: <20070715150540.GH7106@genesis.frugalware.org>
On Sun, Jul 15, 2007 at 05:05:40PM +0200, VMiklos wrote:
> Hello,
>
> Na Sun, Jul 15, 2007 at 04:48:35PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> > Isn't that what "git submodule update" does ?
>
> i can't get it to work, but here is a log:
>
> vmiklos@vmobile:~/git/test$ ls
> vmiklos@vmobile:~/git/test$ mkdir server
> vmiklos@vmobile:~/git/test$ cd server
> vmiklos@vmobile:~/git/test/server$ mkdir main
> vmiklos@vmobile:~/git/test/server$ cd main
> vmiklos@vmobile:~/git/test/server/main$ git init
> Initialized empty Git repository in .git/
> vmiklos@vmobile:~/git/test/server/main$ echo "foo" > main.c
> vmiklos@vmobile:~/git/test/server/main$ git add main.c
> vmiklos@vmobile:~/git/test/server/main$ git commit -m "import main"
> Created initial commit 1ceae8f: import main
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 main.c
> vmiklos@vmobile:~/git/test/server/main$ cd ..
> vmiklos@vmobile:~/git/test/server$ mkdir libfoo
> vmiklos@vmobile:~/git/test/server$ cd libfoo
> vmiklos@vmobile:~/git/test/server/libfoo$ git init
> Initialized empty Git repository in .git/
> vmiklos@vmobile:~/git/test/server/libfoo$ echo "foo" > libfoo.c
> vmiklos@vmobile:~/git/test/server/libfoo$ git add libfoo.c
> vmiklos@vmobile:~/git/test/server/libfoo$ git commit -m "import libfoo"
> Created initial commit 5979d36: import libfoo
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 libfoo.c
> vmiklos@vmobile:~/git/test/server/libfoo$ cd ../..
> vmiklos@vmobile:~/git/test$ mkdir client
> vmiklos@vmobile:~/git/test$ cd client
> vmiklos@vmobile:~/git/test/client$ git clone ../server/main
> Initialized empty Git repository in /home/vmiklos/git/test/client/main/.git/
> remote: Generating pack...
> Done counting 3 objects.
> Deltifying 3 objects...
> 100% (3/3) done
> Total 3 remote: (delta 0), reused 0 (delta 0)
> Indexing 3 objects...
> 100% (3/3) done
>
> vmiklos@vmobile:~/git/test/client$ cd main
> vmiklos@vmobile:~/git/test/client/main$ ls
> main.c
> vmiklos@vmobile:~/git/test/client/main$ git submodule add ../../server/libfoo/ libfoo
Here you add a submodule in the copy of the superproject in client.
> Initialized empty Git repository in /home/vmiklos/git/test/client/main/libfoo/.git/
> remote: Generating pack...
> remote: Done counting 3 objects.
> remote: Deltifying 3 objects...
> 100% (3/3) done
> Total 3 (delta 0), reused 0 (delta 0)
> Indexing 3 objects...
> 100% (3/3) done
>
> vmiklos@vmobile:~/git/test/client/main$ git submodule init
> Submodule 'libfoo' (/home/vmiklos/git/test/server/libfoo/.git) registered for path 'libfoo'
> vmiklos@vmobile:~/git/test/client/main$ git commit -a -m "registered libfoo submodule"
> Created commit 2c65310: registered libfoo submodule
> 2 files changed, 4 insertions(+), 0 deletions(-)
> create mode 100644 .gitmodules
> create mode 160000 libfoo
> vmiklos@vmobile:~/git/test/client/main$ cd ../../server/main
> vmiklos@vmobile:~/git/test/server/main$ echo bar >> main.c
> vmiklos@vmobile:~/git/test/server/main$ git add git commit -m "bar in main"
> vmiklos@vmobile:~/git/test/server/main$ git add main.c
> vmiklos@vmobile:~/git/test/server/main$ git commit -m "bar in main"
> Created commit 1c26399: bar in main
> 1 files changed, 1 insertions(+), 0 deletions(-)
> vmiklos@vmobile:~/git/test/server/main$ cd ../libfoo
> vmiklos@vmobile:~/git/test/server/libfoo$ echo bar >> libfoo.c
> vmiklos@vmobile:~/git/test/server/libfoo$ git add libfoo.c
> vmiklos@vmobile:~/git/test/server/libfoo$ git commit -m "bar in libfoo"
> Created commit 07ceadb: bar in libfoo
> 1 files changed, 1 insertions(+), 0 deletions(-)
> vmiklos@vmobile:~/git/test/server/libfoo$ cd ../../client/main
> vmiklos@vmobile:~/git/test/client/main$ git submodule update
>
> at the end of it, git submodule update does not pull anything, while
> there are changes both in the main and in the libfoo repo, too
The last time you told the superproject about any changes
in the subprojects was when you added the subproject (in client),
so as far as the superproject is concerned nothing happened
in any submodule. The submodules don't even exist in server.
skimo
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 15:40 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070715152101.GJ999MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 05:21:01PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> > vmiklos@vmobile:~/git/test/client/main$ git submodule add ../../server/libfoo/ libfoo
>
> Here you add a submodule in the copy of the superproject in client.
correct
> > vmiklos@vmobile:~/git/test/client/main$ git submodule update
> >
> > at the end of it, git submodule update does not pull anything, while
> > there are changes both in the main and in the libfoo repo, too
>
> The last time you told the superproject about any changes
> in the subprojects was when you added the subproject (in client),
> so as far as the superproject is concerned nothing happened
> in any submodule. The submodules don't even exist in server.
okay, let me continue the example, then:
vmiklos@vmobile:~/git/test/client2$ git clone ../client/main
Initialized empty Git repository in /home/vmiklos/git/test/client2/main/.git/
remote: Generating pack...
remote: Done counting 11 objects.
remote: Deltifying 11 objects...
remote: 100% (11/11) done
Indexing 11 objects...
100% (11/11) done
Resolving 2 deltas...
100% (2/2) done
remote: Total 11 (delta 2), reused 3 (delta 0)
vmiklos@vmobile:~/git/test/client2$ ls
main/
vmiklos@vmobile:~/git/test/client2$ cd ../client/main/
vmiklos@vmobile:~/git/test/client/main$ git pull
Already up-to-date.
vmiklos@vmobile:~/git/test/client/main$ cd libfoo
vmiklos@vmobile:~/git/test/client/main/libfoo$ git pull
remote: Generating pack...
remote: Done counting 5 objects.
Result has 3 objects.
remote: Deltifying 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0 (delta remote: 0)
Unpacking 3 objects...
100% (3/3) done
* refs/remotes/origin/master: fast forward to branch 'master' of /home/vmiklos/git/test/server/libfoo/
old..new: 5979d36..07ceadb
Updating 5979d36..07ceadb
Fast forward
libfoo.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
vmiklos@vmobile:~/git/test/client/main/libfoo$ cd ../../../client2/main
vmiklos@vmobile:~/git/test/client2/main$ git submodule update
so the submodule exists now on the server and there would be something,
to update in the submodule, but git submodule update seem not to do
anything
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: Marco Costalba @ 2007-07-15 15:58 UTC (permalink / raw)
To: Sean; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <20070715110415.33692142.seanlkml@sympatico.ca>
On 7/15/07, Sean <seanlkml@sympatico.ca> wrote:
>
> characters are guaranteed to appear somewhere else. Your current
> test will fail if a "c" happens to follow NUL in the patch text.
>
Yes sir, I agree with you 100%
The real issue IMHO is that a 'delimiting character' should not appear
in the content that it is trying to delimit. That's all the point
around this thing. If a real 'delimiting character' does not exist
because the content is free perhaps we should find a way to understand
when we are at revision boundaries. The simplest (and most efficient)
way is to know the size of the message in advance.
Also if git log filters out the '\0' chars in the content it is
suboptimal because we could miss to see we have a '\0' in content. BTW
the above mentioned patch in Linux tree was all around removing that
garbage '\0'. If diff output was filtered out perhaps the author could
have missed that patch opportunity.
Marco
BTW, perhaps I'm retarded, but I fail to see what to search for with ^\0.
As example if I have this output:
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index fd3fd90..36c523d 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -444,7 +444,6 @@ static int compute_bitstructs(struct gfs2_rgrpd *rgd)
}
/**
-^@
* gfs2_ri_total - Total up the file system space, according to the rindex.
*
*/
^@commit 8fb68595d508fd30ec90939572484b263600376c
fad59c1390045b5adb7c7249ec4e77e0f868aca5
tree 218a457675c111e2224fb57998d38e45d5786bd1
parent fad59c1390045b5adb7c7249ec4e77e0f868aca5
What should I search for to find the revision boundary? "\n\0" ? is
this that you mean with ^\0
^ permalink raw reply related
* Re: Questions about git-fast-import for cvs2svn
From: Sean @ 2007-07-15 16:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Shawn O. Pearce, git
In-Reply-To: <469A2B1D.2040107@alum.mit.edu>
On Sun, 15 Jul 2007 16:11:41 +0200
Michael Haggerty <mhagger@alum.mit.edu> wrote:
Hi Michael,
Will take a stab at answering your questions...
> 1. Is it a problem to create blobs that are never referenced? The
> easiest point to create blobs is when the RCS files are originally
> parsed, but later we discard some CVS revisions, meaning that the
> corresponding blobs would never be needed. Would this be a problem?
Not a problem. Running "git gc" later will cleanup any unused objects.
> 2. It appears that author/committer require an email address. How
> important is a valid email address here?
It's not necessary for the operation of Git itself; it's up to you to
decide how important the information is to your project. You should
be able to set an empty email address for author or committer in
git fast-import as "name <>".
> a. CVS commits include a username but not an email address. If an
> email address is really required, then I suppose the person doing the
> conversion would have to supply a lookup table mapping username -> email
> address.
Yes, take a look at the format supported by git-cvsimport and git-svnimport,
which can map each username into an appropriate name and email addy for Git.
> b. CVS tag/branch creation events do not even include a username.
> Any suggestions for what to use here?
Perhaps just use your own username or one specifically created to
run the conversion process.
> 3. I expect we should set 'committer' to the value determined from CVS
> and leave 'author' unused. But I suppose another possibility would be
> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS
> author. Which one makes sense?
Another option is to just allow Git to set author and committer to the
same value. As noted in the man page: "If author is omitted then
fast-import will automatically use the committer's information for
the author portion of the commit".
> 4. It appears that a commit can only have a single 'from', which I
> suppose means that files can only be added to one branch from a single
> source branch/revision in a single commit. But CVS branches and tags
> can include files from multiple source branches and/or revisions. What
> would be the most git-like way to handle this situation? Should the
> branch be created in one commit, then have files from other sources
> added to it in other commits? Or should (is this even possible?) all
> files be added to the branch in a single commit, using multiple "merge"
> sources?
Git supports the ability to merge from multiple branches at once (known
as an octopus merge). So it's possible to start a new branch, drawing
in files from more than one source branch in a single commit. As i
understand it, fast-import allows only a single "from" line for a commit,
but allows multiple "merge" lines for additional parentage info.
> 5. Is there any significance at all to the order that commits are output
> to git-fast-import? Obviously, blobs have to be defined before they are
> used, and '<committish>'s have to be defined before they are referenced.
> But is there any other significance to the order of commits?
Don't think so, except perhaps for the packfile optimization issues
mentioned in the man page.
HTH,
Sean
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Sean @ 2007-07-15 16:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150858i1825e01clf0897ad4db319373@mail.gmail.com>
On Sun, 15 Jul 2007 17:58:21 +0200
"Marco Costalba" <mcostalba@gmail.com> wrote:
> What should I search for to find the revision boundary? "\n\0" ? is
> this that you mean with ^\0
Essentially yes. That pattern will never appear inside the comment
or patch text because both sections are always indented. So in the
example you cite, "\n\0" would match the proper terminator, and the
"\n-\0" NUL would be ignored.
Sean
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 16:27 UTC (permalink / raw)
To: Sean; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <20070715121600.792982ef.seanlkml@sympatico.ca>
On 7/15/07, Sean <seanlkml@sympatico.ca> wrote:
> On Sun, 15 Jul 2007 17:58:21 +0200
> "Marco Costalba" <mcostalba@gmail.com> wrote:
>
> > What should I search for to find the revision boundary? "\n\0" ? is
> > this that you mean with ^\0
>
> Essentially yes. That pattern will never appear inside the comment
> or patch text because both sections are always indented. So in the
> example you cite, "\n\0" would match the proper terminator, and the
> "\n-\0" NUL would be ignored.
>
But your scheme does not fail if the patch is not \n terminated ?
It can happen if the patch adds lines at the end of a file and the
last line is not \n terminated.
In this case your scheme seems to miss the good next revision boundary.
Marco
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Sean @ 2007-07-15 16:34 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150927l745926f0nab04ad82dff913@mail.gmail.com>
On Sun, 15 Jul 2007 18:27:41 +0200
"Marco Costalba" <mcostalba@gmail.com> wrote:
> But your scheme does not fail if the patch is not \n terminated ?
I'm pretty sure there is always a preceding end-of-line marker,
before the terminating NUL; although i haven't broken down and
read the code yet.
> It can happen if the patch adds lines at the end of a file and the
> last line is not \n terminated.
>
> In this case your scheme seems to miss the good next revision boundary.
>
Just tested this case here with "git log --parents --pretty=raw -z -r -p"
and git prints out: "\ No newline at end of file" followed by a newline
and then the NUL.
Sean
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 16:54 UTC (permalink / raw)
To: Sean; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <20070715123422.9a431506.seanlkml@sympatico.ca>
On 7/15/07, Sean <seanlkml@sympatico.ca> wrote:
>
> Just tested this case here with "git log --parents --pretty=raw -z -r -p"
> and git prints out: "\ No newline at end of file" followed by a newline
> and then the NUL.
>
Thanks. I think I will use your scheme so. But I really hope it's a
temporary workaround before git prints sizes with messages.
Thanks
Marco
^ permalink raw reply
* Re: Perforce support.
From: Jan Hudec @ 2007-07-15 17:51 UTC (permalink / raw)
To: Govind Salinas; +Cc: git
In-Reply-To: <69b0c0350707121134t61905e87xaa2fc78c30891bb0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On Thu, Jul 12, 2007 at 11:34:56 -0700, Govind Salinas wrote:
> I have been playing around with git for a month or so and have started
> writing, what I hope will be, a nice GUI over git that works well on
> Windows (Cygwin) and offers some feeling of familiarity to our
> Perforce users. That however is only half the problem.
There are already several guis for git. None of them covers complete git
functionality, but if you can start adding functionality to one of them
instead of starting from scratch, it would give you a good head start. At
least the git-gui (in Tcl/Tk, part of git distribution) and qgit4
(git://repo.or.cz/qgit4.git, discuss changes on the git mailing list -- se
also http://digilander.libero.it/mcostalba/, but that only discusses the
previous Qt3-based branch) work on Windows.
> We need to be able to go back and forth to our main Perforce depot,
> and while I understand that git-svn support is very good, I have only
> seen limited support of Perforce. I was wondering if anyone has been
> using git with p4 and how well did it work. We have very complex and
> somewhat large "clients" that do a lot of mapping of directories
> (which strikes me as particularly insane) and I was wondering if any
> of the tools support that.
>
> If anyone has any suggestions/guidance on how to do this I would appreciate
> it.
Search the list. The archive at http://marc.info/?l=git provides quite
sensible search support. There were some interesting discussions about
perforce in last few months.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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