* panic recovery
From: Levend Sayar @ 2011-01-16 12:33 UTC (permalink / raw)
To: git; +Cc: Eda Ercan
Hi, all.
Yesterday one of my colleague tried to commit her two weeks of work.
Nearly 10 source code files.
After an unsuccessful am and apply commands, she tried rebase. And git
bothered something like you have to finish your am first.
Then I suggested to do
git am --abort
After that, we saw that all the sources she developed for two weeks
are gone. We really got panic.But I know that git stores everthing as
objects, namely commit,tree,blob and tag objects.
We sorted every file according to modification time under .git/objects
directory and use "git show" for every single object.
After a cumbersome work, we found blob objects for our source codes
that we lost and commit objects. Namely we rescued her work.
Is there a better way to use in this kind of situations ?
For example, to list every single objects under objects directory
according to their types ?
Or search a phrase in every blob obejcts to find the source code we
are looking for ?
_lvnd_
(^_^)
^ permalink raw reply
* Re: multiple group access to update repo
From: Manuel Doninger @ 2011-01-16 12:27 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <igr99g$mca$1@dough.gmane.org>
On Sat, Jan 15, 2011 at 05:53, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
> How do I allow users from different linux group to cd to a common bare
> mirror repo and also to a common non-bare cloned repo and perform git-fetch
> and git pull --ff-only? Currently, the non-owner group gets this error:
>
> error: cannot open FETCH_HEAD: Permission denied
>
>
> v/r,
> Neal
>
In this case i would suggest to access the repository via SSH and do
the access control with Gitolite. Then you can use for example a user
"Git" and chmod the repositories to that user and group. Depending on
the size of your team, it could need a bit of time to configure
Gitolite, but it's very flexible to adjust it for later needs.
If this doesn't fit your needs, then i think the only solution is to
create a linux group only for that repository and assign all users,
that need access to the repository, to that group.
Manuel
^ permalink raw reply
* Re: cannot fetch arm git tree
From: Uwe Kleine-König @ 2011-01-16 11:08 UTC (permalink / raw)
To: Jello huang; +Cc: Russell King - ARM Linux, linux-arm-kernel, git
In-Reply-To: <20110116092315.GA27542@n2100.arm.linux.org.uk>
Hello Jello,
On Sun, Jan 16, 2011 at 09:23:15AM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 16, 2011 at 10:28:55AM +0800, Jello huang wrote:
> > Dear Russell,
> >
> > when i use git fetch,there arm some wrong with it.
> >
> > jello@jello-laptop:~/git/russell/linux-2.6-arm$git pull
> > error: Unable to find 89e4d4b145bb7e73b4c45671a84b401a5d8694c1 under
> > http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git
> > Cannot obtain needed blob 89e4d4b145bb7e73b4c45671a84b401a5d8694c1
> > while processing commit eda2e5dcc914b4d70f665443efc9780e89a5e5c1.
> > error: Fetch failed.
> >
> > What is the wrong?
>
> No idea. The tree has the object file in one of its pack files:
>
> | rmk@ZenIV:[linux-2.6-arm.git]:<1020> GIT_DIR=. git cat-file -p 89e4d4b145bb7e73b4c45671a84b401a5d8694c1|head
> |
> | List of maintainers and how to submit kernel changes
> |
> | Please try to follow the guidelines below. This will make things
> | easier on the maintainers. Not all of these guidelines matter for every
> | trivial patch so apply some common sense.
>
> and the pack info file lists all the pack files. Maybe you have a hash
> collision on a pack file with your repository?
Probably you have a corrupted pack file. Try renaming all packfiles
listed in
http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git/objects/info/packs
(i.e.
.git/objects/pack/pack-74405a23171b6debd894d4791e06956d6387022a.pack
etc.) and try refetching then. This happend to me after Ctrl-Cing an
earlier git-fetch. Git doesn't seem to handle that case.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i: reword in-editor documentation of "exec"
From: Matthieu Moy @ 2011-01-16 10:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, gitster, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <20110116020132.GB28137@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> -# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
> +# x, exec = run command using shell, and stop if it fails
I don't think this is a good change to remove the <cmd> part. All
other commands are used with
<command> <sha1> <subject line>
and I don't think the user would be able to guess that exec is
different without a hint.
If the problem is the wording of the sentence that may imply that
<cmd> should be the shell itself, then why not
x <cmd>, exec <cmd> = run command <cmd> using shell, and stop if it fails
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] remote-ext: do not segfault for blank lines
From: Jonathan Nieder @ 2011-01-16 3:49 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git, Junio C Hamano
In-Reply-To: <1286901583-30088-4-git-send-email-ilari.liusvaara@elisanet.fi>
Instead of stripping space characters past the beginning of the
line and overflowing a buffer, stop at the beginning of the line
(mimicking the corresponding fix in remote-fd).
The argument to isspace does not need to be cast explicitly because
git isspace takes care of that already.
Noticed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin/remote-ext.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/remote-ext.c b/builtin/remote-ext.c
index 1f77317..ea71977 100644
--- a/builtin/remote-ext.c
+++ b/builtin/remote-ext.c
@@ -212,16 +212,16 @@ static int command_loop(const char *child)
char buffer[MAXCOMMAND];
while (1) {
- size_t length;
+ size_t i;
if (!fgets(buffer, MAXCOMMAND - 1, stdin)) {
if (ferror(stdin))
die("Comammand input error");
exit(0);
}
/* Strip end of line characters. */
- length = strlen(buffer);
- while (isspace((unsigned char)buffer[length - 1]))
- buffer[--length] = 0;
+ i = strlen(buffer);
+ while (i > 0 && isspace(buffer[i - 1]))
+ buffer[--i] = 0;
if (!strcmp(buffer, "capabilities")) {
printf("*connect\n\n");
--
1.7.4.rc2
^ permalink raw reply related
* Re: [PATCH] Optionally parse author information
From: Ramkumar Ramachandra @ 2011-01-16 3:32 UTC (permalink / raw)
To: Joe Corneli
Cc: Love Hörnquist Åstrand, Jonathan Nieder, Git List,
Michael Haggerty
In-Reply-To: <AANLkTi=ddJYT8YiUDYy80xobkxJnvuREN-09=464P_vB@mail.gmail.com>
Hi Joe,
Joe Corneli writes:
> I tested it, and it seems to use email handle instead of author name
> (perhaps that's intentional, though in my case it's not so desirable)
> but, quite critically, it gets the dates wrong:
Yes. I didn't change it's core behavior- it used to extract the
information from the committer's email address previously; I just
changed it to use the author's email address. For dates, it uses
committer dates again, and this is probably desirable: author dates
aren't necessarily monotonic, and this can break some functionality in
SVN.
Ofcourse, a lot more is possible with an patch that allows users to
configure all these things. Until then, I recommend that you just edit
the source to achieve the desired results.
-- Ram
^ permalink raw reply
* Re: [PATCH] Optionally parse author information
From: Jonathan Nieder @ 2011-01-16 2:57 UTC (permalink / raw)
To: Joe Corneli
Cc: Ramkumar Ramachandra, Love Hörnquist Åstrand, Git List,
Michael Haggerty
In-Reply-To: <AANLkTi=ddJYT8YiUDYy80xobkxJnvuREN-09=464P_vB@mail.gmail.com>
Joe Corneli wrote:
> I tested it, and it seems to use email handle instead of author name
> (perhaps that's intentional, though in my case it's not so desirable)
Good point. Presumably git2svn is using the local part of the email
address to mimic svn's default behavior of using one's username.
Other possibilities:
- email address (e.g., majordomo@planetmath.org, as in most google
repositories)
- display name (e.g., "Joe Corneli"). I don't know if svn-related
tools or scripts assume that svn:author doesn't contain spaces.
- full ident string (e.g., "Joe Corneli <majordomo@planetmath.org>")
- whatever the operator wants (mapping specified in authors file).
My guess: an "authors file" facility would be needed to cover all
cases, but whichever rule you want to implement short of that could
also be useful.
> but, quite critically, it gets the dates wrong:
>
> ~/pmhistory.svn$ svn log -l 5
> ------------------------------------------------------------------------
> r53127 | majordomo | 2011-01-10 18:31:58 -0500 (Mon, 10 Jan 2011) | 1 line
[...]
> ~/pmhistory.git$ git log -5
> commit 411b8698e494ee12799300611fed0c8029e76ad3
> Author: milogardner <majordomo@planetmath.org>
> Date: Thu Dec 16 14:11:57 2010 +0000
Maybe it is using the committer date (as shown by "git log --format=fuller")
and someone rebased recently. If you don't care about svn's '{date}'
construct working (meaning out-of-order dates are ok) then author date
might be more suitable. Presumably the important thing is for it to
be consistent.
Hope that helps,
Jonathan
^ permalink raw reply
* [PATCH] Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
From: Jonathan Nieder @ 2011-01-16 2:22 UTC (permalink / raw)
To: David Barr
Cc: Git Mailing List, Ramkumar Ramachandra, Sverre Rabbelier,
Gabriel Filion, Johannes Sixt
In-Reply-To: <1286681415-1831-1-git-send-email-david.barr@cordelta.com>
Omit needless words ("Additionally ... <path> may also" is redundant).
While at it, place the explanation of this special case after the
general rules for paths to provide the reader with some context.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
A small language tweak.
Documentation/git-fast-import.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index f56dfca..e2a46a5 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -534,9 +534,6 @@ start with double quote (`"`).
If an `LF` or double quote must be encoded into `<path>` shell-style
quoting should be used, e.g. `"path/with\n and \" in it"`.
-Additionally, in `040000` mode, `<path>` may also be an empty string
-(`""`) to specify the root of the tree.
-
The value of `<path>` must be in canonical form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
@@ -545,6 +542,9 @@ The value of `<path>` must be in canonical form. That is it must not:
* contain the special component `.` or `..` (e.g. `foo/./bar` and
`foo/../bar` are invalid).
+In `040000` mode, `<path>` can be the empty string (`""`)
+to specify the root of the tree.
+
It is recommended that `<path>` always be encoded using UTF-8.
`filedelete`
--
1.7.4.rc2
^ permalink raw reply related
* Re: [PATCH] Optionally parse author information
From: Joe Corneli @ 2011-01-16 2:17 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Love Hörnquist Åstrand, Jonathan Nieder, Git List,
Michael Haggerty
In-Reply-To: <20110114101636.GA22970@kytes>
I tested it, and it seems to use email handle instead of author name
(perhaps that's intentional, though in my case it's not so desirable)
but, quite critically, it gets the dates wrong:
~/pmhistory.svn$ svn log -l 5
------------------------------------------------------------------------
r53127 | majordomo | 2011-01-10 18:31:58 -0500 (Mon, 10 Jan 2011) | 1 line
------------------------------------------------------------------------
r53126 | majordomo | 2011-01-10 18:31:58 -0500 (Mon, 10 Jan 2011) | 1 line
------------------------------------------------------------------------
r53125 | majordomo | 2011-01-10 18:31:58 -0500 (Mon, 10 Jan 2011) | 1 line
------------------------------------------------------------------------
r53124 | majordomo | 2011-01-10 18:31:57 -0500 (Mon, 10 Jan 2011) | 1 line
------------------------------------------------------------------------
r53123 | majordomo | 2011-01-10 18:31:57 -0500 (Mon, 10 Jan 2011) | 1 line
~/pmhistory.git$ git log -5
commit 411b8698e494ee12799300611fed0c8029e76ad3
Author: milogardner <majordomo@planetmath.org>
Date: Thu Dec 16 14:11:57 2010 +0000
commit d12f8472cc06feec1a0e3a652e4ac14d7869fb3f
Author: milogardner <majordomo@planetmath.org>
Date: Thu Dec 16 14:00:13 2010 +0000
commit 5febb4767563255280d95091ff9b2b0207042071
Author: Mathprof <majordomo@planetmath.org>
Date: Wed Dec 15 23:02:47 2010 +0000
commit 61b11b97c4e503c353af5c1cd68e17b053d12b8e
Author: pahio <majordomo@planetmath.org>
Date: Mon Dec 13 17:59:12 2010 +0000
commit 14d66e2dcd6151eb7214a9afbab159459912da6d
Author: pahio <majordomo@planetmath.org>
Date: Mon Dec 13 17:54:21 2010 +0000
^ permalink raw reply
* [PATCH] Documentation/fast-import: capitalize beginning of sentence
From: Jonathan Nieder @ 2011-01-16 2:16 UTC (permalink / raw)
To: David Barr
Cc: Git Mailing List, Ramkumar Ramachandra, Sverre Rabbelier,
Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20101128194501.GD19998@burratino>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Noticed by skimming through the v1.7.3..v1.7.4-rc2 diff.
Documentation/git-fast-import.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index e2a46a5..43d2174 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -905,7 +905,7 @@ The `<dataref>` can be either a mark reference (`:<idnum>`)
set previously or a full 40-byte SHA-1 of a Git blob, preexisting or
ready to be written.
-output uses the same format as `git cat-file --batch`:
+Output uses the same format as `git cat-file --batch`:
====
<sha1> SP 'blob' SP <size> LF
--
1.7.4.rc2
^ permalink raw reply related
* Re: Resumable clone/Gittorrent (again)
From: Sam Vilain @ 2011-01-16 2:11 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTi=8s4mjreC1yiJi4R5Y3G6_kErmBfk0B9ALcBO8@mail.gmail.com>
On 15/01/11 03:26, Luke Kenneth Casson Leighton wrote:
>>> and change that graph? are you _certain_ that you can write an
>>> algorithm which is capable of generating exactly the same mapping,
>>> even as more commits are added to the repository being mirrored, or,
>>> does that situation not matter?
>> For a given set of start and end points, and a given sort algorithm,
>> walking the commit tree can yield deterministic results.
> excellent. out of curiosity, is it as efficient as git pack-objects
> for the same start and end points?
That isn't a sensible question; walking the revision tree is something
that many commands, including git pack-objects, do internally.
>> Did you look at any of the previous research I linked to before?
> i've been following this since you first originally started it, sam
> :) it would have been be nice if it was a completed implementation
> that i could test and see "for real" what you're referring to (above)
> - the fact that it's in perl and has "TODO" at some of the critical
> points, after trying to work with it for several days i stopped and
> went "i'm not getting anywhere with this" and focussed on bittorrent
> "as a black box" instead.
>
> if i recall, the original gittorrent work that you did (mirror-sync),
> the primary aim was to rely solely and exclusively on a one-to-one
> direct link between one machine and another. in other words, whilst
> syncing, if that peer went "offline", you're screwed - you have to
> start again. is that a fair assessment? please do correct any
> assumptions that i've made.
Ok. Well, first off - I didn't start gittorrent; that was Jonas
Fonseca, it was his Masters thesis. Criticism about not having a
completed implementation to work with is therefore shared between him
and people who have come along since such as myself.
I don't know why you got the idea that the protocol is one to one. It's
one to one just like BitTorrent is - every communication is between two
nodes who share information about what they have and what they need,
before transferring data. It is supposed to be restartable and it is
not supposed to matter which node data is exchanged with. In that way,
you could in principle download from multiple nodes at once, or you
could have restartable transfers. If you lose connectivity then the
most that should have to be re-transferred are incomplete blocks.
> because on the basis _of_ that assumption, i decided not to proceed
> with mirror-sync, instead to pursue a "cache git pack-objects"
> approach and to use bittorrent "black-box-style". which i
> demonstrated (minus the cacheing) works perfectly well, several months
> back.
Right, but as others have noted, there are significant drawbacks with
this approach. For a start, to participate in such a network, you need
to get the particular exact pack that is currently being torrented; just
having a clone is not enough. This is because the result of git
pack-objects is not repeatable.
That being said for many projects that would be an acceptable compromise
for the advantages of a restartable clone. That is why I suggest that a
torrent transfer, treated as a mirror which is infrequently updated, may
be a better approach than trying to overly automate everything.
> as well, after nicolas and others went to all the trouble to explain
> what git pack-objects is, how it works, and how damn efficient it is,
> i'm pretty much convinced that an approach to uniquely identify, then
> pick and cache the *best* git pack-object made [by all the peers
> requested to provide a particular commit range], is the best, most
> efficient - and importantly simplest and easiest to understand -
> approach so far that i've heard. perhaps that's because i came up
> with it, i dunno :) but the important thing is that i can _show_ that
> it works (http://gitorious.org/python-libbittorrent/pybtlib - go back
> a few revisions)
That's great. If you want to continue this simple approach and ignore
the gittorrent/mirror-sync path altogether, that's fine too.
Trying to determine the "best" pack-object may be counter-productive.
Here's a simple approach which allows the repository owner to easily
arrange for efficient torrenting of essential object files:
Add to the .torrent manifest just these files:
.git/objects/pack/pack-*.pack - just the files with .keep files
.git/packed-refs - just the references which are completely available
via the .keep packs
In that way, a repository owner can periodically re-pack their repo,
mark the new pack files as .keep, then re-generate the .torrent file.
All nodes will just have to transfer the new packs, not everything.
> so - perhaps it would help if mirrorsync was revived, so that it can
> be used to demonstrate what you mean (there aren't any instructions on
> how to set up mirrorsync, for example). that would then allow people
> to do a comparative analysis of the approaches being taken.
Ok, that sounds like a good plan - I'll see if I can devote some time to
an explanatory series with working examples with reference to the
existing code etc over the coming months.
Cheers,
Sam
^ permalink raw reply
* [PATCH 2/2] rebase -i: explain how to discard all commits
From: Jonathan Nieder @ 2011-01-16 2:02 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <20110116015941.GA28137@burratino>
Preparing a patch series for submission (as explained under
INTERACTIVE MODE in the git rebase manual) sometimes involves
discarding commits representing changes that turned out to be a bad
idea. Usually this is quite simple to do by deleting the appropriate
"pick" lines, but if all commits are removed then the "remove
everything means abort" logic kicks in and the rebase is cancelled.
One can override that behavior by adding a line with the text "noop".
This is a follow-up to v1.6.0.3~21 (rebase -i: do not fail when there
is no commit to cherry-pick, 2008-10-10).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
git-rebase--interactive.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 09aeecf..d9dfc75 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1025,6 +1025,7 @@ first and then run 'git rebase --continue' again."
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
+# Use the "noop" command if you really want to remove all commits.
#
EOF
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 1/2] rebase -i: reword in-editor documentation of "exec"
From: Jonathan Nieder @ 2011-01-16 2:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <20110116015941.GA28137@burratino>
The argument to the "exec" insn represents a command to be passed to
the user's shell. (At first I misread the description as meaning it
should itself be the name of a shell.)
While fixing that, format the description to more closely parallel
the descriptions of other commands.
Before:
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but [...]
# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
After:
[...]
# f, fixup = like "squash", but [...]
# x, exec = run command using shell, and stop if it fails
#
# If you remove a line [...]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
It would be nice to say "stop for amending if it fails" (or similar)
to make the relationship to the edit insn clearer, but it is not clear
how to make room for that.
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a5ffd9a..09aeecf 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1021,7 +1021,7 @@ first and then run 'git rebase --continue' again."
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
-# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
+# x, exec = run command using shell, and stop if it fails
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 0/2] rebase -i: in-editor documentation nits
From: Jonathan Nieder @ 2011-01-16 1:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <1281453472-29835-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy wrote:
> +++ b/git-rebase--interactive.sh
> @@ -957,6 +988,7 @@ first and then run 'git rebase --continue' again."
> # e, edit = use commit, but stop for amending
> # s, squash = use commit, but meld into previous commit
> # f, fixup = like "squash", but discard this commit's log message
> +# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
> #
> # If you remove a line here THAT COMMIT WILL BE LOST.
> # However, if you remove everything, the rebase will be aborted.
Nit: the "exec" command is formatted differently from the commands
around it, making it stand out (which I don't think is intended).
While we're there, patch 2 adds some brief documentation for the
"noop" command.
Roughly based on [1] (which might be a nice patch to revive, by the
way). Sane?
Jonathan Nieder (2):
rebase -i: reword in-editor documentation of "exec"
rebase -i: explain how to discard all commits
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[1] http://thread.gmane.org/gmane.comp.version-control.git/161120/focus=162079
^ permalink raw reply
* [PATCH v1.7.4-rc2] ll-merge: simplify opts == NULL case
From: Jonathan Nieder @ 2011-01-16 1:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Justin Frankel, Bert Wesarg, git, eyvind.bernhardsen,
Avery Pennarun
In-Reply-To: <7vpqx5mipt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> + if (!opts) {
>> + struct ll_merge_options default_opts = {0};
>> + return ll_merge(result_buf, path, ancestor, ancestor_label,
>> + ours, our_label, theirs, their_label,
>> + &default_opts);
>
> Fun---expecting tail recursion elimination ;-)?
Fun but not warranted. Let's simplify.
-- 8< --
Subject: ll-merge: simplify opts == NULL case
As long as sizeof(struct ll_merge_options) is small, there is not
much reason not to keep a copy of the default merge options in the BSS
section. In return, we get clearer code and one less stack frame in
the opts == NULL case.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
ll-merge.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/ll-merge.c b/ll-merge.c
index 007dd3e..6ce512e 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -351,16 +351,13 @@ int ll_merge(mmbuffer_t *result_buf,
const struct ll_merge_options *opts)
{
static struct git_attr_check check[2];
+ static const struct ll_merge_options default_opts;
const char *ll_driver_name = NULL;
int marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
const struct ll_merge_driver *driver;
- if (!opts) {
- struct ll_merge_options default_opts = {0};
- return ll_merge(result_buf, path, ancestor, ancestor_label,
- ours, our_label, theirs, their_label,
- &default_opts);
- }
+ if (!opts)
+ opts = &default_opts;
if (opts->renormalize) {
normalize_file(ancestor, path);
--
1.7.4.rc2
^ permalink raw reply related
* Re: [PATCH] svndump.c: Fix a printf format compiler warning
From: Ramsay Jones @ 2011-01-15 18:06 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, GIT Mailing-list, David Barr,
Ramkumar Ramachandra
In-Reply-To: <20110111183927.GF15133@burratino>
Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/vcs-svn/svndump.c
>> +++ b/vcs-svn/svndump.c
>> @@ -211,7 +211,7 @@ void svndump_read(const char *url)
>> if (key == keys.svn_fs_dump_format_version) {
>> dump_ctx.version = atoi(val);
>> if (dump_ctx.version > 2)
>> - die("expected svn dump format version <= 2, found %d",
>> + die("expected svn dump format version <= 2, found %"PRIu32,
>> dump_ctx.version);
>
> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks!
> I think we should just use "int", but that is a wider sweeping change
> for another time. Thanks.
>
> Does gcc or sparse provide a warning that could have caught this
> mistake?
None that I know of, no ... :(
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [Not a] [Bug] Gitweb corrupting files?
From: Severin Gehwolf @ 2011-01-15 15:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hbdeatgn.fsf@localhost.localdomain>
On Wed, Jan 12, 2011 at 1:05 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Severin Gehwolf <jerboaa@gmail.com> writes:
>
>> It appears that Gitweb corrupts files when it is being used for
>> creating compressed tarballs of sources.
>
> E.g. http://egit.eclipse.org/w/?p=egit.git;a=snapshot;h=6b528445c3e543688b990e0a631c5f0238b02741;sf=tbz2
> error in egit/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/BranchSelectionDialog.java
>
>> A more precise description of the behaviour I'm experiencing is here:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317882
>
> Couldn't you post summary of the above here?
>
>> Unfortunately I have no knowledge about the version in use at eclipse.org.
>
> It's git and gitweb version 1.6.4.4.
>
>
> From original bugreport:
>
> And it built fine. Then, I tried checking out sources from command line using
> the git client:
>
> git clone git://egit.eclipse.org/egit.git egit
> cd egit
>
> git checkout 6b528445c3e543688b990e0a631c5f0238b02741
> cd ..
> tar -cjf egit_test.tar.bz2 egit
>
> This should be
>
> $ git archive --format=tar 6b528445c3e543688b990e0a631c5f0238b02741 |
> bzip2 > egit_test.tar.bz2
I did some digging and it looks like somehow those files are indeed
corrupt in the Git repo and it's not a Git or gitweb problem.
Thanks for responding!
--Severin
^ permalink raw reply
* Re: [PATCH] git-p4: Fixed handling of file names with spaces
From: Pete Wyckoff @ 2011-01-15 14:35 UTC (permalink / raw)
To: Jerzy Kozera; +Cc: Andreas Schwab, git, gitster, msclrhd
In-Reply-To: <A0F152FE-C659-4F9B-9625-505AA5DAF942@gmail.com>
jerzy.kozera@gmail.com wrote on Fri, 14 Jan 2011 22:45 +0000:
> On 14 Jan 2011, at 22:01, Andreas Schwab wrote:
> > Can those file names also include a double quote or a backquote or a
> > dollar sign?
>
>
> Double quote and backquote get escaped by git so they are not a problem:
> $ git diff-tree -r HEAD^ HEAD
> :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A "\" \\ $"
>
> But as you can see above, the dollar sign remains intact, so it needs to be handled as well - patch below takes it into account.
[..]
> - p4_system("reopen -t %s %s" % (p4Type, file))
> + p4_system("reopen -t %s \"%s\"" % (p4Type, file))
These changes are important for correctness. Thanks for fixing
them.
It is kind of ugly to have to do file escaping all over the
source. I'd rather see all the os.system() calls go away, in
favor of subprocess.Popen(). You can use the latter without
going through the shell at all, hence no escapes are needed.
If you feel ambitious, this would be a nice fix.
Spaces can happen in depot paths too. That isn't handled
current. All the p4Cmd and p4CmdList calls that work on
depotPaths should avoid going through the shell too.
But at least what you have done already should go in. If you
feel adventurous, addressing these other space-related issues
would be nice too.
-- Pete
^ permalink raw reply
* Re: [PATCH 2/3] vcs-svn: Start working on the dumpfile producer
From: Ramkumar Ramachandra @ 2011-01-15 8:11 UTC (permalink / raw)
To: Peter Baumann; +Cc: Git List, Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <20110115073925.GA21744@m62s10.vlinux.de>
Hi Peter,
Peter Baumann writes:
> > + while ((t = buffer_read_line(&input))) {
> > + val = strchr(t, ' ');
> > + if (!val) {
> > + if (!memcmp(t, "blob", 4))
> > + active_ctx = BLOB_CTX;
> > + else if (!memcmp(t, "deleteall", 9))
> > + ;
> > + continue;
>
> Having actually no idea what the input you are reading from might look like, but
> seeing those two memcmp compares above makes me wonder if 't' might ever be smaller
> than 4 (or 9 for the else part). Which obviously would lead to a SEGFAULT.
> In the code below there are also memcmp class which might step out of the
> buffer.
Right. Silly mistake on my part. Thanks for pointing it out.
There are probably many more trivial mistakes- I was in a hurry to get
/something/ working, and didn't have a chance to clean up the code.
-- Ram
^ permalink raw reply
* Re: [RFC PATCH 0/3] Towards a Git-to-SVN bridge
From: Ramkumar Ramachandra @ 2011-01-15 7:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110115072211.GB25253@burratino>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > Over the last couple of days, I've been working on a parser that
> > converts a fast-import stream into a SVN dumpfile. So far, it's very
> > rough and works minimally for some common fast-import
> > commands.
>
> Some early questions:
Thanks for raising these questions. People interested in the project
should find this useful.
> - what are the design goals? Is this meant to be super fast?
> Robust? Simple? Why should I be excited about it?[1]
I want it to be a lot like current svn-fe: as you can see, I've
re-used many parsing ideas from it. It has to be atleast as fast as
svnrdump, because I don't want it to bottleneck in the remote helper
pipeline. It has to be simple because it'll give rise to other simple
remote helpers- all the complexity has to be offloaded onto the lower
layers like fast-import/ fast-export, and not onto the developer of
the remote helper.
> - what subset of fast-import commands is supported? Is it well
> enough defined to make a manpage?
Currently, it supports just "commit", "blob", "author", "committer"
and "mark" that appear after a blob. It should support more commands
soon enough- this implementation is just a proof of concept. Also,
Instead of giving it the ability to parse /any/ valid fast-import
stream, I want to simply focus on parsing the stream produced by git
fast-export. That should explain why I'm trying to patch git
fast-export primarily.
> - does this produce v2 or v3 dumpfiles?
This is one issue I haven't thought about fully yet. I'm currently
thinking of generating a non-deltified dumpfile v3 -- something that
svnrdump will accept. Generating deltas might be an unnecessary
overhead- but as you pointed out yesterday, that clearly needs more
thought.
> - why would I use this instead of git2svn? Does git2svn do anything
> this will not eventually be able to do? (Not a trick question ---
> I don't have enough experience with git2svn to tell its strengths
> and weaknesses.)
git2svn persists blobs in-memory. It's written in Perl and it's
slow. I thought we needed something nicer to be used with a remote
helper, and started writing svn-fi.
> > I've decided to try re-implementing fast-export
> > to eliminate blob marks
>
> Hopefully "re-implement" means "patch" here. :)
Yep. Just a big one :)
> I can comment on the code but it's probably better if I have a sense
> of the design first (in any event, thanks for sending it).
I haven't had time to clean up the code. Note that it "just works" at
the moment- yes, it's already very very fast :) However, I'm going to
stall the branch and work on fast-export-inline for now.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/3] vcs-svn: Start working on the dumpfile producer
From: Peter Baumann @ 2011-01-15 7:39 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <1295074272-19559-3-git-send-email-artagnon@gmail.com>
On Sat, Jan 15, 2011 at 12:21:11PM +0530, Ramkumar Ramachandra wrote:
> Start off with some broad design sketches. Compile succeeds, but
> parser is incorrect. Include a Makefile rule to build it into
> vcs-svn/lib.a.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> Makefile | 2 +-
> vcs-svn/dump_export.c | 73 ++++++++++++
> vcs-svn/svnload.c | 294 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 368 insertions(+), 1 deletions(-)
> create mode 100644 vcs-svn/dump_export.c
> create mode 100644 vcs-svn/svnload.c
>
...
> diff --git a/vcs-svn/svnload.c b/vcs-svn/svnload.c
> new file mode 100644
> index 0000000..7043ae7
> --- /dev/null
> +++ b/vcs-svn/svnload.c
> @@ -0,0 +1,294 @@
> +/*
> + * Produce a dumpfile v3 from a fast-import stream.
> + * Load the dump into the SVN repository with:
> + * svnrdump load <URL> <dumpfile
> + *
> + * Licensed under a two-clause BSD-style license.
> + * See LICENSE for details.
> + */
> +
> +#include "cache.h"
> +#include "git-compat-util.h"
> +#include "line_buffer.h"
> +#include "dump_export.h"
> +#include "strbuf.h"
> +
> +#define SVN_DATE_FORMAT "%Y-%m-%dT%H:%M:%S.000000Z"
> +#define SVN_DATE_LEN 28
> +#define LENGTH_UNKNOWN (~0)
> +
> +static struct line_buffer input = LINE_BUFFER_INIT;
> +static struct strbuf blobs[100];
> +
> +static struct {
> + unsigned long prop_len, text_len, copyfrom_rev, mark;
> + int text_delta, prop_delta; /* Boolean */
> + enum node_action action;
> + enum node_kind kind;
> + struct strbuf copyfrom_path, path;
> +} node_ctx;
> +
> +static struct {
> + int rev, text_len;
> + struct strbuf props, log;
> + struct strbuf svn_author, author, committer;
> + struct strbuf author_date, committer_date;
> + struct strbuf author_email, committer_email;
> +} rev_ctx;
> +
> +static enum {
> + UNKNOWN_CTX,
> + COMMIT_CTX,
> + BLOB_CTX
> +} active_ctx;
> +
> +static void reset_rev_ctx(int revision)
> +{
> + rev_ctx.rev = revision;
> + strbuf_reset(&rev_ctx.props);
> + strbuf_reset(&rev_ctx.log);
> + strbuf_reset(&rev_ctx.svn_author);
> + strbuf_reset(&rev_ctx.author);
> + strbuf_reset(&rev_ctx.committer);
> + strbuf_reset(&rev_ctx.author_date);
> + strbuf_reset(&rev_ctx.committer_date);
> + strbuf_reset(&rev_ctx.author_email);
> + strbuf_reset(&rev_ctx.committer_email);
> +}
> +
> +static void reset_node_ctx(void)
> +{
> + node_ctx.prop_len = LENGTH_UNKNOWN;
> + node_ctx.text_len = LENGTH_UNKNOWN;
> + node_ctx.mark = 0;
> + node_ctx.copyfrom_rev = 0;
> + node_ctx.text_delta = -1;
> + node_ctx.prop_delta = -1;
> + strbuf_reset(&node_ctx.copyfrom_path);
> + strbuf_reset(&node_ctx.path);
> +}
> +
> +static void populate_props(struct strbuf *props, const char *author,
> + const char *log, const char *date) {
> + strbuf_reset(props);
> + strbuf_addf(props, "K\nsvn:author\nV\n%s\n", author);
> + strbuf_addf(props, "K\nsvn:log\nV\n%s", log);
> + strbuf_addf(props, "K\nsvn:date\nV\n%s\n", date);
> + strbuf_add(props, "PROPS-END\n", 10);
> +}
> +
> +static void parse_author_line(char *val, struct strbuf *name,
> + struct strbuf *email, struct strbuf *date) {
> + char *t, *tz_off;
> + char time_buf[SVN_DATE_LEN];
> + const struct tm *tm_time;
> +
> + /* Simon Hausmann <shausman@trolltech.com> 1170199019 +0100 */
> + strbuf_reset(name);
> + strbuf_reset(email);
> + strbuf_reset(date);
> + tz_off = strrchr(val, ' ');
> + *tz_off++ = '\0';
> + t = strrchr(val, ' ');
> + *(t - 1) = '\0'; /* Ignore '>' from email */
> + t ++;
> + tm_time = time_to_tm(strtoul(t, NULL, 10), atoi(tz_off));
> + strftime(time_buf, SVN_DATE_LEN, SVN_DATE_FORMAT, tm_time);
> + strbuf_add(date, time_buf, SVN_DATE_LEN);
> + t = strchr(val, '<');
> + *(t - 1) = '\0'; /* Ignore ' <' from email */
> + t ++;
> + strbuf_add(email, t, strlen(t));
> + strbuf_add(name, val, strlen(val));
> +}
> +
> +void svnload_read(void) {
> + char *t, *val;
> + int mode_incr;
> + struct strbuf *to_dump;
> +
> + while ((t = buffer_read_line(&input))) {
> + val = strchr(t, ' ');
> + if (!val) {
> + if (!memcmp(t, "blob", 4))
> + active_ctx = BLOB_CTX;
> + else if (!memcmp(t, "deleteall", 9))
> + ;
> + continue;
Having actually no idea what the input you are reading from might look like, but
seeing those two memcmp compares above makes me wonder if 't' might ever be smaller
than 4 (or 9 for the else part). Which obviously would lead to a SEGFAULT.
In the code below there are also memcmp class which might step out of the
buffer.
> + }
> + *val++ = '\0';
> +
> + /* strlen(key) */
> + switch (val - t - 1) {
> + case 1:
> + if (!memcmp(t, "D", 1)) {
> + node_ctx.action = NODE_ACTION_DELETE;
> + }
> + else if (!memcmp(t, "C", 1)) {
> + node_ctx.action = NODE_ACTION_ADD;
> + }
> + else if (!memcmp(t, "R", 1)) {
> + node_ctx.action = NODE_ACTION_REPLACE;
> + }
> + else if (!memcmp(t, "M", 1)) {
> + node_ctx.action = NODE_ACTION_CHANGE;
> + mode_incr = 7;
> + if (!memcmp(val, "100644", 6))
> + node_ctx.kind = NODE_KIND_NORMAL;
> + else if (!memcmp(val, "100755", 6))
> + node_ctx.kind = NODE_KIND_EXECUTABLE;
> + else if (!memcmp(val, "120000", 6))
> + node_ctx.kind = NODE_KIND_SYMLINK;
> + else if (!memcmp(val, "160000", 6))
> + node_ctx.kind = NODE_KIND_GITLINK;
> + else if (!memcmp(val, "040000", 6))
> + node_ctx.kind = NODE_KIND_SUBDIR;
> + else {
> + if (!memcmp(val, "755", 3))
> + node_ctx.kind = NODE_KIND_EXECUTABLE;
> + else if(!memcmp(val, "644", 3))
> + node_ctx.kind = NODE_KIND_NORMAL;
> + else
> + die("Unrecognized mode: %s", val);
> + mode_incr = 4;
> + }
> + val += mode_incr;
> + t = strchr(val, ' ');
> + *t++ = '\0';
> + strbuf_reset(&node_ctx.path);
> + strbuf_add(&node_ctx.path, t, strlen(t));
> + if (!memcmp(val + 1, "inline", 6))
> + die("Unsupported dataref: inline");
> + else if (*val == ':')
> + to_dump = &blobs[strtoul(val + 1, NULL, 10)];
> + else
> + die("Unsupported dataref: sha1");
> + dump_export_node(node_ctx.path.buf, node_ctx.kind,
> + node_ctx.action, to_dump->len,
> + 0, NULL);
> + printf("%s", to_dump->buf);
> + }
> + break;
> + case 3:
> + if (!memcmp(t, "tag", 3))
> + continue;
> + break;
> + case 4:
> + if (!memcmp(t, "mark", 4))
> + switch(active_ctx) {
> + case COMMIT_CTX:
> + /* What do we do with commit marks? */
> + continue;
> + case BLOB_CTX:
> + node_ctx.mark = strtoul(val + 1, NULL, 10);
> + break;
> + default:
> + break;
> + }
> + else if (!memcmp(t, "from", 4))
> + continue;
> + else if (!memcmp(t, "data", 4)) {
> + switch (active_ctx) {
> + case COMMIT_CTX:
> + strbuf_reset(&rev_ctx.log);
> + buffer_read_binary(&input,
> + &rev_ctx.log,
> + strtoul(val, NULL, 10));
> + populate_props(&rev_ctx.props,
> + rev_ctx.svn_author.buf,
> + rev_ctx.log.buf,
> + rev_ctx.author_date.buf);
> + dump_export_begin_rev(rev_ctx.rev,
> + rev_ctx.props.buf,
> + rev_ctx.props.len);
> + break;
> + case BLOB_CTX:
> + node_ctx.text_len = strtoul(val, NULL, 10);
> + buffer_read_binary(&input,
> + &blobs[node_ctx.mark],
> + node_ctx.text_len);
> + break;
> + default:
> + break;
> + }
> + }
> + break;
> + case 5:
> + if (!memcmp(t, "reset", 5))
> + continue;
> + if (!memcmp(t, "merge", 5))
> + continue;
> + break;
> + case 6:
> + if (!memcmp(t, "author", 6)) {
> + parse_author_line(val, &rev_ctx.author,
> + &rev_ctx.author_email,
> + &rev_ctx.author_date);
> + /* Build svn_author */
> + t = strchr(rev_ctx.author_email.buf, '@');
> + strbuf_reset(&rev_ctx.svn_author);
> + strbuf_add(&rev_ctx.svn_author,
> + rev_ctx.author_email.buf,
> + t - rev_ctx.author_email.buf);
> +
> + }
> + else if (!memcmp(t, "commit", 6)) {
> + rev_ctx.rev ++;
> + active_ctx = COMMIT_CTX;
> + }
> + break;
> + case 9:
> + if (!memcmp(t, "committer", 9))
> + parse_author_line(val, &rev_ctx.committer,
> + &rev_ctx.committer_email,
> + &rev_ctx.committer_date);
> + break;
> + default:
> + break;
> + }
> + }
> +}
> +
> +int svnload_init(const char *filename)
> +{
> + int i;
> + if (buffer_init(&input, filename))
> + return error("cannot open %s: %s", filename, strerror(errno));
> + active_ctx = UNKNOWN_CTX;
> + strbuf_init(&rev_ctx.props, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.log, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.author, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.committer, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.author_date, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.committer_date, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.author_email, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&rev_ctx.committer_email, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&node_ctx.path, MAX_GITSVN_LINE_LEN);
> + strbuf_init(&node_ctx.copyfrom_path, MAX_GITSVN_LINE_LEN);
> + for (i = 0; i < 100; i ++)
> + strbuf_init(&blobs[i], 10000);
> + return 0;
> +}
> +
> +void svnload_deinit(void)
> +{
> + int i;
> + reset_rev_ctx(0);
> + reset_node_ctx();
> + strbuf_release(&rev_ctx.props);
> + strbuf_release(&rev_ctx.log);
> + strbuf_release(&rev_ctx.author);
> + strbuf_release(&rev_ctx.committer);
> + strbuf_release(&rev_ctx.author_date);
> + strbuf_release(&rev_ctx.committer_date);
> + strbuf_release(&rev_ctx.author_email);
> + strbuf_release(&rev_ctx.committer_email);
> + strbuf_release(&node_ctx.path);
> + strbuf_release(&node_ctx.copyfrom_path);
> + for (i = 0; i < 100; i ++)
> + strbuf_release(&blobs[i]);
> + if (buffer_deinit(&input))
> + fprintf(stderr, "Input error\n");
> + if (ferror(stdout))
> + fprintf(stderr, "Output error\n");
> +}
> --
> 1.7.4.rc1.7.g2cf08.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* git bisect problems/ideas
From: Aaron S. Meurer @ 2011-01-15 7:33 UTC (permalink / raw)
To: git
First off, do you guys have an issue tracker? I asked on IRC, and someone told me that he didn't think you did, and to just post here. After searching your websites, as far as I can tell he was right, though this is amazing to me that you can handle a project like this without an issue tracker. If you guys really do, then sorry. I would rather post this there than here (though if you really do, please make it more findable!)
I just noticed this error/bug:
git checkout test
git bisect start
<do some bisecting>
git branch -D test
<finish bisecting>
git bisect reset
And it gives an error, because test has been deleted. This is in 1.7.3.5. Now, I looked through the log of the current master of git to see if anything has been done about this, and all I noticed was the commit 3bb8cf88247db5, which essentially improves the error message.
Now, this is good, because it seemed to me above that I was stuck bisecting until I recreated the test branch. I did not realize the git bisect <commit> syntax until later.
But this has brought me to bother you guys about something that has been bugging me for a while. I hate git bisect reset. 90% of the time I do not want to go back to where I started bisecting. I would much prefer to just have a git bisect stop command, which just stops the bisecting process, but leaves me where I am (like a shortcut to git bisect reset HEAD). This would be much more symmetric with git bisect start.
While we are on the topic of bisecting, I have another issue. Can we remove the restriction that a "bad" commit come after a "good" commit? I'd say about 70% of the time I use bisect to find a commit that fixes a bug, not breaks it. Whenever this happens, I have to bend my mind over backwards to remind myself that the good behavior is really "bad" and the bad behavior is really "good". Is there a reason that git bisect can't just introspect from which comes earlier and which comes later to see which is "good" or "bad" (instead of just raising an error when they are in the "wrong" order)?
Aaron Meurer
^ permalink raw reply
* Re: [RFC PATCH 0/3] Towards a Git-to-SVN bridge
From: Jonathan Nieder @ 2011-01-15 7:22 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, David Barr, Sverre Rabbelier
In-Reply-To: <1295074272-19559-1-git-send-email-artagnon@gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> Over the last couple of days, I've been working on a parser that
> converts a fast-import stream into a SVN dumpfile. So far, it's very
> rough and works minimally for some common fast-import
> commands.
Some early questions:
- what are the design goals? Is this meant to be super fast?
Robust? Simple? Why should I be excited about it?[1]
- what subset of fast-import commands is supported? Is it well
enough defined to make a manpage?
- does this produce v2 or v3 dumpfiles?
- why would I use this instead of git2svn? Does git2svn do anything
this will not eventually be able to do? (Not a trick question ---
I don't have enough experience with git2svn to tell its strengths
and weaknesses.)
> I've decided to try re-implementing fast-export
> to eliminate blob marks
Hopefully "re-implement" means "patch" here. :)
I can comment on the code but it's probably better if I have a sense
of the design first (in any event, thanks for sending it).
Regards,
Jonathan
[1] I found the original svn-fe design interesting because
(1) it reused code from an existing svndump parser, at least in
spirit,
(2) the repo_tree data structure was well fitted to the design
constraints,
(3) the line_buffer input abstraction was oddly satisfying, even
though it does not buy anything obvious out of the box over
direct use of strbuf and stdio;
(4) speed; and, most importantly
(5) the command-line interface was easy to debug, very flexible,
and dead simple.
I find the current svn-fe satisfying in a different way --- a sort of
"line by line" translation between dump formats is becoming possible.
^ permalink raw reply
* [PATCH 3/3] Build an svn-fi target in contrib/svn-fe
From: Ramkumar Ramachandra @ 2011-01-15 6:51 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <1295074272-19559-1-git-send-email-artagnon@gmail.com>
Build an svn-fi target for testing the dumpfile producer in vcs-svn/.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
contrib/svn-fe/Makefile | 23 +++++++++++++++++++++--
contrib/svn-fe/svn-fi.c | 16 ++++++++++++++++
contrib/svn-fe/svn-fi.txt | 28 ++++++++++++++++++++++++++++
3 files changed, 65 insertions(+), 2 deletions(-)
create mode 100644 contrib/svn-fe/svn-fi.c
create mode 100644 contrib/svn-fe/svn-fi.txt
diff --git a/contrib/svn-fe/Makefile b/contrib/svn-fe/Makefile
index 360d8da..555a8ff 100644
--- a/contrib/svn-fe/Makefile
+++ b/contrib/svn-fe/Makefile
@@ -37,7 +37,7 @@ svn-fe$X: svn-fe.o $(VCSSVN_LIB) $(GIT_LIB)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ svn-fe.o \
$(ALL_LDFLAGS) $(LIBS)
-svn-fe.o: svn-fe.c ../../vcs-svn/svndump.h
+svn-fe.o: svn-fe.c ../../vcs-svn/svnload.h
$(QUIET_CC)$(CC) -I../../vcs-svn -o $*.o -c $(ALL_CFLAGS) $<
svn-fe.html: svn-fe.txt
@@ -51,6 +51,24 @@ svn-fe.1: svn-fe.txt
../contrib/svn-fe/$@
$(MV) ../../Documentation/svn-fe.1 .
+svn-fi$X: svn-fi.o $(VCSSVN_LIB) $(GIT_LIB)
+ $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ svn-fi.o \
+ $(ALL_LDFLAGS) $(LIBS)
+
+svn-fi.o: svn-fi.c ../../vcs-svn/svnload.h
+ $(QUIET_CC)$(CC) -I../../vcs-svn -o $*.o -c $(ALL_CFLAGS) $<
+
+svn-fi.html: svn-fi.txt
+ $(QUIET_SUBDIR0)../../Documentation $(QUIET_SUBDIR1) \
+ MAN_TXT=../contrib/svn-fe/svn-fi.txt \
+ ../contrib/svn-fe/$@
+
+svn-fi.1: svn-fi.txt
+ $(QUIET_SUBDIR0)../../Documentation $(QUIET_SUBDIR1) \
+ MAN_TXT=../contrib/svn-fe/svn-fi.txt \
+ ../contrib/svn-fe/$@
+ $(MV) ../../Documentation/svn-fi.1 .
+
../../vcs-svn/lib.a: FORCE
$(QUIET_SUBDIR0)../.. $(QUIET_SUBDIR1) vcs-svn/lib.a
@@ -58,6 +76,7 @@ svn-fe.1: svn-fe.txt
$(QUIET_SUBDIR0)../.. $(QUIET_SUBDIR1) libgit.a
clean:
- $(RM) svn-fe$X svn-fe.o svn-fe.html svn-fe.xml svn-fe.1
+ $(RM) svn-fe$X svn-fe.o svn-fe.html svn-fe.xml svn-fe.1 \
+ svn-fi$X svn-fi.o svn-fi.html svn-fi.xml svn-fi.1
.PHONY: all clean FORCE
diff --git a/contrib/svn-fe/svn-fi.c b/contrib/svn-fe/svn-fi.c
new file mode 100644
index 0000000..81347b0
--- /dev/null
+++ b/contrib/svn-fe/svn-fi.c
@@ -0,0 +1,16 @@
+/*
+ * This file is in the public domain.
+ * You may freely use, modify, distribute, and relicense it.
+ */
+
+#include <stdlib.h>
+#include "svnload.h"
+
+int main(int argc, char **argv)
+{
+ if (svnload_init(NULL))
+ return 1;
+ svnload_read();
+ svnload_deinit();
+ return 0;
+}
diff --git a/contrib/svn-fe/svn-fi.txt b/contrib/svn-fe/svn-fi.txt
new file mode 100644
index 0000000..996a175
--- /dev/null
+++ b/contrib/svn-fe/svn-fi.txt
@@ -0,0 +1,28 @@
+svn-fe(1)
+=========
+
+NAME
+----
+svn-fi - convert fast-import stream to an SVN "dumpfile"
+
+SYNOPSIS
+--------
+[verse]
+svn-fi
+
+DESCRIPTION
+-----------
+
+Converts a git-fast-import(1) stream into a Subversion dumpfile.
+
+INPUT FORMAT
+-------------
+The fast-import format is documented by the git-fast-import(1)
+manual page.
+
+OUTPUT FORMAT
+------------
+Subversion's repository dump format is documented in full in
+`notes/dump-load-format.txt` from the Subversion source tree.
+Files in this format can be generated using the 'svnadmin dump' or
+'svk admin dump' command.
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
* [PATCH 2/3] vcs-svn: Start working on the dumpfile producer
From: Ramkumar Ramachandra @ 2011-01-15 6:51 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <1295074272-19559-1-git-send-email-artagnon@gmail.com>
Start off with some broad design sketches. Compile succeeds, but
parser is incorrect. Include a Makefile rule to build it into
vcs-svn/lib.a.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Makefile | 2 +-
vcs-svn/dump_export.c | 73 ++++++++++++
vcs-svn/svnload.c | 294 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 368 insertions(+), 1 deletions(-)
create mode 100644 vcs-svn/dump_export.c
create mode 100644 vcs-svn/svnload.c
diff --git a/Makefile b/Makefile
index 1345c38..40f6691 100644
--- a/Makefile
+++ b/Makefile
@@ -1834,7 +1834,7 @@ ifndef NO_CURL
endif
XDIFF_OBJS = xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o xdiff/xpatience.o
-VCSSVN_OBJS = vcs-svn/line_buffer.o \
+VCSSVN_OBJS = vcs-svn/line_buffer.o vcs-svn/svnload.o vcs-svn/dump_export.o \
vcs-svn/repo_tree.o vcs-svn/fast_export.o vcs-svn/sliding_window.o \
vcs-svn/svndiff.o vcs-svn/svndump.o
VCSSVN_TEST_OBJS = test-obj-pool.o \
diff --git a/vcs-svn/dump_export.c b/vcs-svn/dump_export.c
new file mode 100644
index 0000000..04ede06
--- /dev/null
+++ b/vcs-svn/dump_export.c
@@ -0,0 +1,73 @@
+/*
+ * Licensed under a two-clause BSD-style license.
+ * See LICENSE for details.
+ */
+
+#include "git-compat-util.h"
+#include "strbuf.h"
+#include "line_buffer.h"
+#include "dump_export.h"
+
+void dump_export_begin_rev(int revision, const char *revprops,
+ int prop_len) {
+ printf("Revision-number: %d\n", revision);
+ printf("Prop-content-length: %d\n", prop_len);
+ printf("Content-length: %d\n\n", prop_len);
+ printf("%s\n", revprops);
+}
+
+void dump_export_node(const char *path, enum node_kind kind,
+ enum node_action action, unsigned long text_len,
+ unsigned long copyfrom_rev, const char *copyfrom_path) {
+ printf("Node-path: %s\n", path);
+ printf("Node-kind: ");
+ switch (action) {
+ case NODE_KIND_NORMAL:
+ printf("file\n");
+ break;
+ case NODE_KIND_EXECUTABLE:
+ printf("file\n");
+ break;
+ case NODE_KIND_SYMLINK:
+ printf("file\n");
+ break;
+ case NODE_KIND_GITLINK:
+ printf("file\n");
+ break;
+ case NODE_KIND_SUBDIR:
+ die("Unsupported: subdirectory");
+ default:
+ break;
+ }
+ printf("Node-action: ");
+ switch (action) {
+ case NODE_ACTION_CHANGE:
+ printf("change\n");
+ break;
+ case NODE_ACTION_ADD:
+ printf("add\n");
+ break;
+ case NODE_ACTION_REPLACE:
+ printf("replace\n");
+ break;
+ case NODE_ACTION_DELETE:
+ printf("delete\n");
+ break;
+ default:
+ break;
+ }
+ if (copyfrom_rev != SVN_INVALID_REV) {
+ printf("Node-copyfrom-rev: %lu\n", copyfrom_rev);
+ printf("Node-copyfrom-path: %s\n", copyfrom_path);
+ }
+ printf("Prop-delta: false\n");
+ printf("Prop-content-length: 10\n"); /* Constant 10 for "PROPS-END" */
+ printf("Text-delta: false\n");
+ printf("Text-content-length: %lu\n", text_len);
+ printf("Content-length: %lu\n\n", text_len + 10);
+ printf("PROPS-END\n\n");
+}
+
+void dump_export_text(struct line_buffer *data, off_t len) {
+ buffer_copy_bytes(data, len);
+}
diff --git a/vcs-svn/svnload.c b/vcs-svn/svnload.c
new file mode 100644
index 0000000..7043ae7
--- /dev/null
+++ b/vcs-svn/svnload.c
@@ -0,0 +1,294 @@
+/*
+ * Produce a dumpfile v3 from a fast-import stream.
+ * Load the dump into the SVN repository with:
+ * svnrdump load <URL> <dumpfile
+ *
+ * Licensed under a two-clause BSD-style license.
+ * See LICENSE for details.
+ */
+
+#include "cache.h"
+#include "git-compat-util.h"
+#include "line_buffer.h"
+#include "dump_export.h"
+#include "strbuf.h"
+
+#define SVN_DATE_FORMAT "%Y-%m-%dT%H:%M:%S.000000Z"
+#define SVN_DATE_LEN 28
+#define LENGTH_UNKNOWN (~0)
+
+static struct line_buffer input = LINE_BUFFER_INIT;
+static struct strbuf blobs[100];
+
+static struct {
+ unsigned long prop_len, text_len, copyfrom_rev, mark;
+ int text_delta, prop_delta; /* Boolean */
+ enum node_action action;
+ enum node_kind kind;
+ struct strbuf copyfrom_path, path;
+} node_ctx;
+
+static struct {
+ int rev, text_len;
+ struct strbuf props, log;
+ struct strbuf svn_author, author, committer;
+ struct strbuf author_date, committer_date;
+ struct strbuf author_email, committer_email;
+} rev_ctx;
+
+static enum {
+ UNKNOWN_CTX,
+ COMMIT_CTX,
+ BLOB_CTX
+} active_ctx;
+
+static void reset_rev_ctx(int revision)
+{
+ rev_ctx.rev = revision;
+ strbuf_reset(&rev_ctx.props);
+ strbuf_reset(&rev_ctx.log);
+ strbuf_reset(&rev_ctx.svn_author);
+ strbuf_reset(&rev_ctx.author);
+ strbuf_reset(&rev_ctx.committer);
+ strbuf_reset(&rev_ctx.author_date);
+ strbuf_reset(&rev_ctx.committer_date);
+ strbuf_reset(&rev_ctx.author_email);
+ strbuf_reset(&rev_ctx.committer_email);
+}
+
+static void reset_node_ctx(void)
+{
+ node_ctx.prop_len = LENGTH_UNKNOWN;
+ node_ctx.text_len = LENGTH_UNKNOWN;
+ node_ctx.mark = 0;
+ node_ctx.copyfrom_rev = 0;
+ node_ctx.text_delta = -1;
+ node_ctx.prop_delta = -1;
+ strbuf_reset(&node_ctx.copyfrom_path);
+ strbuf_reset(&node_ctx.path);
+}
+
+static void populate_props(struct strbuf *props, const char *author,
+ const char *log, const char *date) {
+ strbuf_reset(props);
+ strbuf_addf(props, "K\nsvn:author\nV\n%s\n", author);
+ strbuf_addf(props, "K\nsvn:log\nV\n%s", log);
+ strbuf_addf(props, "K\nsvn:date\nV\n%s\n", date);
+ strbuf_add(props, "PROPS-END\n", 10);
+}
+
+static void parse_author_line(char *val, struct strbuf *name,
+ struct strbuf *email, struct strbuf *date) {
+ char *t, *tz_off;
+ char time_buf[SVN_DATE_LEN];
+ const struct tm *tm_time;
+
+ /* Simon Hausmann <shausman@trolltech.com> 1170199019 +0100 */
+ strbuf_reset(name);
+ strbuf_reset(email);
+ strbuf_reset(date);
+ tz_off = strrchr(val, ' ');
+ *tz_off++ = '\0';
+ t = strrchr(val, ' ');
+ *(t - 1) = '\0'; /* Ignore '>' from email */
+ t ++;
+ tm_time = time_to_tm(strtoul(t, NULL, 10), atoi(tz_off));
+ strftime(time_buf, SVN_DATE_LEN, SVN_DATE_FORMAT, tm_time);
+ strbuf_add(date, time_buf, SVN_DATE_LEN);
+ t = strchr(val, '<');
+ *(t - 1) = '\0'; /* Ignore ' <' from email */
+ t ++;
+ strbuf_add(email, t, strlen(t));
+ strbuf_add(name, val, strlen(val));
+}
+
+void svnload_read(void) {
+ char *t, *val;
+ int mode_incr;
+ struct strbuf *to_dump;
+
+ while ((t = buffer_read_line(&input))) {
+ val = strchr(t, ' ');
+ if (!val) {
+ if (!memcmp(t, "blob", 4))
+ active_ctx = BLOB_CTX;
+ else if (!memcmp(t, "deleteall", 9))
+ ;
+ continue;
+ }
+ *val++ = '\0';
+
+ /* strlen(key) */
+ switch (val - t - 1) {
+ case 1:
+ if (!memcmp(t, "D", 1)) {
+ node_ctx.action = NODE_ACTION_DELETE;
+ }
+ else if (!memcmp(t, "C", 1)) {
+ node_ctx.action = NODE_ACTION_ADD;
+ }
+ else if (!memcmp(t, "R", 1)) {
+ node_ctx.action = NODE_ACTION_REPLACE;
+ }
+ else if (!memcmp(t, "M", 1)) {
+ node_ctx.action = NODE_ACTION_CHANGE;
+ mode_incr = 7;
+ if (!memcmp(val, "100644", 6))
+ node_ctx.kind = NODE_KIND_NORMAL;
+ else if (!memcmp(val, "100755", 6))
+ node_ctx.kind = NODE_KIND_EXECUTABLE;
+ else if (!memcmp(val, "120000", 6))
+ node_ctx.kind = NODE_KIND_SYMLINK;
+ else if (!memcmp(val, "160000", 6))
+ node_ctx.kind = NODE_KIND_GITLINK;
+ else if (!memcmp(val, "040000", 6))
+ node_ctx.kind = NODE_KIND_SUBDIR;
+ else {
+ if (!memcmp(val, "755", 3))
+ node_ctx.kind = NODE_KIND_EXECUTABLE;
+ else if(!memcmp(val, "644", 3))
+ node_ctx.kind = NODE_KIND_NORMAL;
+ else
+ die("Unrecognized mode: %s", val);
+ mode_incr = 4;
+ }
+ val += mode_incr;
+ t = strchr(val, ' ');
+ *t++ = '\0';
+ strbuf_reset(&node_ctx.path);
+ strbuf_add(&node_ctx.path, t, strlen(t));
+ if (!memcmp(val + 1, "inline", 6))
+ die("Unsupported dataref: inline");
+ else if (*val == ':')
+ to_dump = &blobs[strtoul(val + 1, NULL, 10)];
+ else
+ die("Unsupported dataref: sha1");
+ dump_export_node(node_ctx.path.buf, node_ctx.kind,
+ node_ctx.action, to_dump->len,
+ 0, NULL);
+ printf("%s", to_dump->buf);
+ }
+ break;
+ case 3:
+ if (!memcmp(t, "tag", 3))
+ continue;
+ break;
+ case 4:
+ if (!memcmp(t, "mark", 4))
+ switch(active_ctx) {
+ case COMMIT_CTX:
+ /* What do we do with commit marks? */
+ continue;
+ case BLOB_CTX:
+ node_ctx.mark = strtoul(val + 1, NULL, 10);
+ break;
+ default:
+ break;
+ }
+ else if (!memcmp(t, "from", 4))
+ continue;
+ else if (!memcmp(t, "data", 4)) {
+ switch (active_ctx) {
+ case COMMIT_CTX:
+ strbuf_reset(&rev_ctx.log);
+ buffer_read_binary(&input,
+ &rev_ctx.log,
+ strtoul(val, NULL, 10));
+ populate_props(&rev_ctx.props,
+ rev_ctx.svn_author.buf,
+ rev_ctx.log.buf,
+ rev_ctx.author_date.buf);
+ dump_export_begin_rev(rev_ctx.rev,
+ rev_ctx.props.buf,
+ rev_ctx.props.len);
+ break;
+ case BLOB_CTX:
+ node_ctx.text_len = strtoul(val, NULL, 10);
+ buffer_read_binary(&input,
+ &blobs[node_ctx.mark],
+ node_ctx.text_len);
+ break;
+ default:
+ break;
+ }
+ }
+ break;
+ case 5:
+ if (!memcmp(t, "reset", 5))
+ continue;
+ if (!memcmp(t, "merge", 5))
+ continue;
+ break;
+ case 6:
+ if (!memcmp(t, "author", 6)) {
+ parse_author_line(val, &rev_ctx.author,
+ &rev_ctx.author_email,
+ &rev_ctx.author_date);
+ /* Build svn_author */
+ t = strchr(rev_ctx.author_email.buf, '@');
+ strbuf_reset(&rev_ctx.svn_author);
+ strbuf_add(&rev_ctx.svn_author,
+ rev_ctx.author_email.buf,
+ t - rev_ctx.author_email.buf);
+
+ }
+ else if (!memcmp(t, "commit", 6)) {
+ rev_ctx.rev ++;
+ active_ctx = COMMIT_CTX;
+ }
+ break;
+ case 9:
+ if (!memcmp(t, "committer", 9))
+ parse_author_line(val, &rev_ctx.committer,
+ &rev_ctx.committer_email,
+ &rev_ctx.committer_date);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
+int svnload_init(const char *filename)
+{
+ int i;
+ if (buffer_init(&input, filename))
+ return error("cannot open %s: %s", filename, strerror(errno));
+ active_ctx = UNKNOWN_CTX;
+ strbuf_init(&rev_ctx.props, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.log, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.author, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.committer, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.author_date, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.committer_date, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.author_email, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&rev_ctx.committer_email, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&node_ctx.path, MAX_GITSVN_LINE_LEN);
+ strbuf_init(&node_ctx.copyfrom_path, MAX_GITSVN_LINE_LEN);
+ for (i = 0; i < 100; i ++)
+ strbuf_init(&blobs[i], 10000);
+ return 0;
+}
+
+void svnload_deinit(void)
+{
+ int i;
+ reset_rev_ctx(0);
+ reset_node_ctx();
+ strbuf_release(&rev_ctx.props);
+ strbuf_release(&rev_ctx.log);
+ strbuf_release(&rev_ctx.author);
+ strbuf_release(&rev_ctx.committer);
+ strbuf_release(&rev_ctx.author_date);
+ strbuf_release(&rev_ctx.committer_date);
+ strbuf_release(&rev_ctx.author_email);
+ strbuf_release(&rev_ctx.committer_email);
+ strbuf_release(&node_ctx.path);
+ strbuf_release(&node_ctx.copyfrom_path);
+ for (i = 0; i < 100; i ++)
+ strbuf_release(&blobs[i]);
+ if (buffer_deinit(&input))
+ fprintf(stderr, "Input error\n");
+ if (ferror(stdout))
+ fprintf(stderr, "Output error\n");
+}
--
1.7.4.rc1.7.g2cf08.dirty
^ 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