* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Jeff King @ 2009-12-05 16:28 UTC (permalink / raw)
To: James P. Howard, II; +Cc: Junio C Hamano, git
In-Reply-To: <20091205154753.GA3717@thermopylae.local>
On Sat, Dec 05, 2009 at 10:47:53AM -0500, James P. Howard, II wrote:
> > - While the amount of change necessary for this change doesn't look too
> > bad, is it really worth it? What is wrong with "1,$p" while using ed
> > as your editor?
>
> I tried a few variants of this, and shell script wrappers for ex (and
> gate, which is a specizalized text editor that actually works kind of
> well for commit message editing), and it worked fairly well.
>
> The real motivation is that this feature ditches all assumptions about
> the capabilities of the text editor. I am not sure where that leads
> yet, but I'd rather make it possible.
Is your problem that your editor doesn't show the template content and
you want to see it, or is it that your editor isn't pleasant to use when
the buffer is pre-filled with the template?
If the former, it seems like just dumping it to stdout isn't all that
satisfying, either. What happens when your editing causes the
information to scroll off the screen and you want to see it again?
Couldn't you get the same thing just by doing "git status; git commit"?
If the latter, I think we would be better served by an option to simply
turn off the template. Then that is also helpful for the case of people
using decent editors, but who don't want to waste the CPU time on
generating the template information (which can be substantial for things
like media repositories).
I suspect your answer will be that it is some of both, but this just
really feels like we are putting hacks into git because of one
featureless editor. Hacks like that would be better suited (IMHO) to a
wrapper script for the editor.
-Peff
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-05 16:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marc Strapetz, git
In-Reply-To: <alpine.DEB.1.00.0912051601040.4985@pacific.mpi-cbg.de>
On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
> As for "missing", do you refer to "paid service", or "yet another GUI"?
Ahaha! I can say "a good gui" :)
I was not knowing that this was "paid service". I saw the screenshot
and tried it. No doubt, it has a _great_ ui interface. While installation I
realized that it is licensed.
- SOFTWARE Non-Commercial License,
- SOFTWARE Commercial License,
- SOFTWARE Enterprise License.
-- Dilip
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-05 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Maarten Lankhorst, git
In-Reply-To: <7vljhislbj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ... The test already checks that the change won't break soft reset,
> which is good, but it does not seem to check/specify what should happen in
> the mixed reset in this case (I think it should be allowed).
Heh, I was not thinking straight. A bare repository does not have the
index, so allowing (cd .git && git reset) is Ok but mixed in a bare
repository (cd bare.git && git reset) is not.
Let's cover a few more missing cases.
t/t7103-reset-bare.sh | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
index 3ddf0ac..68041df 100755
--- a/t/t7103-reset-bare.sh
+++ b/t/t7103-reset-bare.sh
@@ -21,20 +21,32 @@ test_expect_success 'merge reset requires a worktree' '
test_must_fail git reset --merge)
'
+test_expect_success 'mixed reset is ok' '
+ (cd .git && git reset)
+'
+
+test_expect_success 'soft reset is ok' '
+ (cd .git && git reset --soft)
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
'
-test_expect_success 'hard reset is not allowed' '
- test_must_fail git reset --hard HEAD^
+test_expect_success 'hard reset is not allowed in bare' '
+ test_must_fail git reset --hard HEAD^
'
-test_expect_success 'merge reset is not allowed' '
+test_expect_success 'merge reset is not allowed in bare' '
test_must_fail git reset --merge HEAD^
'
-test_expect_success 'soft reset is allowed' '
+test_expect_success 'mixed reset is not allowed in bare' '
+ test_must_fail git reset --mixed HEAD^
+'
+
+test_expect_success 'soft reset is allowed in bare' '
git reset --soft HEAD^ &&
test "`git show --pretty=format:%s | head -n 1`" = "one"
'
^ permalink raw reply related
* Re: [PATCH 3/3] Add a command "fix" to rebase --interactive.
From: Junio C Hamano @ 2009-12-05 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michael Haggerty, git
In-Reply-To: <alpine.DEB.1.00.0912041943160.21557@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> > index 0bd3bf7..539413d 100755
>> > --- a/git-rebase--interactive.sh
>> > +++ b/git-rebase--interactive.sh
>> > @@ -302,7 +302,7 @@ nth_string () {
>> >
>> > make_squash_message () {
>> > if test -f "$SQUASH_MSG"; then
>> > - COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
>> > + COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
> ...
> IIRC "|" was not correctly handled by BSD sed (used e.g. in MacOSX).
You are right; we actually have seen and fixed a similar breakage. For
example, "git log --all-match --grep=BRE --grep=ERE" finds:
commit 1883a0d3b7ad7c9de1ac790bda6f1a6181237439
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Sep 19 23:52:49 2008 -0700
diff: use extended regexp to find hunk headers
Using ERE elements such as "|" (alternation) by backquoting in BRE
is a GNU extension and should not be done in portable programs.
and "sed" is defined to take BRE.
Tentatively I'd queue this on top of 3/3 for eventual squashing.
Thanks
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 5 Dec 2009 10:42:44 -0800
Subject: [PATCH] [squash to Add a command "fix"] Avoid "\(alternatives\|choices\)" in sed script
---
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 539413d..c30209e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -302,7 +302,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
+ COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)[tsnr][htd] commit message.*:$/\1/p" \
< "$SQUASH_MSG" | sed -ne '$p')+1))
echo "# This is a combination of $COUNT commits."
sed -e 1d -e '2,/^./{
--
1.6.6.rc1.31.g1a56b
^ permalink raw reply related
* Gui criticism
From: Ram Rachum @ 2009-12-05 18:51 UTC (permalink / raw)
To: git
Hello!
This is my first time on this list. I'm a Python developer who's been using git
for about a year. I generally like it, but I have several gripes about the GUI.
(My development machine is on Windows XP.) Would specifying these criticisms be
helpful to you?
Best Wishes,
Ram Rachum.
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-05 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Maarten Lankhorst, Junio C Hamano, git
In-Reply-To: <20091204111158.GE27495@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 03, 2009 at 12:30:46PM +0100, Maarten Lankhorst wrote:
>
>> When I was working on my code and made a mess that I wanted to undo,
>> I accidentally did it in the .git directory, and had a whole clone of
>> my last committed tree there.
>>
>> It can be triggered easily:
>>
>> mkdir test; cd test; git init; touch foo; git add foo; git commit -m
>> 'add foo'; cd .git; git reset --hard; [ -f foo ] && echo hello beauty
>>
>> Other parts of git could be affected, I haven't checked where exactly
>> the bug hides, so I was afraid to send in a patch
>
> Yuck. Thanks for the bug report. This is due to a too-loose check on my
> part in 49b9362 (git-reset: refuse to do hard reset in a bare
> repository, 2007-12-31).
>
> Junio, I think the following should go to maint (I didn't bother
> splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
> we don't care about maint releases that far back).
Although I'll apply your patch to 'maint' and will merge it for 1.6.6, I
am not quite sure if this is the best fix in the longer run. Shouldn't we
go back to the top of the work tree and running what was asked there?
^ permalink raw reply
* Re: Gui criticism
From: Michael J Gruber @ 2009-12-05 19:25 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Ram Rachum venit, vidit, dixit 05.12.2009 19:51:
> Hello!
>
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
No, unless they are specific bug reports.
The main problem is that we have too many GUIs, and the "main" ones are
in tcl/tk which not many people write. So there's a small developer base
for the standard GUI, and the rest prefers to split up and each do their
own GUI rather than work on a coordinated project. (I've tried to change
that before.)
Michael
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 19:37 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Hello Ram,
On Sat, Dec 5, 2009 at 8:51 PM, Ram Rachum <cool-rr@cool-rr.com> wrote:
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
I don't think the mailing list is the best place for this, that's why
I just started a project in SourceForge, so that users can post these
kinds of issues in the ideatorrent:
https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
I haven't made the announcement yet, but soon :)
--
Felipe Contreras
^ permalink raw reply
* Re: Speedlimit at "git clone"
From: Stefan Kuhne @ 2009-12-05 19:40 UTC (permalink / raw)
To: git
In-Reply-To: <4B17AA6B.7030000@access.denied>
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Stefan Kuhne schrieb:
Hello,
>
> how can i limit the download speed at "git clone"?
>
no one any idea?
Regards,
Stefan Kuhne
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]
^ permalink raw reply
* Re: Gui criticism
From: Martin Langhoff @ 2009-12-05 19:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
On Sat, Dec 5, 2009 at 8:37 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I don't think the mailing list is the best place for this
Mailing lists and face to face events are _the_ best places.
> I just started a project in SourceForge
A new project is for code. And the existing GUIs need help, your help,
in the already existing mailing lists and codebases they have.
>, so that users can post these
> kinds of issues
In a safe place where developers won't read?
> I haven't made the announcement yet, but soon :)
How about picking an existing git GUI project you're prepared to help,
and... just... help? Code, documentation, screen mockups, graphic art?
Is it too... normal? Maybe too... productive?
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I don't think the mailing list is the best place for this, that's why
> I just started a project in SourceForge, so that users can post these
> kinds of issues in the ideatorrent:
> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
Two issues and a half offhand after entering one:
- I found the experience of adding an "idea" too clunky and slow.
Writing a well thought out e-mail can be done in the same time.
- Although enforcing a minimum structure of "idea" description is a good
thing to do, I found the current structure presented by that web page
lacks focus. It has problem description and a rather broad and vague
"idea", and it feels to me that it is promoting entering any garbage
without discussing feasibility, "pros-and-cons" or necessary steps to
achieve a particular goal.
- The largest issue of this kind of system is who will be moderating and
how capable they are.
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ram Rachum, git
In-Reply-To: <7v3a3prxdt.fsf@alter.siamese.dyndns.org>
On Sat, Dec 5, 2009 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I don't think the mailing list is the best place for this, that's why
>> I just started a project in SourceForge, so that users can post these
>> kinds of issues in the ideatorrent:
>> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
>
> Two issues and a half offhand after entering one:
>
> - I found the experience of adding an "idea" too clunky and slow.
> Writing a well thought out e-mail can be done in the same time.
Yeah, I agree; it's too slow right now, but it's the only way I've
found to host some kind of ideastorm.
The difference with e-mails is that ideas get votes, which helps to
find out what users really want:
http://brainstorm.ubuntu.com/
Also, the main action to do in this system should be "vote", that's
the action that should be fast.
> - Although enforcing a minimum structure of "idea" description is a good
> thing to do, I found the current structure presented by that web page
> lacks focus. It has problem description and a rather broad and vague
> "idea", and it feels to me that it is promoting entering any garbage
> without discussing feasibility, "pros-and-cons" or necessary steps to
> achieve a particular goal.
That's why ideas go to a sandbox, and then maintainers approve or reject them.
> - The largest issue of this kind of system is who will be moderating and
> how capable they are.
Indeed, that's one issue, but also, it needs a large inflow of votes,
and when popular ideas are identified, then it needs people to
actually implement them.
--
Felipe Contreras
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:41 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051225y2d193a1fqfb38ebcce95719c3@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Also, the main action to do in this system should be "vote", that's
> the action that should be fast.
Actually I do not think you would want that, especially as a moderator (I
am assuming that you would be self-appointing to be one). What will you
do to help a "broad, vague, and infeasible idea" forward when it gets many
votes?
That is why I prefer a system that requires substance when voicing an
opinion ("Yes I like the solution because in addition to the original
problem description it will also help this use case"), and it also is the
reason I tend to ignore e-mails that only say "+1" on this list.
In other words, this is not a democracy, and you do not necessarily want a
democracy that is prone to populism.
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: David Aguilar @ 2009-12-05 20:44 UTC (permalink / raw)
To: Dilip M; +Cc: Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <c94f8e120912050832o6d43672bla3beb1e3cedd7db3@mail.gmail.com>
On Sat, Dec 05, 2009 at 10:02:08PM +0530, Dilip M wrote:
> On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
>
> > As for "missing", do you refer to "paid service", or "yet another GUI"?
>
> Ahaha! I can say "a good gui" :)
>
> I was not knowing that this was "paid service". I saw the screenshot
> and tried it. No doubt, it has a _great_ ui interface. While installation I
> realized that it is licensed.
>
> - SOFTWARE Non-Commercial License,
> - SOFTWARE Commercial License,
> - SOFTWARE Enterprise License.
Aside from the other good GUIs out there, have you tried
git-cola?
http://cola.tuxfamily.org/
It's GPL and not too shabby.
The screenshots on the webpage are a bit out of date, though.
I should probably get to writing the release announcment and
updating the screenshots ;)
It probably also depends on your platform of choice.
I know some Windows users like explorer-integration, so stuff
like git-cheetah make a lot of sense for them. I was a little
sad to see that the tortoise-git guys didn't get the joke
(who wants a tortoise when you have a cheetah?) and didn't
just work on cheetah instead, but hey, it's all good.
Another example: eclipse users like eclipse integration so for
them egit makes perfect sense.
Maybe that makes git-cola the poor man's smartgit?
If that's the case then it looks like the poor man is still
winning according to the feature matrix on the git wiki ;)
I don't know.. I haven't used smartgit, but if there are
any features that people are itching to have that git-cola
doesn't then feel free to throw it on the backlog:
http://github.com/davvid/git-cola/issues
At first glance, the gitk-like history widget in smartgit
is very nice. I've been thinking about how to implement that in
PyQt for a while but haven't yet hammered it out.
Have fun,
--
David
^ permalink raw reply
* Re: [PATCH] bash: update 'git commit' completion
From: Shawn O. Pearce @ 2009-12-05 21:17 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: Junio C Hamano, git
In-Reply-To: <1259974301-11593-1-git-send-email-szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> I just wanted to add the recently learnt '--reset-author' option, but
> then noticed that there are many more options missing. This patch
> adds support for all of 'git commit's options, except '--allow-empty',
> because it is primarily there for foreign scm interfaces.
>
> Furthermore, this patch also adds support for completing the arguments
> of those options that take a non-filename argument: valid modes are
> offered for '--cleanup' and '--untracked-files', while refs for
> '--reuse-message' and '--reedit-message', because these two take a
> commit as argument.
>
> Signed-off-by: SZEDER G??bor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH RESEND] git gui: make current branch default in "remote delete branch" merge check
From: Shawn O. Pearce @ 2009-12-05 21:18 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Junio C Hamano
In-Reply-To: <20091204212648.GA3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> We already do the same when locally deleting a branch.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>
> lib/remote_branch_delete.tcl | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:19 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Peter Baumann, Jeff Epler, git
In-Reply-To: <20091204220730.GB3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> On Thu, Oct 29, 2009 at 08:34:54AM +0100, Peter Baumann wrote:
> > Cc ing Shawn as the git gui maintainer, as he might have missed this series
> > during his away time.
>
> Ping? A short reminder for Shawn as I do not see the patches in his
> tree.
I have a stack of git-gui patches which I've just ignored in
my inbox. I'll work through them this afternoon.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Fix applying a line when all following lines are deletions
From: Shawn O. Pearce @ 2009-12-05 21:32 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <1256160023-29629-2-git-send-email-jepler@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> If a diff looked like
> @@
> context
> -del1
> -del2
> and you wanted to stage the deletion 'del1', the generated patch
> wouldn't apply because it was missing the line 'del2' converted to
> context, but this line was counted in the @@-line
> ---
> lib/diff.tcl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/lib/diff.tcl b/lib/diff.tcl
> index bd5d189..066755b 100644
> --- a/lib/diff.tcl
> +++ b/lib/diff.tcl
> @@ -664,6 +664,7 @@ proc apply_line {x y} {
> }
> set i_l $next_l
> }
> + set patch "$patch$pre_context"
Signed-off-by ?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:36 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091026193903.GA27319@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> I've found another problem, which I'll work on as soon as I find a
> chance.
>
> When staging multiple "+" lines preceded by a "-" line that must be
> turned into context, the converted "-" line must come after *all* the
> "+" lines, not just the first one.
So the reason this series got stuck was this message, this bug is
enough to suggest we shouldn't apply it to my tree yet, so I've
been waiting for an update on the topic.
Also, I need a Signed-off-by line.
--
Shawn.
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Shawn O. Pearce @ 2009-12-05 22:15 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg
In-Reply-To: <1250467128-29839-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> As promised a long time ago (March 30), version 3 of the small patchset
> to improve handling of repositories in git gui. The most significant
> change is the addition of the third patch.
...
> Giuseppe Bilotta (3):
> git-gui: handle non-standard worktree locations
> git-gui: handle bare repos correctly
> git-gui: work from the .git dir
>
> git-gui/git-gui.sh | 88 +++++++++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 73 insertions(+), 15 deletions(-)
Unfortunately this series doesn't apply to my tree, and I don't
have the blobs which are recorded in the index line, so I can't
easily 3-way merge it onto the current tip.
Would you be able to rebase it?
--
Shawn.
^ permalink raw reply
* Re: git-svn breakage on repository rename
From: Eric Wong @ 2009-12-05 22:22 UTC (permalink / raw)
To: Guido Stevens; +Cc: git, George Kuk
In-Reply-To: <4B197078.6050203@cosent.net>
Guido Stevens <guido.stevens@cosent.net> wrote:
> Hi Eric e.a.,
>
> I have a weird git-svn corner case that might interest you (or not at
> all). I'd appreciate any help or hints for moving beyond this problem.
>
> I'm using git-svn to do a full commit history analysis of the Zope +
> Plone CMS code bases as part of a research project with the University
> of Nottingham into open source knowledge dynamics.
>
> One of the repositories I'm importing breaks with a "Checksum mismatch",
> indicating a corruption. However, this error message occurs exactly at
> the point where the repository was renamed: from "Products.CMFPlone" to
> "Plone" (22715->22716). (Yes, it's the Plone core itself that resists
> analysis :-()
>
> The git-svn url for the later commits would be:
> http://svn-mirror.plone.org/svn/plone/Plone/trunk
>
> Whereas an older part of the code base lives at:
> http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk
>
> Funny thing is, git-svn detects this rename upfront but then breaks
> anyway. Which raises the questions:
>
> - is this breakage caused by the rename?
Hi Guido,
Yes. By default, git svn without --stdlayout does not attempt
to determine a repository root so parent following can be done.
On the other hand, Plone does appear to use a standard SVN layout.
> - or does git-svn handle the rename, and there is an actual corruption?
It should, let me know if the example I give below doesn't work
It looks like a big repo and they're worried about bandwidth:
"Do not make a checkout of the entire repository! This is likely to
get you blacklisted."
(ref: http://dev.plone.org/plone/wiki/RepoInfo)
> - is there any way I can work around this and get a valid or semi-valid
> git history for this project?
>
> I don't mind missing a few commits, since I'm not doing code development
> on this repository, only statistical analysis.
I would mind very much if git svn missed commits :>
> Solving this would also be helpful for anyone who wants to work on Plone
> development through git rather than through raw svn.
>
> :*CU#
>
> ----------------------------------------------------
> To reconstruct this error:
> ----------------------------------------------------
>
> $ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
> $ cd Plone
> $ git svn fetch
Since Plone appears to use a standard trunk/branches/tags layout
recommended by SVN developers, can you try this instead?:
git svn clone -s http://svn-mirror.plone.org/svn/plone/Plone
If you don't care about branches/tags at all, you can also try
git svn clone --no-follow-parent \
https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
Also, in the future it'd be nice to know which version of git svn
you're using since bugs may be fixed in a newer version. Thanks!
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Eric Wong @ 2009-12-05 22:32 UTC (permalink / raw)
To: Sam Vilain, Alex Vandiver; +Cc: git
In-Reply-To: <1259786690-sup-8337@utwig>
Alex Vandiver <alex@chmrr.net> wrote:
> This hunk is wrong due to a mis-merge on my part -- the first 'push'
> line should have been removed, obviously. I'll wait for other
> comments before I push a v2, however.
Hi Alex,
I'll continue to defer to Sam for ack-ing SVK-related things.
One thing I am very picky about is wrapping lines at 80-columns or
less (hard tabs being 8 characters wide).
--
Eric Wong
^ permalink raw reply
* Re: svn svn returning 'fatal: Not a valid object name' on sourceforge svn repo
From: Eric Wong @ 2009-12-05 22:49 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p0624081ac73dd6a1aaff@[63.138.152.192]>
Stephen Bannasch <stephen.bannasch@deanbrook.org> wrote:
> I use git svn often and normally it works fine.
>
> I getting a fatal error trying to clone the asciimathm svn repo at sourceforge:
>
> $ git svn clone --trunk=trunk --branches=branches http://asciimathml.svn.sourceforge.net/svnroot/asciimathml asciimathml-svn-git
> fatal: Not a valid object name
> ls-tree -z ./: command returned error: 128
>
> Anybody seen this kind of problem before.
>
> A svn co works fine.
>
> I'm using git version 1.6.5.1 on mac os 10.5.8.
Hi Stephen,
Passing the "-r4:HEAD" parameter to "git svn clone" should work. It
looks like the repository was initially miscreated and "trunk" was a
symlink (and not a directory) in r1.
I have not yet thought of a good solution to this, yet...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 22:51 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20091205223241.GB2120@dcvr.yhbt.net>
At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> I'll continue to defer to Sam for ack-ing SVK-related things.
>
> One thing I am very picky about is wrapping lines at 80-columns or
> less (hard tabs being 8 characters wide).
*nod* I've fixed up my local copy for v2 to rewrap things at < 80
columns, and will keep that in mind for the future.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Sam Vilain @ 2009-12-05 22:59 UTC (permalink / raw)
To: Alex Vandiver; +Cc: Eric Wong, git
In-Reply-To: <1260052934-sup-9563@utwig>
On Sat, 2009-12-05 at 17:51 -0500, Alex Vandiver wrote:
> At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> > I'll continue to defer to Sam for ack-ing SVK-related things.
> >
> > One thing I am very picky about is wrapping lines at 80-columns or
> > less (hard tabs being 8 characters wide).
>
> *nod* I've fixed up my local copy for v2 to rewrap things at < 80
> columns, and will keep that in mind for the future.
Hi, I've just seen the series, looks like a good idea. Just a couple of
questions then I'll review the code;
- when a change is merged upstream with svk, you will get multiple log
entries in a single commit message. What do you do with commits like
that?
- there are quite a few repos which will have empty commits (ie, no
changes), but with one or more of the above log entries, owing to a bug
which I can't seem to find the details of right now.. how might those
appear?
Thanks for your submission!
Sam
^ 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