* possible code error at run_command.c
From: Frank Li @ 2009-12-21 6:46 UTC (permalink / raw)
To: git
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
int fdin[2], fdout[2], fderr[2];
int failed_errno = failed_errno;
I have not found failed_errno as global variable.
failed_errno = failed_errno means nothing.
It is possible coding error and should be
int failed_errno= 0 or
failed_errno=errno.
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-20 23:21 UTC (permalink / raw)
To: Karl Wiberg; +Cc: git, Gustav Hållberg
In-Reply-To: <b8197bcb0912191550u300a9c20o351eba66c85292bb@mail.gmail.com>
2009/12/19 Karl Wiberg <kha@treskal.com>:
> On Fri, Dec 18, 2009 at 4:49 PM, Catalin Marinas
> <catalin.marinas@gmail.com> wrote:
>
>> @@ -371,12 +369,10 @@ class StackTransaction(object):
>> # We've just caused conflicts, so we must allow them in
>> # the final checkout.
>> self.__allow_conflicts = lambda trans: True
>> -
>> - # Save this update so that we can run it a little later.
>> - self.__conflicting_push = update
>> + self.__patches = _TransPatchMap(self.__stack)
>> + update()
>> self.__halt("%d merge conflict(s)" % len(self.__conflicts))
>> else:
>> - # Update immediately.
>> update()
>>
>> def push_tree(self, pn):
>
> Better. But couldn't you remove the update function completely and
> just inline the code in it, since it's called immediately?
Of course, I tried, but couldn't get it to work. I get HEAD and top
not equal unless I call update() between _TransPatchMap and
self.__halt(). For the non-conflicting case we need to call update
before or after this "if merge_conflict".
One solution is to split the "if merge_conflict" in two but maybe you
have a better idea.
Thanks,
--
Catalin
^ permalink raw reply
* [ANNOUNCE] Git 1.6.6.rc4
From: Junio C Hamano @ 2009-12-20 22:59 UTC (permalink / raw)
To: git
A release candidate Git 1.6.6.rc4 is available at the usual places
for final testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc4-1.fc11.$arch.rpm (RPM)
Hopefully I'll do the final this Wednesday to make 1.6.6 a holiday gift to
everybody.
I would very much prefer news outlets like kernelpodcast.org and lwn.net
_not_ to say "... is released; it comes with many _fixes_". Fixes to
released versions have indeed been included in the 'master' branch, but
they all appear in the maintenance release. The main _point_ of using a
new feature release like 1.6.6 is to get new _features_, so it is more
appropriate to say "it comes with many new features."
Thanks for all contributors who have worked hard to whip this release into
shape.
----------------------------------------------------------------
Changes since v1.6.6-rc3 are as follows:
Björn Gustavsson (1):
rebase -i: abort cleanly if the editor fails to launch
Eric Wong (2):
git svn: make empty directory creation gc-aware
t9146: use 'svn_cmd' wrapper
Junio C Hamano (1):
Git 1.6.6-rc4
Stephen Boyd (2):
api-strbuf.txt: fix typos and document launch_editor()
technical-docs: document hash API
^ permalink raw reply
* Re: Efficiency and correctness patches for git-svn mergeinfo support
From: Andrew Myrick @ 2009-12-20 22:03 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Eric Wong
In-Reply-To: <1261343240.20752.20.camel@denix>
On Sun, Dec 20, 2009 at 1:07 PM, Sam Vilain <sam@vilain.net> wrote:
> On Sat, 2009-12-19 at 14:15 -0800, Andrew Myrick wrote:
>> I tried cloning from a fairly recent revision that I knew was after
>> our switchover to svn 1.5, and I received a number of these errors:
>>
>> Couldn't find revmap for [branch]
>> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>>
>> I'm not sure if this is expected, since I didn't clone from the whole
>> repo, but it did cause a lot of spew. I'm starting a fresh clone now,
>> but it takes a few days to get through the whole repository. I'm
>> fairly new to git, so I would welcome any tips on how I can test this
>> more quickly.
>
> Whoops, no, not expected, I'll post a minor correction. That means that
> the branch which was merged in does not have git-svn metadata; ie, it's
> not being tracked explicitly. If people are doing merging of things
> which aren't roots of branches you would expect this. SVN, like
> Perforce, supports a confusing amount of flexibility in its merge
> tracking. If [branch] is a real branch, then you'll want to see why it
> doesn't have metadata yet. Is it really a sub-tree of a real branch?
> You could fetch it independently using a separate git-svn remote, or you
> could ignore the warning; it should be relatively self-evident what
> happened from the merge message and the contents of the changeset.
I think the problem is that I started fetching from a later revision
than when the branch was created and reintegrated. There would be no
metadata for the branch, so a lookup for it would fail. Fetching the
branch explicitly, or fetching from r1 as my current test is doing,
should not experience this problem.
> Note if your repository was significantly re-organized at any point, it
> will pay to treat each section of history as a separate import project,
> and stitch the results together afterwards using grafts and
> filter-branch.
I don't believe it was, but I will keep that in mind if I run into
trouble. The import from r1 went fine with git v1.6.5.*, and it's
proceeding well now.
> This version should be *significantly* faster than the old one. ie, it
> should not take a minute per commit while importing the heavily
> merged-into integration branch. Possibly a few seconds at most.
So far, most commits are fetched in under 3s with your new version.
Thanks for your help, Sam.
-Andrew
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: memoize conversion of SVN merge ticket info to git commit ranges
From: Sam Vilain @ 2009-12-20 21:24 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <1261240435-8948-3-git-send-email-sam@vilain.net>
On Sun, 2009-12-20 at 05:33 +1300, Sam Vilain wrote:
> Each time the svn mergeinfo ticket changes, we look it up in the rev_map;
> when there are a lot of merged branches, this will result in many repeated
> lookups of the same information for subsequent commits. Arrange the slow
> part of the function so that it may be memoized, and memoize it. The more
> expensive revision walking operation can be memoized separately.
>
> Signed-off-by: Sam Vilain <sam@vilain.net>
> ---
> git-svn.perl | 91 ++++++++++++++++++++++++++++++++++-----------------------
> 1 files changed, 54 insertions(+), 37 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index a4b052c..3b17a83 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1634,6 +1634,7 @@ use Carp qw/croak/;
> use File::Path qw/mkpath/;
> use File::Copy qw/copy/;
> use IPC::Open3;
> +use Memoize; # core since 5.8.0, Jul 2002
>
> my ($_gc_nr, $_gc_period);
>
> @@ -2967,6 +2968,55 @@ sub find_extra_svk_parents {
> }
> }
>
> +sub lookup_svn_merge {
> + my $uuid = shift;
> + my $url = shift;
> + my $merge = shift;
> +
> + my ($source, $revs) = split ":", $merge;
> + my $path = $source;
> + $path =~ s{^/}{};
> + my $gs = Git::SVN->find_by_url($url.$source, $url, $path);
> + if ( !$gs ) {
> + warn "Couldn't find revmap for $url$source\n";
> + next;
> + }
As mentioned in the other thread, that 'next' should now be 'return'.
Sam
^ permalink raw reply
* Re: Efficiency and correctness patches for git-svn mergeinfo support
From: Sam Vilain @ 2009-12-20 21:07 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, Eric Wong
In-Reply-To: <6b2f9b1d0912191415n560a5a58xbe6390b1fcade854@mail.gmail.com>
On Sat, 2009-12-19 at 14:15 -0800, Andrew Myrick wrote:
> I tried cloning from a fairly recent revision that I knew was after
> our switchover to svn 1.5, and I received a number of these errors:
>
> Couldn't find revmap for [branch]
> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
> Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>
> I'm not sure if this is expected, since I didn't clone from the whole
> repo, but it did cause a lot of spew. I'm starting a fresh clone now,
> but it takes a few days to get through the whole repository. I'm
> fairly new to git, so I would welcome any tips on how I can test this
> more quickly.
Whoops, no, not expected, I'll post a minor correction. That means that
the branch which was merged in does not have git-svn metadata; ie, it's
not being tracked explicitly. If people are doing merging of things
which aren't roots of branches you would expect this. SVN, like
Perforce, supports a confusing amount of flexibility in its merge
tracking. If [branch] is a real branch, then you'll want to see why it
doesn't have metadata yet. Is it really a sub-tree of a real branch?
You could fetch it independently using a separate git-svn remote, or you
could ignore the warning; it should be relatively self-evident what
happened from the merge message and the contents of the changeset.
Note if your repository was significantly re-organized at any point, it
will pay to treat each section of history as a separate import project,
and stitch the results together afterwards using grafts and
filter-branch.
This version should be *significantly* faster than the old one. ie, it
should not take a minute per commit while importing the heavily
merged-into integration branch. Possibly a few seconds at most.
Sam
^ permalink raw reply
* Re: [msysGit] [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Junio C Hamano @ 2009-12-20 21:05 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Johannes Schindelin, Pat Thoyts, git, Shawn O. Pearce, msysgit
In-Reply-To: <a5b261830912201225q7d596b55qb54676922301954e@mail.gmail.com>
Pat Thoyts <patthoyts@googlemail.com> writes:
> 2009/12/20 Junio C Hamano <gitster@pobox.com>:
>>
>> On X, does the "default: thin borders, kind of windows98ish" look very
>> different from the non-themed classic Tk style?
>>
>
> Here is a big set of screenshots then:
Which is probably very helpful to others. Thanks.
On the other hand, if you wanted to give me just a quick answer, you
simply could have said "The default X11 theme looks like the good old
classic Tk that draws diamond shaped radio-buttons". (which is the
impression I got after running the current git-gui installation on my box
and comparing it with your "Tk 8.5 themed with unix default").
^ permalink raw reply
* Re: [msysGit] [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Pat Thoyts @ 2009-12-20 20:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Pat Thoyts, git, Shawn O. Pearce, msysgit
In-Reply-To: <7vws0ha2mt.fsf@alter.siamese.dyndns.org>
2009/12/20 Junio C Hamano <gitster@pobox.com>:
>
> On X, does the "default: thin borders, kind of windows98ish" look very
> different from the non-themed classic Tk style?
>
Here is a big set of screenshots then:
Unmodified or with Tk 8.4:
original windows: http://www.patthoyts.tk/screenshots/git-gui-old.png
original unix: http://www.patthoyts.tk/screenshots/git-gui-x11.png
With Tk 8.5 and using themed widgets:
unix default: http://www.patthoyts.tk/screenshots/git-gui-default.png
unix alt: http://www.patthoyts.tk/screenshots/git-gui-alt.png
unix classic: http://www.patthoyts.tk/screenshots/git-gui-classic.png
unix clam: http://www.patthoyts.tk/screenshots/git-gui-clam.png
unix tileqt: http://www.patthoyts.tk/screenshots/git-gui-tileqt.png
(experimental)
windows7: http://www.patthoyts.tk/screenshots/git-gui-win32.png
> What I am trying to get at is to gain enough information so that I can
> suggest a rewrite of these two lines (quoted at the beginning by Dscho)
> like this:
>
> Ttk defaults to the native look as much as possible on Windows and
> MacOSX; the default on X is the _________ look.
>
> The user may choose a theme by:
>
> - on Windows, doing ________;
> - on MacOSX, doing _________;
> - on X, selecting a theme using the TkTheme XRDB resource class;
>
> which I think would be much easier to read.
You write better than I do. The theme used globally by themed Tk can
be selected on at least Ubuntu's GNOME desktop by adding the following
line into ~/.Xresources:
*TkTheme: clam
It is also possible to add a Theme menu or selection combobox onto the
options dialog and record a theme selection along with the other
git-gui saved options. Then a user could use 'git config gui.theme
clam'. The set of available themes can be extended with packages and
is somewhat platform dependent (ie: xpnative can only be present on
Windows XP and above).
Pat Thoyts.
^ permalink raw reply
* Re: [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Junio C Hamano @ 2009-12-20 19:04 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Johannes Schindelin, Pat Thoyts, git, Shawn O. Pearce, msysgit
In-Reply-To: <a5b261830912200723s131f0b93w2f5ab94f19faf86a@mail.gmail.com>
Pat Thoyts <patthoyts@googlemail.com> writes:
> 2009/12/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>
>>> On Windows and MacOSX ttk defaults to the native look as much as possible.
>>> On X11 the user may select a theme using the TkTheme XRDB resource class.
>>
>> Maybe you could describe a quick way to set that resource?
>
> echo '*TkTheme: clam' | xrdb -merge -
>
> Or edit ~/.Xdefaults or maybe ~/.Xresources to add a line containing
> *TkTheme: clam
> Used to be the X resource database was the way to customize X11. The
> builtin themes are:
> default: thin borders, kind of windows98ish
> classic: motif style
> alt: more windowsy still.
> clam: based on some version of the XFCE look a few years ago.
On X, does the "default: thin borders, kind of windows98ish" look very
different from the non-themed classic Tk style?
What I am trying to get at is to gain enough information so that I can
suggest a rewrite of these two lines (quoted at the beginning by Dscho)
like this:
Ttk defaults to the native look as much as possible on Windows and
MacOSX; the default on X is the _________ look.
The user may choose a theme by:
- on Windows, doing ________;
- on MacOSX, doing _________;
- on X, selecting a theme using the TkTheme XRDB resource class;
which I think would be much easier to read.
^ permalink raw reply
* Re: [PATCH] rebase -i: print the editor name if it fails to launch
From: Junio C Hamano @ 2009-12-20 18:44 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B2DE132.1080700@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> I am not sure whether "git am" also should be modified
> to call git_editor_error_string. Currently it ignores
> any errors from the call to git_editor. Should it abort
> if there is an error or should it print a warning like this
>
> echo "Warning: $(git_editor_error_string)"
>
> if the editor fails to launch?
It probably is better, even though the lack of check there is not as
harmful compared to the one in "rebase -i" that annoyed you (which I also
see occasionally after freshly rebooting my environment, as I use
emacsclient like you do). You will be taken back to the "what now?"
interactive loop and have a chance to \C-c out of it. So such a patch
would help not in the sense that it would prevent the command from doing
what you didn't intend to (which is your "rebase -i" patch is about), but
in the sense that it hints what needs to be fixed once you break out of
the command.
> - git_editor "$TODO" ||
> - die_abort "Could not execute editor"
> + git_editor "$TODO" || die_abort "$(git_editor_error_string)"
Isn't this too elaborate? git_editor() has already run and when it
attempted to launch the editor it assigned to GIT_EDITOR in order to use
it as an eval string.
git_editor "$TODO" ||
die_abort "Failed to run '${GIT_EDITOR:-your editor}'"
would suffice, no?
The alternative string is for a case where "git var" gave an empty string,
or GIT_EDITOR was an empty string from the beginning.
^ permalink raw reply
* Re: [msysGit] [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Pat Thoyts @ 2009-12-20 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pat Thoyts, git, Shawn O. Pearce, msysgit
In-Reply-To: <alpine.DEB.1.00.0912201412420.4985@pacific.mpi-cbg.de>
2009/12/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> On Windows and MacOSX ttk defaults to the native look as much as possible.
>> On X11 the user may select a theme using the TkTheme XRDB resource class.
>
> Maybe you could describe a quick way to set that resource?
echo '*TkTheme: clam' | xrdb -merge -
Or edit ~/.Xdefaults or maybe ~/.Xresources to add a line containing
*TkTheme: clam
Used to be the X resource database was the way to customize X11. The
builtin themes are:
default: thin borders, kind of windows98ish
classic: motif style
alt: more windowsy still.
clam: based on some version of the XFCE look a few years ago.
On Windows you also get winnative, xpnative or vista but the intention
is that Tk just makes everything look native by selecting the correct
theme when it starts up. MacOSX gets an aqua theme. There is some work
in progress to get the Qt or Gtk styling engines to draw the ttk
elements so that it can pick up the current GNOME/KDE desktop -
effectively making it look native on such systems there too. However,
on Windows is where this stuff makes the most difference and works
best.
You can of course just run git-gui in any git repository to see how it
looks at the moment. However I put up another screenshot at
http://www.patthoyts.tk/screenshots/git-gui-old.png which is the
unmodified git-gui code with tcl8.5. The fonts look worse with 8.4
(even on windows).
> As to the patch: it is huge. I suspect that it would be easier to read
> and verify if it was done in two patches: the first one introducing helper
> procs that replace the existing repeated code, and a second patch that
> modifies only the helper procs to handle ttk if desired. You did that
> with pad_label, but that proc is not defined in a central place, but
> limited to about.tcl.
I could split it up but it is quite hard to validate without switching
themes to ensure you got everything. I toggle through some themes
looking for unchanged widgets or rogue borders.
I did find a bug in the choose_rev conversion when I rechecked with
tcl 8.4 so I will reissue this.
Pat Thoyts
^ permalink raw reply
* Re: [msysGit] [PATCH] git-gui: use themed tk widgets with Tk 8.5
From: Johannes Schindelin @ 2009-12-20 13:16 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Shawn O. Pearce, msysgit
In-Reply-To: <87my1ev4gi.fsf@users.sourceforge.net>
Hi,
On Sun, 20 Dec 2009, Pat Thoyts wrote:
> This patch enables the use of themed Tk widgets with Tk 8.5 and above.
> These make a significant difference on Windows in making the application
> appear native. The gui.usettk git config variable may be set to disable
> this if the user prefers the classic Tk look.
>
> On Windows and MacOSX ttk defaults to the native look as much as possible.
> On X11 the user may select a theme using the TkTheme XRDB resource class.
Maybe you could describe a quick way to set that resource?
> Some support is included for Tk 8.6 features (themed spinbox and native
> font chooser for MacOSX and Windows).
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>
> There is a screenshot of this running on Windows 7 at
> http://www.patthoyts.tk/screenshots/git-gui-win32.png
> It has been tested on Linux but not on MacOSX yet.
Please put this paragraph after the "---". Oh, and could you also include
a screenshot without ttk?
As to the patch: it is huge. I suspect that it would be easier to read
and verify if it was done in two patches: the first one introducing helper
procs that replace the existing repeated code, and a second patch that
modifies only the helper procs to handle ttk if desired. You did that
with pad_label, but that proc is not defined in a central place, but
limited to about.tcl.
Hmm?
Thanks,
Dscho
^ permalink raw reply
* Re: git svn clone just stops
From: Pascal Obry @ 2009-12-20 9:44 UTC (permalink / raw)
To: Eric Wong; +Cc: Mark Jerkovic, git
In-Reply-To: <20091220085731.GA11535@dcvr.yhbt.net>
Hi Eric,
> --revision may be passed to fetch, but its optional. fetch should
> always know where to pickup after it left off.
Ok, thanks for the info.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git svn clone just stops
From: Eric Wong @ 2009-12-20 8:57 UTC (permalink / raw)
To: Pascal Obry; +Cc: Mark Jerkovic, git
In-Reply-To: <4B2B990B.9060502@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
> > Not without error messages of some sort. git svn was designed with poor
> > network conditions in mind and clone is resumable, so you can just
> > resume like this:
> >
> > cd project.git && git svn fetch
>
> What about --revision option. I mean if I have this clone interrupted:
>
> $ git svn clone --revision=345:HEAD svn+ssh://...
>
> Should I specify --revision when restarting with fetch? I think I had an
> issue with this...
>
> Maybe some other options are also to be passed to fetch?
Hi Pascal,
--revision may be passed to fetch, but its optional. fetch should
always know where to pickup after it left off.
"git svn $command -h" shows you all options a particular $command
allows.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] rebase -i: print the editor name if it fails to launch
From: Björn Gustavsson @ 2009-12-20 8:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <4B2DE132.1080700@gmail.com>
Oops, I seem to have hit the Send button too early. Please ignore the
first email that stops in mid sentence.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: Delete a commit
From: Pascal Obry @ 2009-12-20 8:37 UTC (permalink / raw)
To: git
In-Reply-To: <20091220004340.GA30440@marge.bs.l>
Le 20/12/2009 01:43, Bertram Scharpf a écrit :
> % git fsck --lost-found
> dangling commit 6abc221327e896c850c56dafae92277bcfe68e2b
>
> It is still there. This is the one I want to delete.
Well, it is deleted (not accessible from any ref). It will be purged
from the repository at some point after a "git gc".
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* [PATCH] rebase -i: print the editor name if it fails to launch
From: Björn Gustavsson @ 2009-12-20 8:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The "git rebase -i" commands simply prints "Could not execute
editor" if the editor fails to launch.
Be a little bit more helpful and be consistent with the
built-in commands that use launch_editor() and also print
the name of the editor that failed to launch.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Here is a suggestion for how "git rebase -i" can be a
little bit more helpful if it fails to launch the editor.
This patch can be applied on top of my previous patch.
I am not sure whether "git am" also should be modified
to call git_editor_error_string. Currently it ignores
any errors from the call to git_editor. Should it abort
if there is an error or should it print a warning like this
echo "Warning: $(git_editor_error_string)"
if the editor fails to launch?
Grepping all *.sh files, I found no other references
to git_editor.
git-rebase--interactive.sh | 3 +--
git-sh-setup.sh | 9 +++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d529328..a08a813 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -778,8 +778,7 @@ EOF
die_abort "Nothing to do"
cp "$TODO" "$TODO".backup
- git_editor "$TODO" ||
- die_abort "Could not execute editor"
+ git_editor "$TODO" || die_abort "$(git_editor_error_string)"
has_action "$TODO" ||
die_abort "Nothing to do"
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dfcb807..36782ec 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -107,6 +107,15 @@ git_editor() {
eval "$GIT_EDITOR" '"$@"'
}
+git_editor_error_string() {
+ if test -z "${GIT_EDITOR:+set}"
+ then
+ GIT_EDITOR="$(git var GIT_EDITOR)" ||
+ (echo "No editor configured."; return 0)
+ fi
+ echo "There was a problem with the editor '$GIT_EDITOR'."
+}
+
sane_grep () {
GREP_OPTIONS= LC_ALL=C grep "$@"
}
--
1.6.6.rc3.2.ge3899
^ permalink raw reply related
* Re: [PATCH] rebase -i: abort cleanly if the editor fails to launch
From: Björn Gustavsson @ 2009-12-20 7:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wcy7kyc.fsf@alter.siamese.dyndns.org>
2009/12/19 Junio C Hamano <gitster@pobox.com>:
> Two questions:
>
> - Is emacsclient the _only_ editor that can exit with non-zero status to
> signal an error condition "the user invoked me to edit an existing
> file, but I ended up not letting the user edit it"?
I have no idea, but my guess is that it would only happen in
exceptional circumstances (e.g. a file system that has run out
of space).
> - Are there editors that let you exit with non-zero status on demand?
>
> The above is not a complaint to your log message, but is a genuine request
> for information.
>
> An editor that can exit with non-zero status on demand could use this
> codepath to abort the rebase, when a user realizes that the edit s/he has
> done so far was completely bogus [*1*]. In such a case, the existing
> error message "Could not execute editor" may sound funny.
Again, no idea, but I have never heard of such a feature. I think
that anyone advanced enough to use such a feature in an editor
would not be troubled by "Could not execute editor".
I mentioned emacsclient because it is a real annoyance
that has bitten me more than once (usually because I have
closed my local emacs while working on a remote computer
because I prefer to only keep windows that I am actively
working with), but my patch will help if the user has configured
a non-existent editor too (but such a problem usually
only happens once).
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH] rebase -i: abort cleanly if the editor fails to launch
From: Junio C Hamano @ 2009-12-20 7:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Björn Gustavsson, git
In-Reply-To: <alpine.DEB.1.00.0912192156030.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The non-existent editor also aborts with a non-zero status.
Thanks; that is a good point. Perhaps we might want to say what editor we
tried to run in the error message.
>> An editor that can exit with non-zero status on demand could use this
>> codepath to abort the rebase,
>
> Removing all lines of the edit script will abort an interactive rebase.
I guess you replied too fast without reading the message to the end ;-)
^ permalink raw reply
* Re: [PATCH] git svn: make empty directory creation gc-aware
From: Eric Wong @ 2009-12-20 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain, Robert Zeh
In-Reply-To: <7vzl5e3yx3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > More pushes hopefully coming as Sam and Andrew work out the mergeinfo
> > performance problems and I look into crossing svn-remote boundaries
> > for parent lookups.
>
> Thanks.
>
> This particular patch should be in 1.6.6 final, because mkdirs first
> appeared in 1.6.6-rc0 at 6111b93 (git svn: attempt to create empty dirs on
> clone+rebase, 2009-11-15), and 1.6.5.X series does not have the command,
> so this seems like a new feature that never existed in any tagged release,
> and if we shipped 1.6.6 without this patch, we will be shipping it with a
> know breakage, while if we shipped it with this, even if this patch
> somehow had an unintended side effect, at worst we'd be exchanging a bug
> with some other bug, so it wouldn't be worse.
I agree completely.
> Is mkdirs the only "noteworthy" feature that should be mentioned in the
> Release Notes in your area? It would be really nice if you can give a
> patch to Documentation/RelNotes-1.6.6.txt in a few days to turn a single
> liner I have there to something more helpful. The current shortlog since
> 1.6.5 indicates there weren't that much activity during this release.
Sam's merge handling work is definitely noteworthy, but it's already in
the release notes, hopefully the performance regression there is worked
out. I'll definitely send you a patch to the release notes after I get
a chance to figure out the other issue with multiple svn-remotes
tonight/tomorrow.
--
Eric Wong
^ permalink raw reply
* [PATCH 2/1] t9146: use 'svn_cmd' wrapper
From: Eric Wong @ 2009-12-20 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Robert Zeh
In-Reply-To: <20091219222738.GA20331@dcvr.yhbt.net>
Using 'svn' directly may not work for all users.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
> Test case included and pushed out to git://git.bogomips.org/git-svn
Junio: Not sure if you've merged yet, but feel free to squash this
with the other one. Thanks.
t/t9146-git-svn-empty-dirs.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 3f2d719..565365c 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -122,7 +122,7 @@ test_expect_success 'git svn gc-ed files work' '
: Compress::Zlib may not be available &&
if test -f "$unhandled".gz
then
- svn mkdir -m gz "$svnrepo"/gz &&
+ svn_cmd mkdir -m gz "$svnrepo"/gz &&
git reset --hard $(git rev-list HEAD | tail -1) &&
git svn rebase &&
test -f "$unhandled".gz &&
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git svn: make empty directory creation gc-aware
From: Junio C Hamano @ 2009-12-20 7:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Robert Zeh
In-Reply-To: <20091219222738.GA20331@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> The "git svn gc" command creates and appends to unhandled.log.gz
> files which should be parsed before the uncompressed
> unhandled.log files.
>
> Reported-by: Robert Zeh
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> Eric Wong <normalperson@yhbt.net> wrote:
> > Robert Zeh <robert.a.zeh@gmail.com> wrote:
> > > It looks like there is a conflict between git svn gc and git svn
> > > mkdirs. The git svn mkdirs command only looks at unhandled.log files.
> > > Shouldn't it also look at any compressed unhandled.log files too?
> >
> > Hi Robert,
> >
> > Yes, an oversight. Does this patch work for you? (Highly untested)
>
> Test case included and pushed out to git://git.bogomips.org/git-svn
>
> More pushes hopefully coming as Sam and Andrew work out the mergeinfo
> performance problems and I look into crossing svn-remote boundaries
> for parent lookups.
Thanks.
This particular patch should be in 1.6.6 final, because mkdirs first
appeared in 1.6.6-rc0 at 6111b93 (git svn: attempt to create empty dirs on
clone+rebase, 2009-11-15), and 1.6.5.X series does not have the command,
so this seems like a new feature that never existed in any tagged release,
and if we shipped 1.6.6 without this patch, we will be shipping it with a
know breakage, while if we shipped it with this, even if this patch
somehow had an unintended side effect, at worst we'd be exchanging a bug
with some other bug, so it wouldn't be worse.
Is mkdirs the only "noteworthy" feature that should be mentioned in the
Release Notes in your area? It would be really nice if you can give a
patch to Documentation/RelNotes-1.6.6.txt in a few days to turn a single
liner I have there to something more helpful. The current shortlog since
1.6.5 indicates there weren't that much activity during this release.
Alex Vandiver (3):
git-svn: sort svk merge tickets to account for minimal parents
git-svn: Set svn.authorsfile to an absolute path when cloning
git-svn: set svn.authorsfile earlier when cloning
Eric Wong (7):
git svn: fix fetch where glob is on the top-level URL
git svn: read global+system config for clone+init
git svn: attempt to create empty dirs on clone+rebase
git svn: always reuse existing remotes on fetch
git svn: strip leading path when making empty dirs
git svn: log removals of empty directories
git svn: make empty directory creation gc-aware
Greg Price (1):
git svn: Don't create empty directories whose parents were deleted
Jonathan Nieder (2):
add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
am -i, git-svn: use "git var GIT_PAGER"
Sam Vilain (2):
git-svn: convert SVK merge tickets to extra parents
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
Thomas Rast (1):
Document git-svn's first-parent rule
Toby Allsopp (1):
git svn: handle SVN merges from revisions past the tip of the branch
^ permalink raw reply
* Re: Git as electronic lab notebook
From: Nicolas Pitre @ 2009-12-20 4:55 UTC (permalink / raw)
To: Bill Lear; +Cc: Johan 't Hart, Ciprian Dorin, Craciun, Thomas Johnson, git
In-Reply-To: <19245.43871.588697.532035@lisa.zopyra.com>
On Sat, 19 Dec 2009, Bill Lear wrote:
> On Saturday, December 19, 2009 at 22:15:00 (-0500) Nicolas Pitre writes:
> >On Sun, 20 Dec 2009, Johan 't Hart wrote:
> >
> >> Is git able to handle 4Gig files? I've heard git loads every file completely
> >> in memory before handling it...
> >
> >Right. Sowith current Git you will be able to deal with 4GB files only
> >if you have a 64-bit machine and more than 4GB of RAM.
>
> ??
>
> % uname -a
> Linux pppp 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux
> % cat /proc/meminfo | grep MemTotal
> MemTotal: 3095296 kB
> % mkdir gogle
> % cd gogle
> % git init
> % dd if=/dev/zero of=zerofile.tst bs=1k count=4700000
> % git add *
> % git commit -a -m new
> [master (root-commit) 35a25be] new
> 1 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 zerofile.tst
> % git --version
> git version 1.6.5.7
>
> Seems ok to me...
That's the easy part. Diffing such files and delta compressing them, or
even checking them out especially when delta compressed, just won't work
if you don't have the RAM. Fixing this limitation would introduce
significant complexity in the code that no one felt was worth it.
I had some thoughts about supporting the addition of really huge files
in a Git repository where only add/commit/checkout/fetch/push would work
with no delta compression. That didn't materialized yet though.
Nicolas
^ permalink raw reply
* Re: Git as electronic lab notebook
From: Bill Lear @ 2009-12-20 4:43 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johan 't Hart, Ciprian Dorin, Craciun, Thomas Johnson, git
In-Reply-To: <alpine.LFD.2.00.0912192212400.28241@xanadu.home>
On Saturday, December 19, 2009 at 22:15:00 (-0500) Nicolas Pitre writes:
>On Sun, 20 Dec 2009, Johan 't Hart wrote:
>
>> Is git able to handle 4Gig files? I've heard git loads every file completely
>> in memory before handling it...
>
>Right. Sowith current Git you will be able to deal with 4GB files only
>if you have a 64-bit machine and more than 4GB of RAM.
??
% uname -a
Linux pppp 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux
% cat /proc/meminfo | grep MemTotal
MemTotal: 3095296 kB
% mkdir gogle
% cd gogle
% git init
% dd if=/dev/zero of=zerofile.tst bs=1k count=4700000
% git add *
% git commit -a -m new
[master (root-commit) 35a25be] new
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 zerofile.tst
% git --version
git version 1.6.5.7
Seems ok to me...
Though, I find this interesting:
% git log -p
commit 35a25be3fff2f8bbd6ec22c94b9a5c0d66053d21
Author: Bill Lear <rael@zopyra.com>
Date: Sat Dec 19 22:38:48 2009 -0600
new
diff --git a/zerofile.tst b/zerofile.tst
new file mode 100644
index 0000000..e5bd39d
Binary files /dev/null and b/zerofile.tst differ
Bill
^ permalink raw reply
* Re: Git as electronic lab notebook
From: Nicolas Pitre @ 2009-12-20 3:15 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Ciprian Dorin, Craciun, Thomas Johnson, git
In-Reply-To: <4B2D6CA5.3070304@gmail.com>
On Sun, 20 Dec 2009, Johan 't Hart wrote:
> Is git able to handle 4Gig files? I've heard git loads every file completely
> in memory before handling it...
Right. Sowith current Git you will be able to deal with 4GB files only
if you have a 64-bit machine and more than 4GB of RAM.
Nicolas
^ 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