* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: David Kågedal @ 2007-12-13 14:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712130604r6daf05d5n7afbadfe23831839@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>> I have a fair amount of branches, and I noticed that "stg branch -l"
>> takes ridiculously long to finish.
>
> I have the same problem.
>
>> Maybe someone can help me find a quicker replacement for the
>> get_protected call?
Hey, why not put the "protected" flag in the config? Then we can get
it the same way as the other stuff.
Protecting a branch is a configuration action, so it makes sense to
put it in the config.
--
David Kågedal
^ permalink raw reply
* [PATCH] git-gui: Move frequently used commands to the top of the context menu.
From: Johannes Sixt @ 2007-12-13 14:39 UTC (permalink / raw)
To: Johannes Schindelin, Shawn O. Pearce
Cc: Junio C Hamano, Jason Sewall, David, Marco Costalba, Andy Parkins,
git
In-Reply-To: <Pine.LNX.4.64.0712131417110.27959@racer.site>
From: Johannes Sixt <johannes.sixt@telecom.at>
"Stage/Unstage Hunk" is probably the most frequently used command of the
patch context menu *and* it is not available in some other form than
the context menu. Therefore, it should go to the top. "Less Context" and
"More Context" entries are also not easily available otherwise, and are
therefore, moved second. The other entries are available via key strokes
(Copy, Paste, Refresh) or rarly used (Font Size, Options) and can go last.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Johannes Schindelin schrieb:
> On Thu, 13 Dec 2007, Johannes Sixt wrote:
>> It's probably sufficient to have an option "Stage this Line": Once you
>> have staged enough lines, the hunk will be split automatically by the
>> current number-of-context-lines setting.
>
> And your hand falls off... ;-)
Not with this patch.
And, obviously, "Stage this Line" is accompanied by "Unstage this Line".
So when you want to stage a lot *except* one line, then you better
stage the lot, then *unstage* one line.
-- Hannes
PS: Warning, Shawn: [ab]/git-gui.sh below is forged; you won't have
blob 95b9537.
git-gui.sh | 42 +++++++++++++++++++++---------------------
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 95b9537..8e3751f 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2542,6 +2542,27 @@ $ui_diff tag raise sel
set ctxm .vpane.lower.diff.body.ctxm
menu $ctxm -tearoff 0
$ctxm add command \
+ -label [mc "Apply/Reverse Hunk"] \
+ -command {apply_hunk $cursorX $cursorY}
+set ui_diff_applyhunk [$ctxm index last]
+lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
+$ctxm add separator
+$ctxm add command \
+ -label [mc "Show Less Context"] \
+ -command {if {$repo_config(gui.diffcontext) >= 1} {
+ incr repo_config(gui.diffcontext) -1
+ reshow_diff
+ }}
+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
+$ctxm add command \
+ -label [mc "Show More Context"] \
+ -command {if {$repo_config(gui.diffcontext) < 99} {
+ incr repo_config(gui.diffcontext)
+ reshow_diff
+ }}
+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
+$ctxm add separator
+$ctxm add command \
-label [mc Refresh] \
-command reshow_diff
lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
@@ -2563,12 +2584,6 @@ $ctxm add command \
lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
$ctxm add separator
$ctxm add command \
- -label [mc "Apply/Reverse Hunk"] \
- -command {apply_hunk $cursorX $cursorY}
-set ui_diff_applyhunk [$ctxm index last]
-lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
-$ctxm add separator
-$ctxm add command \
-label [mc "Decrease Font Size"] \
-command {incr_font_size font_diff -1}
lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
@@ -2577,21 +2592,6 @@ $ctxm add command \
-command {incr_font_size font_diff 1}
lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
$ctxm add separator
-$ctxm add command \
- -label [mc "Show Less Context"] \
- -command {if {$repo_config(gui.diffcontext) >= 1} {
- incr repo_config(gui.diffcontext) -1
- reshow_diff
- }}
-lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
-$ctxm add command \
- -label [mc "Show More Context"] \
- -command {if {$repo_config(gui.diffcontext) < 99} {
- incr repo_config(gui.diffcontext)
- reshow_diff
- }}
-lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
-$ctxm add separator
$ctxm add command -label [mc "Options..."] \
-command do_options
proc popup_diff_menu {ctxm x y X Y} {
--
1.5.3.7.1929.gf9f0a
^ permalink raw reply related
* Re: Something is broken in repack
From: Paolo Bonzini @ 2007-12-13 15:32 UTC (permalink / raw)
To: git; +Cc: gcc
In-Reply-To: <fcaeb9bf0712130532s79aa7afeve6f018f9430ab3b3@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On Dec 12, 2007 10:48 PM, Nicolas Pitre <nico@cam.org> wrote:
>> In the mean time you might have to use only one thread and lots of
>> memory to repack the gcc repo, or find the perfect memory allocator to
>> be used with Git. After all, packing the whole gcc history to around
>> 230MB is quite a stunt but it requires sufficient resources to
>> achieve it. Fortunately, like Linus said, such a wholesale repack is not
>> something that most users have to do anyway.
>
> Is there an alternative to "git repack -a -d" that repacks everything
> but the first pack?
That would be a pretty good idea for big repositories. If I were to
implement it, I would actually add a .git/config option like
pack.permanent so that more than one pack could be made permanent; then
to repack really really everything you'd need "git repack -a -a -d".
Paolo
^ permalink raw reply
* Inconsistency in use of "--bare" between init & clone
From: Joe Ratterman @ 2007-12-13 15:37 UTC (permalink / raw)
To: git
I've been getting ready to support my organization in a change-over to
git from cvs, and I've found a strange issue when creating bare
repositories. The placement of the "--bare" option changes:
git --bare clone <url> == "--bare" is silently ignored
git --bare init == Creates an empty bare repo
git clone --bare == Clones the url into a new bare repo
git init --bare == Error:
usage: git-init [-q | --quiet]
[--template=<template-directory>] [--shared]
I assume there a reason for the lack of symmetry, but I don't understand it.
Thanks,
Joe
$ git version
git version 1.5.3.7.1157.gbf82a
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: Catalin Marinas @ 2007-12-13 15:38 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87lk7yr7ib.fsf@lysator.liu.se>
On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
> > On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> >> I have a fair amount of branches, and I noticed that "stg branch -l"
> >> takes ridiculously long to finish.
> >
> > I have the same problem.
> >
> >> Maybe someone can help me find a quicker replacement for the
> >> get_protected call?
>
> Hey, why not put the "protected" flag in the config? Then we can get
> it the same way as the other stuff.
>
> Protecting a branch is a configuration action, so it makes sense to
> put it in the config.
Yes, I'm OK with this. The only problem I see is that we have to
change the stgit.formatversion and provide an upgrade in the Series
object. However, 'stg branch -l' no longer initialises the Series
objects and the upgrade won't happen.
The branch command would have to check format version and force the
upgrade if it isn't the required one.
BTW, have you run stg-prof to check where it spends most of the time?
Is it caused by Python object creation or GIT calls invoked during the
Series objects initialisation. If the latter, we can turn some
variables into properties and access them lazily.
--
Catalin
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: Karl Hasselström @ 2007-12-13 16:04 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712130604r6daf05d5n7afbadfe23831839@mail.gmail.com>
On 2007-12-13 14:04:26 +0000, Catalin Marinas wrote:
> On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>
> > Maybe someone can help me find a quicker replacement for the
> > get_protected call?
>
> We can have the standard --list command which ignores the protected
> flag
Exactly what is the p flag useful for anyway?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: David Kågedal @ 2007-12-13 16:08 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712130738s18ad303fu17a8412097377900@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> BTW, have you run stg-prof to check where it spends most of the time?
> Is it caused by Python object creation or GIT calls invoked during the
> Series objects initialisation. If the latter, we can turn some
> variables into properties and access them lazily.
I ran with STG_SUBPROCESS_LOG=debug and noticed that there were four
invokations of git for each branch it listed, in addition to the ten
invokation before it even starts to list the branches.
So I focused on replacing those 4xN invokations with 2 invokations,
and it helped a lot. But I'm sure there are still lots of things to
improve.
Actually, I didn't know about stg-prof.
--
David Kågedal
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: Karl Hasselström @ 2007-12-13 16:08 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, git
In-Reply-To: <87lk7yr7ib.fsf@lysator.liu.se>
On 2007-12-13 15:31:24 +0100, David Kågedal wrote:
> Hey, why not put the "protected" flag in the config? Then we can get
> it the same way as the other stuff.
>
> Protecting a branch is a configuration action, so it makes sense to
> put it in the config.
I agree; if we are to have such a flag, the config is the right place
for it.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: Catalin Marinas @ 2007-12-13 16:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071213160432.GA30693@diana.vm.bytemark.co.uk>
On 13/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-13 14:04:26 +0000, Catalin Marinas wrote:
>
> > On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> >
> > > Maybe someone can help me find a quicker replacement for the
> > > get_protected call?
> >
> > We can have the standard --list command which ignores the protected
> > flag
>
> Exactly what is the p flag useful for anyway?
It was added so that you don't rebase the stack by mistake. Yann
suggested to have a specific policy for this and make the protected
flag freeze the stack completely.
--
Catalin
^ permalink raw reply
* [BUG] Failed to make install-info
From: Jon Loeliger @ 2007-12-13 15:38 UTC (permalink / raw)
To: git
Guys,
I managed to fail to install info files during:
/usr/src/git# make prefix=/usr install-info
The /usr/share/info/dir file is readable. But it
looks like our build isn't supplying a description
that is needed by install-info? Is my info really
old or something?
This is:
1693 % pwd
/usr/src/git
1694 % git describe
v1.5.4-rc0
1695 % git rev-parse HEAD
1e8df762b38e01685f3aa3613e2d61f73346fcbe
and:
1698 % install-info --version
Debian install-info version 1.14.5.
Thanks,
jdl
make -C Documentation install-info
make[1]: Entering directory `/usr/src/git/Documentation'
rm -f doc.dep+ doc.dep
/usr/bin/perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make -C ../ GIT-VERSION-FILE
make[2]: Entering directory `/usr/src/git'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/usr/src/git'
make[1]: Leaving directory `/usr/src/git/Documentation'
make[1]: Entering directory `/usr/src/git/Documentation'
make -C ../ GIT-VERSION-FILE
make[2]: Entering directory `/usr/src/git'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/usr/src/git'
install -d -m 755 /usr/share/info
install -m 644 git.info gitman.info /usr/share/info
if test -r /usr/share/info/dir; then \
install-info --info-dir=/usr/share/info git.info ;\
install-info --info-dir=/usr/share/info gitman.info ;\
else \
echo "No directory found in /usr/share/info" >&2 ; \
fi
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(git.info): unable to determine description for `dir' entry - giving up
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(gitman.info): unable to determine description for `dir' entry - giving up
make[1]: *** [install-info] Error 1
make[1]: Leaving directory `/usr/src/git/Documentation'
make: *** [install-info] Error 2
^ permalink raw reply
* [PATCH] git-svn: unlink internal index files after operations
From: Eric Wong @ 2007-12-13 16:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Being git, we can generate these very quickly on the fly as
needed, so there's no point in wasting space for these things
for large projects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 54d7844..fde39e2 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -396,6 +396,7 @@ sub cmd_set_tree {
}
$gs->set_tree($_) foreach @revs;
print "Done committing ",scalar @revs," revisions to SVN\n";
+ unlink $gs->{index};
}
sub cmd_dcommit {
@@ -514,6 +515,7 @@ sub cmd_dcommit {
$last_rev = $cmt_rev;
}
}
+ unlink $gs->{index};
}
sub cmd_find_rev {
@@ -1374,6 +1376,7 @@ sub fetch_all {
($base, $head) = parse_revision_argument($base, $head);
$ra->gs_fetch_loop_common($base, $head, \@gs, \@globs);
+ unlink $_->{index} foreach @gs;
}
sub read_all_remotes {
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 0/2] [RFT] git-svn: more efficient revision -> commit mapping
From: Eric Wong @ 2007-12-13 16:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git, Harvey Harrison
In-Reply-To: <47609BF9.4030005@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Eric Wong wrote:
> > Sam (or anybody else using useSvmProps:
> >
> > Do you have any feedback with svmProps enabled?
>
> 3682645 120 -rw-rw-r-- 1 samv samv 121893 Dec 13 14:05
> tags/debian_version_1_2_0beta1@2972/.rev_db.d29f7b36-84ff-0310-85ce-ba787dbd31ca
>
> =>
>
> -3683050 4 -rw-rw-r-- 1 samv samv 48 Dec 13 14:26
> ./tags/debian_version_1_2_0beta1@2972/.rev_map.d29f7b36-84ff-0310-85ce-ba787dbd31ca
>
> git-log --all | grep git-svn | tail -3
>
> git-svn-id:
> file:///home/samv/.svk/local/mirror/fai/branches/source-dist@2971
> d29f7b36-84ff-0310-85ce-ba787dbd31ca
> git-svn-id: svn+ssh://svn.debian.org/svn/fai/trunk@2
> ba5ec265-b0fb-0310-8e1a-cf9e4c2b1591
> git-svn-id: svn+ssh://svn.debian.org/svn/fai/trunk@1
> ba5ec265-b0fb-0310-8e1a-cf9e4c2b1591
>
> So, the remapping is still working fine.
Hi Sam, nice.
> The one that failed there is not a new bug. Here's the fix anyway
> though :-)
>
> Subject: [PATCH] git-svn: fix --use-svm-props and --follow-parent
>
> If, when using --follow-parent, it finds that the parent is an SVM
> path, *and* the SVM path is not at the root of the corresponding SVN
> repository (the usual case when using SVK), then the logic in
> Git::SVN::ra will not find the correct source repository. This is
> because the freshly created RA object is missing the path. So, set
> this after creation.
This seems to break the non-useSvmProps case (in t9104). I'll look more
at it later.
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 54d7844..3e5fd82 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2189,6 +2189,7 @@ sub find_parent_branch {
> $ref_id .= '-' while find_ref($ref_id);
> print STDERR "Initializing parent: $ref_id\n";
> $gs = Git::SVN->init($new_url, '', $ref_id, $ref_id, 1);
> + $gs->{path} = $branch_from;
> }
> my ($r0, $parent) = $gs->find_rev_before($r, 1);
> if (!defined $r0 || !defined $parent) {
--
Eric Wong
^ permalink raw reply
* Re: Something is broken in repack
From: Paolo Bonzini @ 2007-12-13 16:29 UTC (permalink / raw)
Cc: git, gcc
In-Reply-To: <fjrj9k$n6k$1@ger.gmane.org>
>> Is there an alternative to "git repack -a -d" that repacks everything
>> but the first pack?
>
> That would be a pretty good idea for big repositories. If I were to
> implement it, I would actually add a .git/config option like
> pack.permanent so that more than one pack could be made permanent; then
> to repack really really everything you'd need "git repack -a -a -d".
Actually there is something like this, as seen from the source of
git-repack:
for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
| sed -e 's/^\.\///' -e 's/\.pack$//'`
do
if [ -e "$PACKDIR/$e.keep" ]; then
: keep
else
args="$args --unpacked=$e.pack"
existing="$existing $e"
fi
done
So, just create a file named as the pack, but with extension ".keep".
Paolo
^ permalink raw reply
* Re: git-svn: expand handling of From: and Signed-off-by:
From: Eric Wong @ 2007-12-13 16:32 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git, Junio C Hamano
In-Reply-To: <20071213065815.GH30608@shadowen.org>
Andy Whitcroft <apw@shadowen.org> wrote:
> The current parsing for From: and Signed-off-by: lines handles fully
> specified names:
>
> From: Full Name <email@address>
>
> Expand this to include the raw email addresses and straight "names":
>
> From: email@address -> email <email@address>
> From: Full Name -> Full Name <unknown>
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Some minor whitespace damage (which Junio can fix up), but
Acked-by: Eric Wong <normalperson@yhbt.net>
Thanks Andy.
> ---
> git-svn.perl | 17 +++++++++++++----
> 1 files changed, 13 insertions(+), 4 deletions(-)
> diff --git a/git-svn.perl b/git-svn.perl
> index 54d7844..058f8e9 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2363,11 +2363,20 @@ sub make_log_entry {
>
> my ($commit_name, $commit_email) = ($name, $email);
> if ($_use_log_author) {
> - if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
> - ($name, $email) = ($1, $2);
> - } elsif ($log_entry{log} =~
> - /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
> + my $name_field;
> + if ($log_entry{log} =~ /From:\s+(.*\S)\s*\n/i) {
> + $name_field = $1;
> + } elsif ($log_entry{log} =~ /Signed-off-by:\s+(.*\S)\s*\n/i) {
> + $name_field = $1;
> + }
> + if (!defined $name_field) {
> + #
> + } elsif ($name_field =~ /(.*?)\s+<(.*)>/) {
> ($name, $email) = ($1, $2);
> + } elsif ($name_field =~ /(.*)@/) {
^ spaces before tab here
> + ($name, $email) = ($1, $name_field);
> + } else {
> + ($name, $email) = ($name_field, 'unknown');
> }
> }
> if (defined $headrev && $self->use_svm_props) {
--
Eric Wong
^ permalink raw reply
* Re: Something is broken in repack
From: Johannes Sixt @ 2007-12-13 16:39 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, gcc
In-Reply-To: <fjrj9k$n6k$1@ger.gmane.org>
Paolo Bonzini schrieb:
> Nguyen Thai Ngoc Duy wrote:
>> On Dec 12, 2007 10:48 PM, Nicolas Pitre <nico@cam.org> wrote:
>>> In the mean time you might have to use only one thread and lots of
>>> memory to repack the gcc repo, or find the perfect memory allocator to
>>> be used with Git. After all, packing the whole gcc history to around
>>> 230MB is quite a stunt but it requires sufficient resources to
>>> achieve it. Fortunately, like Linus said, such a wholesale repack is not
>>> something that most users have to do anyway.
>>
>> Is there an alternative to "git repack -a -d" that repacks everything
>> but the first pack?
>
> That would be a pretty good idea for big repositories. If I were to
> implement it, I would actually add a .git/config option like
> pack.permanent so that more than one pack could be made permanent; then
> to repack really really everything you'd need "git repack -a -a -d".
It's already there: If you have a pack .git/objects/pack/pack-foo.pack, then
"touch .git/objects/pack/pack-foo.keep" marks the pack as precious.
-- Hannes
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: David Kågedal @ 2007-12-13 16:39 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712130810p35b33e6aj7756b1af1922992b@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 13/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> On 2007-12-13 14:04:26 +0000, Catalin Marinas wrote:
>>
>> > On 13/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>> >
>> > > Maybe someone can help me find a quicker replacement for the
>> > > get_protected call?
>> >
>> > We can have the standard --list command which ignores the protected
>> > flag
>>
>> Exactly what is the p flag useful for anyway?
>
> It was added so that you don't rebase the stack by mistake. Yann
> suggested to have a specific policy for this and make the protected
> flag freeze the stack completely.
I'd be much more interested in a flag that prevents me from running
"git rebase" on a stg-controlled branch by mistake...
--
David Kågedal
^ permalink raw reply
* Re: git-svn init from Avogadro SVN repo - deleted files showing
From: Eric Wong @ 2007-12-13 16:41 UTC (permalink / raw)
To: Peter Baumann; +Cc: Marcus D. Hanwell, git
In-Reply-To: <20071210104235.GA7521@xp.machine.xx>
Peter Baumann <waste.manager@gmx.de> wrote:
> On Sun, Dec 09, 2007 at 07:24:40PM -0500, Marcus D. Hanwell wrote:
> > Hi,
> >
> > I am quite new to git and git-svn but have been using both for my
> > development work recently. I imported the Avogadro subversion repository
> > (hosted on Sourceforge) using the following commands,
> >
> > git svn init -t tags -b branches -T trunk
> > https://avogadro.svn.sourceforge.net/svnroot/avogadro
> >
> > git svn fetch
> >
> >
> > The files avogadro.pro and README in the trunk/ directory appear in my
> > imported git repository but not in Avogadro subversion trunk. We also had
> > trunk/src/ and all its files/subdirectories appearing in the git checkout
> > but not in subversion trunk. We deleted this using git and git svn which
> > removed it from the git checkouts too after r858.
> >
> > I have been talking to Peter who confirmed this and pointed out that the
> > repo was reorganised several times in the past. Please CC me on replies as
> > I am not on the list. There is a copy of my git repo at
> > http://platinum.cryos.net/avogadro.git/ if you would rather skip the
> > import. Other than that everything has been working great. It would be good
> > to get rid of this bug if possible. Let me know if there is anything else I
> > can do to help.
> >
>
> [ Eric Cc'ed, as the author of git-svn ]
>
> I can confirm that this looks like an import problem.
> (e.g see svn log -v -r33:78 https://avogadro.svn.sourceforge.net/svnroot/avogadro)
>
> I did my analysis on the file /trunk/avogadro.pro, because the error
> happens really early in the history so could just import up to revision 76
> to see what goes wrong. (The file gets never deleted in the import, as it
> should be!)
>
>
>
> trunk/avogadro.pro is added here:
>
> ------------------------------------------------------------------------
> r33 | dcurtis3 | 2006-08-21 07:34:10 +0200 (Mon, 21 Aug 2006) | 3 lines
> Changed paths:
> A /trunk/avogadro.pro
>
> Does a recursive build.
>
>
> Here the refactoring starts (a new directory not tracked by git is added):
> ------------------------------------------------------------------------
> r66 | dcurtis3 | 2007-01-03 06:42:45 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro
>
> Making room for libavogadro.
>
>
> /branches is moved to /avogadro/branches
> ------------------------------------------------------------------------
> r67 | dcurtis3 | 2007-01-03 06:47:11 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/branches (from /branches:66)
> D /branches
>
> Making room for libavogadro
>
>
>
>
> ERROR HAPPENS HERE:
> ====================
>
> /trunk and /tags are moved, too.
> (/trunk/avogadro.pro becomes /avogadro/trunk/avogadro.pro):
> ------------------------------------------------------------------------
> r68 | dcurtis3 | 2007-01-03 06:47:34 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/tags (from /tags:66)
> A /avogadro/trunk (from /trunk:66)
> D /tags
> D /trunk
>
> Making room for libavogadro.
>
> The above delete/move of trunk isn't recorded anywhere in the git svn import.
> 'git-svn find-rev r66' doesn't produce any output!
> And later git-svn thinks that /trunk and all its files are still there, so
> e.g. /trunk/avogadro.pro stays in the repo forever.
Hi,
Thanks for the analysis, Peter.
git-svn ignores deletions to the directory we're tracking in order to
represent renames when the follow-parent case is hit.
Unfortunately, this never took into account the directory we're tracking
reappearing later in history. I'll try to have a fix later tonight or
over the weekend.
> mv /avogadro/trunk/avogadro.pro /trunk/avogadro/avogadro.pro
> ------------------------------------------------------------------------
> r75 | dcurtis3 | 2007-01-03 20:49:35 +0100 (Wed, 03 Jan 2007) | 2 lines
> Changed paths:
> D /avogadro
> D /avogadro-lib
> A /branches
> A /tags
> A /trunk
> A /trunk/avogadro (from /avogadro/trunk:74)
> A /trunk/libavogadro (from /avogadro-lib/trunk:74)
>
> Moving things around. Conforming to a more KDE-like layout in SVN.
> I'm going nuts. SOrry
Instead of handling the full delete of everything in r68, I think I'll
make it so importing r75 will clobber all the stuff in trunk/ we ignored
deleting in r68 before adding the contents of trunk/ in r75.
--
Eric Wong
^ permalink raw reply
* Re: [StGit RFC] Make "stg branch -l" faster by getting all git config information in one call
From: Karl Hasselström @ 2007-12-13 17:04 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, git
In-Reply-To: <878x3yr1ka.fsf@lysator.liu.se>
On 2007-12-13 17:39:49 +0100, David Kågedal wrote:
> I'd be much more interested in a flag that prevents me from running
> "git rebase" on a stg-controlled branch by mistake...
In the long run, we probably want to figure out a good set of hooks in
git that would let us know when interesting stuff happens. And then
add them. The challenge will be to keep the number of hooks down.
In the short run, we need a general "undo" command. (I've got one on
the drawing board. Just need to set aside some time ...)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Junio C Hamano @ 2007-12-13 17:40 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Jeff King, git
In-Reply-To: <20071213093536.GC12398@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> In fact we have kind of the issue for every single optional argument out
> there:
>
> $ git describe --abbrev HEAD
> error: option `abbrev' expects a numerical value
> [...]
>
> *ouch*
>
> So I believe that with optional arguments we must change the way we do
> things, and that we _must_ enforce the argument to be sticked in that
> case.
I think "Must" is a bit too strong an expression.
git describe --abbrev 7 HEAD
git describe --abbrev HEAD
git describe --abbrev=HEAD
git describe --abbrev=7 HEAD
git describe --abbrev
The --abbrev parser in this case could be asked with this question: "You
are on the command line. There is a token after you. Is it your
parameter?".
Among the above cases, the third one through the last one will get slightly
different questions. The third and fourth ones get "You are given this
parameter and it must be yours", and the last one gets "You are on the
command line, and were not given any parameter."
The parser can do one of these things:
* Inspect the token, if exists, and see if it is appropriate for it.
* If not
- if it is optional, then take the default value, and answer "I
handled myself Ok, but that HEAD is not mine";
- if it "must be yours" (the third case), barf.
* If so
- Use that given value and answer "I handled myself Ok, and that
parameter 7 is mine"; this includes the fourth case as well.
And this does not have to be callback for common types like integers.
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Pierre Habouzit @ 2007-12-13 18:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vbq8u4ho8.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > In fact we have kind of the issue for every single optional argument out
> > there:
> >
> > $ git describe --abbrev HEAD
> > error: option `abbrev' expects a numerical value
> > [...]
> >
> > *ouch*
> >
> > So I believe that with optional arguments we must change the way we do
> > things, and that we _must_ enforce the argument to be sticked in that
> > case.
>
> I think "Must" is a bit too strong an expression.
>
> git describe --abbrev 7 HEAD
> git describe --abbrev HEAD
> git describe --abbrev=HEAD
> git describe --abbrev=7 HEAD
> git describe --abbrev
>
> The --abbrev parser in this case could be asked with this question: "You
> are on the command line. There is a token after you. Is it your
> parameter?".
I thought of that, but it's really convoluted and can definitely lead
to very subtle issues. The number of git commands with optional
arguments is quite low, mostly due to legacy, I don't expect _new_
commands to take optional arguments. I don't really like the ambiguity
it creates, and in some cases you just won't be able to disambiguate at
all. Here it looks nice because --abbrev takes an integer argument, and
it's likely that no branch nor reference names will be only made of
digits. Though for commands taking an optional string[0] argument this is
way more fishy.
*I* (and it's my opinion, maybe other don't see it that way) see the
parse-option module as a convenience given to people using the CLI UI in
an interactive shell. So it tries to achieve a good balance between
brevity and error detection. Here I think it's quite error prone and
gives almost no help to the user: if there is a gain to type git repack
-afd vs. git repack -a -f -d, I see no real gain in --abbrev 10 vs.
--abbrev=10.
[0] OTOH I'm not sure there will ever be optional arguments that
aren't integers in git, but I may be wrong.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git config --get-regexp exit status
From: Junio C Hamano @ 2007-12-13 18:06 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <871w9qsoc8.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> David Kågedal <davidk@lysator.liu.se> writes:
> ...
> One thing that annoyed me what that "git config --get-regexp" will
> return zero, one, or more matches, which are all valid reponses. But
> it treats the zero-match special and return an exit status of 1.
>
> Is that a conscious choice, or just an effect of how "git config
> --get" works?
>
> Since zero matches isn't really an error, I would like the exit status
> to be 0. At least for this use case :-)
I would imagine "matching variant" may want to signal "I did not match
anything" as a special event, just like grep does. As long as the
caller can distinguish "no match" from real failure cases (say, not in a
git repository and hence no configuration file), that is one valid use
of status code.
I haven't been annoyed by that myself, but I see what you mean. "give
me all the matching ones" callers would want to consider zero match and
seven matches both the same way as non errors. And similarity to "grep"
does not extend very far because there is no "--get-regexp" variant that
is quiet (i.e. "no output, just checking if there is a match").
So I do not mind if --get-regexp considered zero matches as non-error
myself. If an existing script did something like:
if list=$(git config --get-regexp '$pattern')
then
# use list, without verifying if it is empty
...
fi
such a change would break it, though. But the script should have been
doing:
LF='
'
if list=$(git config --get-regexp '$pattern')
then
IFS="$LF"
for $list
do
...
done
fi
anyway, so...
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Pierre Habouzit @ 2007-12-13 18:07 UTC (permalink / raw)
To: Junio C Hamano, Jeff King, git
In-Reply-To: <20071213180347.GE1224@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
On Thu, Dec 13, 2007 at 06:03:47PM +0000, Pierre Habouzit wrote:
> On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:
> > Pierre Habouzit <madcoder@debian.org> writes:
> >
> > > In fact we have kind of the issue for every single optional argument out
> > > there:
> > >
> > > $ git describe --abbrev HEAD
> > > error: option `abbrev' expects a numerical value
> > > [...]
> > >
> > > *ouch*
> > >
> > > So I believe that with optional arguments we must change the way we do
> > > things, and that we _must_ enforce the argument to be sticked in that
> > > case.
> >
> > I think "Must" is a bit too strong an expression.
> >
> > git describe --abbrev 7 HEAD
> > git describe --abbrev HEAD
> > git describe --abbrev=HEAD
> > git describe --abbrev=7 HEAD
> > git describe --abbrev
> >
> > The --abbrev parser in this case could be asked with this question: "You
> > are on the command line. There is a token after you. Is it your
> > parameter?".
The other issue is that when you had --abbrev=foo or --abbrev foo, the
first one has to generate an error, whereas the second one should just
say "foo" is not for me. The point being that the callback is not really
aware of how the argument got assigned to it.
That means that we will have to pass more flags to callabacks, making it
less easy to write them. Again, I'm not sure that the coding hassle is
worth of the small gain.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn init from Avogadro SVN repo - deleted files showing
From: Peter Baumann @ 2007-12-13 18:13 UTC (permalink / raw)
To: Eric Wong; +Cc: Marcus D. Hanwell, git
In-Reply-To: <20071213164134.GD18433@soma>
On Thu, Dec 13, 2007 at 08:41:34AM -0800, Eric Wong wrote:
> Peter Baumann <waste.manager@gmx.de> wrote:
> > On Sun, Dec 09, 2007 at 07:24:40PM -0500, Marcus D. Hanwell wrote:
> > > Hi,
> > >
> > > I am quite new to git and git-svn but have been using both for my
> > > development work recently. I imported the Avogadro subversion repository
> > > (hosted on Sourceforge) using the following commands,
> > >
> > > git svn init -t tags -b branches -T trunk
> > > https://avogadro.svn.sourceforge.net/svnroot/avogadro
> > >
> > > git svn fetch
> > >
> > >
> > > The files avogadro.pro and README in the trunk/ directory appear in my
> > > imported git repository but not in Avogadro subversion trunk. We also had
> > > trunk/src/ and all its files/subdirectories appearing in the git checkout
> > > but not in subversion trunk. We deleted this using git and git svn which
> > > removed it from the git checkouts too after r858.
> > >
> > > I have been talking to Peter who confirmed this and pointed out that the
> > > repo was reorganised several times in the past. Please CC me on replies as
> > > I am not on the list. There is a copy of my git repo at
> > > http://platinum.cryos.net/avogadro.git/ if you would rather skip the
> > > import. Other than that everything has been working great. It would be good
> > > to get rid of this bug if possible. Let me know if there is anything else I
> > > can do to help.
> > >
> >
> > [ Eric Cc'ed, as the author of git-svn ]
> >
> > I can confirm that this looks like an import problem.
> > (e.g see svn log -v -r33:78 https://avogadro.svn.sourceforge.net/svnroot/avogadro)
> >
> > I did my analysis on the file /trunk/avogadro.pro, because the error
> > happens really early in the history so could just import up to revision 76
> > to see what goes wrong. (The file gets never deleted in the import, as it
> > should be!)
> >
> >
> >
> > trunk/avogadro.pro is added here:
> >
> > ------------------------------------------------------------------------
> > r33 | dcurtis3 | 2006-08-21 07:34:10 +0200 (Mon, 21 Aug 2006) | 3 lines
> > Changed paths:
> > A /trunk/avogadro.pro
> >
> > Does a recursive build.
> >
> >
> > Here the refactoring starts (a new directory not tracked by git is added):
> > ------------------------------------------------------------------------
> > r66 | dcurtis3 | 2007-01-03 06:42:45 +0100 (Wed, 03 Jan 2007) | 3 lines
> > Changed paths:
> > A /avogadro
> >
> > Making room for libavogadro.
> >
> >
> > /branches is moved to /avogadro/branches
> > ------------------------------------------------------------------------
> > r67 | dcurtis3 | 2007-01-03 06:47:11 +0100 (Wed, 03 Jan 2007) | 3 lines
> > Changed paths:
> > A /avogadro/branches (from /branches:66)
> > D /branches
> >
> > Making room for libavogadro
> >
> >
> >
> >
> > ERROR HAPPENS HERE:
> > ====================
> >
> > /trunk and /tags are moved, too.
> > (/trunk/avogadro.pro becomes /avogadro/trunk/avogadro.pro):
> > ------------------------------------------------------------------------
> > r68 | dcurtis3 | 2007-01-03 06:47:34 +0100 (Wed, 03 Jan 2007) | 3 lines
> > Changed paths:
> > A /avogadro/tags (from /tags:66)
> > A /avogadro/trunk (from /trunk:66)
> > D /tags
> > D /trunk
> >
> > Making room for libavogadro.
> >
> > The above delete/move of trunk isn't recorded anywhere in the git svn import.
> > 'git-svn find-rev r66' doesn't produce any output!
> > And later git-svn thinks that /trunk and all its files are still there, so
> > e.g. /trunk/avogadro.pro stays in the repo forever.
>
> Hi,
>
> Thanks for the analysis, Peter.
>
> git-svn ignores deletions to the directory we're tracking in order to
> represent renames when the follow-parent case is hit.
>
> Unfortunately, this never took into account the directory we're tracking
> reappearing later in history. I'll try to have a fix later tonight or
> over the weekend.
>
> > mv /avogadro/trunk/avogadro.pro /trunk/avogadro/avogadro.pro
> > ------------------------------------------------------------------------
> > r75 | dcurtis3 | 2007-01-03 20:49:35 +0100 (Wed, 03 Jan 2007) | 2 lines
> > Changed paths:
> > D /avogadro
> > D /avogadro-lib
> > A /branches
> > A /tags
> > A /trunk
> > A /trunk/avogadro (from /avogadro/trunk:74)
> > A /trunk/libavogadro (from /avogadro-lib/trunk:74)
> >
> > Moving things around. Conforming to a more KDE-like layout in SVN.
> > I'm going nuts. SOrry
>
> Instead of handling the full delete of everything in r68, I think I'll
> make it so importing r75 will clobber all the stuff in trunk/ we ignored
> deleting in r68 before adding the contents of trunk/ in r75.
>
Sorry, that last sentence I can't parse/understand. But I trust you to do the
right thing.
-Peter
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Kristian Høgsberg @ 2007-12-13 18:28 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <20071213180347.GE1224@artemis.madism.org>
On Thu, 2007-12-13 at 19:03 +0100, Pierre Habouzit wrote:
> On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:
> > Pierre Habouzit <madcoder@debian.org> writes:
> >
> > > In fact we have kind of the issue for every single optional argument out
> > > there:
> > >
> > > $ git describe --abbrev HEAD
> > > error: option `abbrev' expects a numerical value
> > > [...]
> > >
> > > *ouch*
> > >
> > > So I believe that with optional arguments we must change the way we do
> > > things, and that we _must_ enforce the argument to be sticked in that
> > > case.
> >
> > I think "Must" is a bit too strong an expression.
> >
> > git describe --abbrev 7 HEAD
> > git describe --abbrev HEAD
> > git describe --abbrev=HEAD
> > git describe --abbrev=7 HEAD
> > git describe --abbrev
> >
> > The --abbrev parser in this case could be asked with this question: "You
> > are on the command line. There is a token after you. Is it your
> > parameter?".
>
> I thought of that, but it's really convoluted and can definitely lead
> to very subtle issues. The number of git commands with optional
> arguments is quite low, mostly due to legacy, I don't expect _new_
> commands to take optional arguments. I don't really like the ambiguity
> it creates, and in some cases you just won't be able to disambiguate at
> all. Here it looks nice because --abbrev takes an integer argument, and
> it's likely that no branch nor reference names will be only made of
> digits. Though for commands taking an optional string[0] argument this is
> way more fishy.
My
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Kristian Høgsberg @ 2007-12-13 18:47 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <1197570521.28742.0.camel@hinata.boston.redhat.com>
On Thu, 2007-12-13 at 13:28 -0500, Kristian Høgsberg wrote:
> On Thu, 2007-12-13 at 19:03 +0100, Pierre Habouzit wrote:
> > On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:
> > > Pierre Habouzit <madcoder@debian.org> writes:
> > >
> > > > In fact we have kind of the issue for every single optional argument out
> > > > there:
> > > >
> > > > $ git describe --abbrev HEAD
> > > > error: option `abbrev' expects a numerical value
> > > > [...]
> > > >
> > > > *ouch*
> > > >
> > > > So I believe that with optional arguments we must change the way we do
> > > > things, and that we _must_ enforce the argument to be sticked in that
> > > > case.
> > >
> > > I think "Must" is a bit too strong an expression.
> > >
> > > git describe --abbrev 7 HEAD
> > > git describe --abbrev HEAD
> > > git describe --abbrev=HEAD
> > > git describe --abbrev=7 HEAD
> > > git describe --abbrev
> > >
> > > The --abbrev parser in this case could be asked with this question: "You
> > > are on the command line. There is a token after you. Is it your
> > > parameter?".
> >
> > I thought of that, but it's really convoluted and can definitely lead
> > to very subtle issues. The number of git commands with optional
> > arguments is quite low, mostly due to legacy, I don't expect _new_
> > commands to take optional arguments. I don't really like the ambiguity
> > it creates, and in some cases you just won't be able to disambiguate at
> > all. Here it looks nice because --abbrev takes an integer argument, and
> > it's likely that no branch nor reference names will be only made of
> > digits. Though for commands taking an optional string[0] argument this is
> > way more fishy.
>
> My
Oops, sorry about that. I just wanted to say we shouldn't jump through
all these hoops to make the option parser support every type of option
there ever was in the git command line ui. A lot of these were probably
decided somewhat arbitrarily by whoever implemented the command.
Instead it's an opportunity to retroactively enforce some consistency
and predictability to the various option-styles that have been
hand-rolled over time in different git commands.
Kristian
^ 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