* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Kalle Olavi Niemitalo @ 2012-11-11 7:02 UTC (permalink / raw)
To: Paul Fox; +Cc: git
In-Reply-To: <20121110220811.DC6A42E8B68@grass.foxharp.boston.ma.us>
Paul Fox <pgf@foxharp.boston.ma.us> writes:
> you're sending SIGINT to the cvs commit command, and that causes the
> editor to die right away?
That's right. It is not a quirk of shell-mode in Emacs, because
I get the same result with ^C in xterm too.
% EDITOR="$HOME/prefix/x86_64-unknown-linux-gnu/bin/emacsclient --current-frame"
% export EDITOR
% cvs commit BUGIT
Waiting for Emacs...^Ccvs commit: warning: editor session failed
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
Action: (continue) a
cvs [commit aborted]: aborted by user
%
While cvs was waiting from emacsclient:
% cat /proc/2030/stat
2030 (cvs) S 1849 2030 1849 34816 2030 4202496 598 0 0 0 0 0 0 0 20 0 1 0 94752537 34254848 410 18446744073709551615 140168182550528 140168183348316 140737407935424 140737407931680 140168163193950 0 0 6 20513 0 0 0 17 2 0 0 0 0 0
% grep 'Name\|Pid\|Sig' /proc/2030/status
Name: cvs
Pid: 2030
PPid: 1849
TracerPid: 0
SigQ: 0/28998
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000006
SigCgt: 0000000180005021
% cat /proc/2031/stat
2031 (emacsclient) S 2030 2030 1849 34816 2030 4202496 155 0 0 0 0 0 0 0 20 0 1 0 94752538 4169728 81 18446744073709551615 4194304 4210620 140735996104016 140735996095456 140664960886018 0 0 0 0 0 0 0 17 1 0 0 0 0 0
% grep 'Name\|Pid\|Sig' /proc/2031/status
Name: emacsclient
Pid: 2031
PPid: 2030
TracerPid: 0
SigQ: 0/28998
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
%
which I interpret to mean both processes were in process group
2030, the cvs process ignored SIGINT and SIGQUIT, the emacsclient
process neither ignored nor handled any signals, and neither
process blocked any signals (not even SIGCHLD as system(3) would).
When ^C in the terminal sent SIGINT to the process group, it
terminated the emacsclient process only.
If git did the same thing as cvs here, i.e. ignore the signals in
the parent process only and check the exit status of the editor,
I think that would be OK.
^ permalink raw reply
* Re: Reviews on mailing-list
From: Junio C Hamano @ 2012-11-11 5:54 UTC (permalink / raw)
To: Thiago Farina, Felipe Contreras; +Cc: Deniz Türkoglu, git, Shawn Pearce
In-Reply-To: <CACnwZYekU0CYnqQT8L2siJbUsn=T9qowgth94TWc8KN472Ziag@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> wrote:
>Requiring a web browser is a huge requirement, ham??
No, but requiring reviews and discussions typed in the browser is.
Pardon terseness, typo and HTML from a tablet.
^ permalink raw reply
* [PATCH] gitweb: git_summary - show $project in title
From: Henrich Schuchardt @ 2012-11-11 5:20 UTC (permalink / raw)
To: git; +Cc: xypron.glpk
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconstent user experience.
This patch adds the missing project title.
Signed-off-by: Henrich Schuchardt <xypron.glpk@gmx.de>
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..3e1c452 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6451,7 +6451,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print "<div class=\"title\"> </div>\n";
+ print "<div class=\"title\">$project</div>\n";
print "<table class=\"projects_list\">\n" .
"<tr id=\"metadata_desc\"><td>description</td><td>" . esc_html($descr) . "</td></tr>\n";
unless ($omit_owner) {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v4 3/6] Color skipped tests blue
From: Adam Spiers @ 2012-11-11 2:04 UTC (permalink / raw)
To: Jeff King; +Cc: git list, Junio C Hamano, Stefano Lattarini
In-Reply-To: <20120921061325.GA15867@sigill.intra.peff.net>
On Fri, Sep 21, 2012 at 02:13:25AM -0400, Jeff King wrote:
> On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
>
> > t/test-lib.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 5293830..78c88c2 100755
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -182,13 +182,13 @@ then
> > error)
> > tput bold; tput setaf 1;; # bold red
> > skip)
> > - tput bold; tput setaf 2;; # bold green
> > + tput setaf 4;; # blue
> > warn)
> > tput bold; tput setaf 3;; # bold yellow
> > pass)
> > tput setaf 2;; # green
> > info)
> > - tput setaf 3;; # brown
> > + tput setaf 3;; # yellow/brown
>
> I happened to be running a test script with "-v" earlier today, and I
> noticed that the "expecting success..." dump of the test contents is
> also yellow. By your new rules, shouldn't it be blue?
>
> I think it is matching the "info" type, which from the discussion should
> be blue, no?
It uses the "default" colour:
say >&3 "expecting success: $2"
where say is defined:
say () {
say_color info "$*"
}
Many other messages are output in this default colour too, and I never
proposed to change it. The only time in the discussion where blue was
associated with "info" was in this sentence I wrote in the
commit message for the patch altering the colour of "skip" messages:
"However, it's more informational than cautionary, so instead we
use blue which is a universal color for information signs."
Whilst it could also be applied to "info", I don't think it would be a
good idea to have the "skip" and "info" colours *both* as bold blue.
It seems to me more important that the "skip" messages should visually
stand out more than "info", since they are rarer and a more notable
level of information than the latter (especially if --verbose is
used). Additionally, yellow is already somewhat overloaded (yellow
for "info" and bold yellow for "warn"). Therefore I would suggest
changing "info" to perhaps bold white or bold cyan. Or "skip" could
be magenta and "info" blue. But now we are heading down a slippery
slope; it'll be near impossible to please everyone. Any final
thoughts?
> Maybe it is just my terminal. I see it is labeled as "brown" here, but
> it looks very yellow (and I am using the stock xterm colors. According
> to:
>
> https://en.wikipedia.org/wiki/ANSI_colors
>
> It looks it really is brown on some platforms.
Yes, it can be.
> I'm not sure if it is
> worth worrying about. I don't really want to get into configurable
> colors just for the test-suite output.
Agreed. There is no indisputably correct combination. However, I
think that, modulo a tweak for the above, we are definitely in the
right ball park. The main thing is that the traffic light colour
scheme is adhered to, and that different types of message are clearly
visually separated, with more important ones standing out more than
less important ones.
^ permalink raw reply
* Re: Reviews on mailing-list
From: Deniz Türkoglu @ 2012-11-11 1:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMP44s2AvaAs-dn_eoSFWoLHBQk5QrrV=zYTOpRi2nEywoua4w@mail.gmail.com>
On Sat, Nov 10, 2012 at 3:40 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>
>> This is my first mail to the git mailing list. I have been following
>> the list for some time now and I would like to suggest moving the
>> reviews out of the mailing list, for example to a gerrit instance, I
>> believe it would improve the commits and the mailing list. I have a
>> filter on 'PATCH', but I feel I miss some of the discussion, and
>> things that I would be interested in.
>>
>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>> said he is OK with hosting the gerrit instance.
>>
>> I would like to hear your thoughts on this.
>
> Personally I think reviews on the mailing list is far superior than
> any other review methods. I've even blogged about it and all the
> reasons[1]. Gerrit is better than bugzilla, but it still requires a
> web browser, and logging in.
I disagree that the current approach is optimal. Bugzilla is a
bug-tracker and is not meant to be used for reviews. I believe in
using the right tool for the right job. An e-mail should be concise
and to the point, in this case only contain the discussion. This will
help it to reach a wider audience and be more useful when people
stumble upon it through a google search.
cheers,
-deniz
^ permalink raw reply
* Re: Reviews on mailing-list
From: Thiago Farina @ 2012-11-11 1:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMP44s2AvaAs-dn_eoSFWoLHBQk5QrrV=zYTOpRi2nEywoua4w@mail.gmail.com>
On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>
>> This is my first mail to the git mailing list. I have been following
>> the list for some time now and I would like to suggest moving the
>> reviews out of the mailing list, for example to a gerrit instance, I
>> believe it would improve the commits and the mailing list. I have a
>> filter on 'PATCH', but I feel I miss some of the discussion, and
>> things that I would be interested in.
>>
>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>> said he is OK with hosting the gerrit instance.
>>
>> I would like to hear your thoughts on this.
>
> Personally I think reviews on the mailing list is far superior than
> any other review methods. I've even blogged about it and all the
> reasons[1]. Gerrit is better than bugzilla, but it still requires a
> web browser, and logging in.
>
Requiring a web browser is a huge requirement, ham?? How come that can
be an impediment to move forward way of this awkward way of reviewing
patches through email? Switching to Gerrit would mean everyone would
be using the same tool instead of anyone using its own email client
(gmail, mutt, thunderbird, whatever...) and having to figure out git
format-patch, git send-email (--reply-to where?).
There are a lot of issues of having to use email for reviewing patches
that I think Gerrit is a superior alternative.
And many people are arguing for it!
Let's move on...
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Felipe Contreras @ 2012-11-11 0:58 UTC (permalink / raw)
To: Stefano Lattarini
Cc: Junio C Hamano, Torsten Bögershausen, Git Mailing List
In-Reply-To: <509EEF09.6060109@gmail.com>
On Sun, Nov 11, 2012 at 1:19 AM, Stefano Lattarini
<stefano.lattarini@gmail.com> wrote:
> On 11/11/2012 12:11 AM, Felipe Contreras wrote:
>> On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>>> The short version:
>>>>> echo -n doesn't seem to be portable.
>>>>> The following works for me:
>>>>
>>>> Right, I was supposed to change that to:
>>>>
>>>> true > marks-cur &&
>>>
>>> Please make it like so:
>>>
>>> >marks-cur &&
>>>
>>> No command is necessary when creating an empty file or truncating an
>>> existing file to empty, and no SP between redirection and its target.
>>
>> That hangs on zsh (presumably waiting for stdin).
>>
> Unless you set:
>
> NULLCMD=:
>
> early in your test script.
>
> Or, to be extra-safe, you could steal this initialization code from
> autoconf:
>
> # Be more Bourne compatible.
> if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
> emulate sh
> NULLCMD=:
> setopt NO_GLOB_SUBST
> # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
> # is contrary to our usage. Disable this feature.
> alias -g '${1+"$@"}'='"$@"'
It doesn't seem like zsh listens to that variable in sh mode:
% zsh -c 'emulate sh; NULLCMD=foobar; > content'
And it doesn't seem like NO_GLOB_SUBST is needed any more.
I think it doesn't hurt to do 'true > marks-cur', but whatever.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: orphan blob or what?
From: bruce @ 2012-11-11 0:32 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1352497275-ner-6808@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> On Fri, 09 Nov 2012 11:37:04 -0800, bruce <bruce.e.robertson@intel.com> wrote:
>> Tomas Carnecky <tomas.carnecky@gmail.com> writes:
>>
>> Just idiocy on my part. Thanks.
>>
>> > On Thu, 08 Nov 2012 16:24:36 -0800, bruce <bruce.e.robertson@intel.com> wrote:
>> >> In today's and older clones of https://github.com/mirrors/linux.git I
>> >> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
>> >> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
>> >> in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
>> >> can't see it via 'git log'. And yet
>> >>
>> >> linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >> 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
>> >> 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >> f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >
>> > Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile,
>> > 2010-09-29) references this blob.
>
> It wasn't easy to find the commit. First I figured out at which path that file
> was stored. Using git log -S'wm8962_reg[WM8962_MAX_REGISTER + 1]' I quickly
> determined that the file was somewhere in sound/, more specifically
> sound/soc/codecs/wm8962-tables.c. However a 'git log --
> sound/soc/codecs/wm8962-tables.c' did not show any commit. That was strange,
> because 'git log -S'WM8962_MAX_REGISTER + 1' --name-status --
> sound/soc/codecs/' clearly shows that the file existed at some point in the
> past. The commit is hidden from a simple 'git log' due to 'History
> Simplification'. See the git-log man page. I added --full-history -p to the log
> command, and searched in the pager for '6fa98e'. That revealed the commit which
> references that blob:
>
> git log --full-history -p -- sound/soc/codecs/wm8962-tables.c
Thanks very much for the elucidation. I really must RTFMs. Only 44.786
Kib lines. Porcelain (mostly) first. I just can't eliminate the reading
I need to do.
FWIW, I was somewhat perplexed by searching for
c969f19f8fd17e600a16fe91aab66d86936cce0a in 'gitk -all'. It doesn't find
it BUT if I use --select-commit=c969f19f8fd17e600a16fe91aab66d86936cce0a
then positions to it. If I position away again it again can't find
it. Bother!
BTW, this was all occasioned by looking for unused large packed blobs as
an educational exercise.
Thanks again,
Bruce
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Stefano Lattarini @ 2012-11-11 0:19 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s0dQ8EeCkHo8Lh3odG3qQoeLFModec+7doLeTHnZoJ_pg@mail.gmail.com>
On 11/11/2012 12:11 AM, Felipe Contreras wrote:
> On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>> The short version:
>>>> echo -n doesn't seem to be portable.
>>>> The following works for me:
>>>
>>> Right, I was supposed to change that to:
>>>
>>> true > marks-cur &&
>>
>> Please make it like so:
>>
>> >marks-cur &&
>>
>> No command is necessary when creating an empty file or truncating an
>> existing file to empty, and no SP between redirection and its target.
>
> That hangs on zsh (presumably waiting for stdin).
>
Unless you set:
NULLCMD=:
early in your test script.
Or, to be extra-safe, you could steal this initialization code from
autoconf:
# Be more Bourne compatible.
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
setopt NO_GLOB_SUBST
# Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
else
case `(set -o) 2>/dev/null` in *posix*) set -o posix ;; esac
fi
All of this untested with the real Git testsuite, of course ;-)
Regards, and HTH,
Stefano
^ permalink raw reply
* [PATCH] git-credential-gnome-keyring: Remove die
From: Matt Kraai @ 2012-11-11 0:08 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
git-credential-gnome-keyring defines die, but it is unused and
incorrect (it passes a va_list to error, which does not expect one),
so remove it.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
.../credential/gnome-keyring/git-credential-gnome-keyring.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 41f61c5..3eaafba 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -104,16 +104,6 @@ static inline void error(const char *fmt, ...)
va_end(ap);
}
-static inline void die(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap,fmt);
- error(fmt, ap);
- va_end(ap);
- exit(EXIT_FAILURE);
-}
-
static inline void die_errno(int err)
{
error("%s", strerror(err));
--
1.7.10.4
^ permalink raw reply related
* Re: Reviews on mailing-list
From: Felipe Contreras @ 2012-11-10 23:40 UTC (permalink / raw)
To: Deniz Türkoglu; +Cc: git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CA+ZXwZOnZZyk_KWmLLLNChWb1R_Av1s5jM4PsLFWKaG8BB+uXQ@mail.gmail.com>
On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
> This is my first mail to the git mailing list. I have been following
> the list for some time now and I would like to suggest moving the
> reviews out of the mailing list, for example to a gerrit instance, I
> believe it would improve the commits and the mailing list. I have a
> filter on 'PATCH', but I feel I miss some of the discussion, and
> things that I would be interested in.
>
> I have spoken to Shawn Pearce (gerrit project lead, google) and he
> said he is OK with hosting the gerrit instance.
>
> I would like to hear your thoughts on this.
Personally I think reviews on the mailing list is far superior than
any other review methods. I've even blogged about it and all the
reasons[1]. Gerrit is better than bugzilla, but it still requires a
web browser, and logging in.
I love to be able to just hit 'reply' with my favorite MUA, comment
inline, and hit send.
Cheers.
[1] http://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/
--
Felipe Contreras
^ permalink raw reply
* Reviews on mailing-list
From: Deniz Türkoglu @ 2012-11-10 23:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn Pearce
Hi all,
This is my first mail to the git mailing list. I have been following
the list for some time now and I would like to suggest moving the
reviews out of the mailing list, for example to a gerrit instance, I
believe it would improve the commits and the mailing list. I have a
filter on 'PATCH', but I feel I miss some of the discussion, and
things that I would be interested in.
I have spoken to Shawn Pearce (gerrit project lead, google) and he
said he is OK with hosting the gerrit instance.
I would like to hear your thoughts on this.
cheers,
-deniz
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Felipe Contreras @ 2012-11-10 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torsten Bögershausen, Git Mailing List
In-Reply-To: <7v4nkxozep.fsf@alter.siamese.dyndns.org>
On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>> The short version:
>>> echo -n doesn't seem to be portable.
>>> The following works for me:
>>
>> Right, I was supposed to change that to:
>>
>> true > marks-cur &&
>
> Please make it like so:
>
> >marks-cur &&
>
> No command is necessary when creating an empty file or truncating an
> existing file to empty, and no SP between redirection and its target.
That hangs on zsh (presumably waiting for stdin).
--
Felipe Contreras
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Junio C Hamano @ 2012-11-10 22:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s2sKL4CJ_wcM7U9mYPX6bkaQA8hgDM6Z0QEj2TACh-8DQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>> The short version:
>> echo -n doesn't seem to be portable.
>> The following works for me:
>
> Right, I was supposed to change that to:
>
> true > marks-cur &&
Please make it like so:
>marks-cur &&
No command is necessary when creating an empty file or truncating an
existing file to empty, and no SP between redirection and its target.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Paul Fox @ 2012-11-10 22:08 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <871ug15k5c.fsf@Niukka.kon.iki.fi>
kalle olavi niemitalo wrote:
> Paul Fox <pgf@foxharp.boston.ma.us> writes:
>
> > when i implemented the change, i wondered if some twisted emacs
> > workflow would be an issue. ;-) and i almost blocked SIGQUIT as
> > well -- the two programs i looked at for precedent (CVS and MH) both
> > block both SIGQUIT and SIGINT when spawning an editor.
> >
> > but since emacs users must have dealt with CVS for a long time before
> > dealing with git, how might they have done so?
>
> I think I usually ran CVS via vc.el, which prompts for a commit
> message in Emacs before it runs cvs commit. So CVS did not need
> to run $EDITOR.
>
> I just tried emacsclient with CVS 1.12.13-MirDebian-9, and it
> behaves somewhat differently from Git with pf/editor-ignore-sigint.
> When I tell Emacs to send SIGINT to the *Shell* buffer, CVS prompts:
>
> cvs commit: warning: editor session failed
>
> Log message unchanged or not specified
> a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
> Action: (continue)
you're sending SIGINT to the cvs commit command, and that causes the
editor to die right away? that's surprising. i can replicate your
described behavior by setting $VISUAL to a script that just sleeps, and
sending SIGTERM to the cvs commit process. but not by sending SIGINT.
well, i'm not sure what to say. there's a real problem when using the
current code and traditional editors. i thought that the patch in
pf/editor-ignore-sigint reflected standard practice, and indeed it
accomplishes exactly the right thing with those editors. you've shown
a particular work flow involving emacsclient that won't work anymore
with the change made, though there are workarounds. perhaps there's
something the other editors themselves should be doing differently,
but i don't know what that might be.
paul
>
> and then I can choose to abort.
>
> With strace, it looks like CVS sets SIG_IGN as the handler of
> SIGINT and SIGQUIT only in the parent process after forking, not
> in the child process that executes the editor.
>
> CVS also temporarily blocks signals by calling sigprocmask, but
> it undoes that before it forks or waits for the child process.
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 45.5 degrees)
^ permalink raw reply
* Re: t5801-remote-helpers.sh fails
From: Felipe Contreras @ 2012-11-10 22:05 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Git Mailing List
In-Reply-To: <509EA8EE.1030908@web.de>
On Sat, Nov 10, 2012 at 8:20 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 11/10/2012 08:15 PM, Felipe Contreras wrote:
>>
>> Hi,
>>
>> On Sat, Nov 10, 2012 at 2:48 PM, Torsten Bögershausen <tboegi@web.de>
>> wrote:
>>
>>> on peff/pu t5801 fails, the error is in git-remote-testgit, please see
>>> below.
>>>
>>> That's on my Mac OS X box.
>>>
>>> I haven't digged further into the test case, but it looks as if
>>> "[-+]A make NAMEs associative arrays"
>>> is not supported on this version of bash.
>>> /Torsten
>>>
>>>
>>> /Users/tb/projects/git/git.peff/git-remote-testgit: line 64: declare: -A:
>>> invalid option
>>> declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
>>> /Users/tb/projects/git/git.peff/git-remote-testgit: line 66:
>>> refs/heads/master: division by 0 (error token is "/master")
>>> error: fast-export died of signal 13
>>> fatal: Error while running fast-export
>>
>>
>> What is your bash --version?
>>
> bash --version
> GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
> Copyright (C) 2007 Free Software Foundation, Inc.
I see, that version indeed doesn't have associative arrays.
> On the other hand, Documentation/CodingGuidelines says:
> - No shell arrays.
Yeah, for shell code I guess, but this is bash code.
> Could we use perl to have arrays?
I think the code in perl would be harder to follow, and this is meant
not only as a test, but also as a reference.
I'm not exactly sure what we should do here:
a) remove the code (would not be so good as a reference)
b) enable the code conditionally based on the version of bash (harder to read)
c) replace the code without associative arrays (will be much more
complicated and ugly)
d) add a check for the bash version to the top of the test in t/
I'm leaning towards d), followed by b).
If only there was a clean way to do this, so c) would not be so ugly.
After investigating different optins this seems to be the best:
join -e empty -o '0 1.2 2.2' -a 2 <(echo "$before") <(echo "$after")
| while read e a b; do
test "$a" == "$b" && continue
echo "changed $e"
done
But to me seems a bit harder to grasp. Not sure.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] git tag --contains : avoid stack overflow
From: Pat Thoyts @ 2012-11-10 21:33 UTC (permalink / raw)
To: Jean-Jacques Lafay; +Cc: msysgit, Git List, Philip Oakley
In-Reply-To: <d9843c09-3ca9-406e-9df8-78603235d985@googlegroups.com>
On 10 November 2012 21:13, Jean-Jacques Lafay
<jeanjacques.lafay@gmail.com> wrote:
> Le samedi 10 novembre 2012 21:00:10 UTC+1, Philip Oakley a écrit :
>>
>> From: "Jean-Jacques Lafay" <jeanjacq...@gmail.com> Sent: Saturday,
>> November 10, 2012 5:36 PM
>> > In large repos, the recursion implementation of contains(commit,
>> > commit_list)
>> > may result in a stack overflow. Replace the recursion with a loop to
>> > fix it.
>> >
>> > Signed-off-by: Jean-Jacques Lafay <jeanjacq...@gmail.com>
>>
>> This is a change to the main git code so it is better to submit it to
>> the main git list at g...@vger.kernel.org (plain text, no HTML, first
>> post usually has a delay ;-)
>>
>> It sounds reasonable but others may have opinions and comments.
>>
>> Have you actually suffered from the stack overflow issue? You only
>> suggest it as a possibility, rather than a real problem.
>>
>> Philip
>
>
> Yes, it actually crashed on me, and since the call is made by GitExtension
> while browsing the commit history, it was quickly annoying to have windows
> popping a "git.exe stopped working" message box at my face every time I
> clicked on a line of the history ;-) (well, you can sort of work around it
> by having the "file tree" or "diff" tab active)
>
> Coincidentally, as I was having a glance at the recent topics, I saw that
> someone else experienced it.
>
> However, I couldn't reproduce it on Linux : where the windows
> implementations crashes at a ~32000 depth (*not* exactly 32768, mind you),
> on linux it happily went through 100000 commits. I didn't take time to look
> much further, but maybe on my 64 bit Linux VM, the process can afford to
> reserve a much bigger address range for the stack of each thread than the
> 1Mb given to 32 bit processes on windows.
>
> Jean-Jacques.
I checked this on msysGit - the test causes a crash on Windows when
using the 1.8.0 release and recompiling with this patch applied fixes
this. As mentioned, its best to have this reviewed upstream too as its
likely that windows just has a smaller stack so causes the crash
earlier.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH] git tag --contains : avoid stack overflow
From: Jean-Jacques Lafay @ 2012-11-10 21:13 UTC (permalink / raw)
To: msysgit; +Cc: Jean-Jacques Lafay, Git List, Philip Oakley
In-Reply-To: <03ED9D50D1F64467863C051959CFC433@PhilipOakley>
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Le samedi 10 novembre 2012 21:00:10 UTC+1, Philip Oakley a écrit :
> From: "Jean-Jacques Lafay" <jeanjacq...@gmail.com <javascript:>> Sent:
> Saturday,
> November 10, 2012 5:36 PM
> > In large repos, the recursion implementation of contains(commit,
> > commit_list)
> > may result in a stack overflow. Replace the recursion with a loop to
> > fix it.
> >
> > Signed-off-by: Jean-Jacques Lafay <jeanjacq...@gmail.com <javascript:>>
>
> This is a change to the main git code so it is better to submit it to
> the main git list at g...@vger.kernel.org <javascript:> (plain text, no
> HTML, first
> post usually has a delay ;-)
>
> It sounds reasonable but others may have opinions and comments.
>
> Have you actually suffered from the stack overflow issue? You only
> suggest it as a possibility, rather than a real problem.
>
> Philip
>
Yes, it actually crashed on me, and since the call is made by GitExtension
while browsing the commit history, it was quickly annoying to have windows
popping a "git.exe stopped working" message box at my face every time I
clicked on a line of the history ;-) (well, you can sort of work around it
by having the "file tree" or "diff" tab active)
Coincidentally, as I was having a glance at the recent topics, I saw that
someone else experienced it.
However, I couldn't reproduce it on Linux : where the windows
implementations crashes at a ~32000 depth (*not* exactly 32768, mind you),
on linux it happily went through 100000 commits. I didn't take time to look
much further, but maybe on my 64 bit Linux VM, the process can afford to
reserve a much bigger address range for the stack of each thread than the
1Mb given to 32 bit processes on windows.
Jean-Jacques.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
[-- Attachment #2: Type: text/html, Size: 3089 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Andreas Schwab @ 2012-11-10 21:12 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: Paul Fox, git
In-Reply-To: <871ug15k5c.fsf@Niukka.kon.iki.fi>
Kalle Olavi Niemitalo <kon@iki.fi> writes:
> With strace, it looks like CVS sets SIG_IGN as the handler of
> SIGINT and SIGQUIT only in the parent process after forking, not
> in the child process that executes the editor.
>
> CVS also temporarily blocks signals by calling sigprocmask, but
> it undoes that before it forks or waits for the child process.
This emulates what system(3) does.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git-reset man page
From: Krzysztof Mazur @ 2012-11-10 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Angelo Borsotti, git, peff
In-Reply-To: <7v8va9p6pn.fsf@alter.siamese.dyndns.org>
On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> > Maybe we should just add that <paths> is an shortcut for <pathspec>
> > and fix places where paths and pathspec are mixed or <path> is used as
> > <pathspec>.
>
> We should unify uses of <paths> and <path> (the former should be
> <path>... or something).
Currently in most cases "<paths>..." is used ;)
>
> Some places you need to give exact path (iow, these places you
> cannot use pathspec), while most other places pathspec
> (i.e. matching pattern) is accepted.
I know, thats why I added a note that "<path> is not always used for pathspec".
>
> The manual correctly updated will most likely to use both <path> and
> <pathspec> appropriately.
So we should always use "<path>" for exact path, and "<pathspec>" for
pathspecs patterns as defined in gitglossary. I think it's better
to avoid "<paths>" and always use "<path>..." or "<pathspec>...".
Krzysiek
^ permalink raw reply
* Re: git-reset man page
From: Junio C Hamano @ 2012-11-10 20:02 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Angelo Borsotti, git, peff
In-Reply-To: <20121110155718.GA29321@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> Maybe we should just add that <paths> is an shortcut for <pathspec>
> and fix places where paths and pathspec are mixed or <path> is used as
> <pathspec>.
We should unify uses of <paths> and <path> (the former should be
<path>... or something).
Some places you need to give exact path (iow, these places you
cannot use pathspec), while most other places pathspec
(i.e. matching pattern) is accepted.
The manual correctly updated will most likely to use both <path> and
<pathspec> appropriately.
^ permalink raw reply
* Re: [PATCH] git tag --contains : avoid stack overflow
From: Philip Oakley @ 2012-11-10 20:00 UTC (permalink / raw)
To: Jean-Jacques Lafay, msysgit; +Cc: Git List
In-Reply-To: <1352568970-4669-1-git-send-email-jeanjacques.lafay@gmail.com>
From: "Jean-Jacques Lafay" <jeanjacques.lafay@gmail.com> Sent: Saturday,
November 10, 2012 5:36 PM
> In large repos, the recursion implementation of contains(commit,
> commit_list)
> may result in a stack overflow. Replace the recursion with a loop to
> fix it.
>
> Signed-off-by: Jean-Jacques Lafay <jeanjacques.lafay@gmail.com>
This is a change to the main git code so it is better to submit it to
the main git list at git@vger.kernel.org (plain text, no HTML, first
post usually has a delay ;-)
It sounds reasonable but others may have opinions and comments.
Have you actually suffered from the stack overflow issue? You only
suggest it as a possibility, rather than a real problem.
Philip
> ---
> builtin/tag.c | 83
> ++++++++++++++++++++++++++++++++++++++++------------------
> t/t7004-tag.sh | 21 +++++++++++++++
> 2 files changed, 78 insertions(+), 26 deletions(-)
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 9c3e067..4be67dd 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -73,40 +73,71 @@ static int in_commit_list(const struct commit_list
> *want, struct commit *c)
> return 0;
> }
>
> -static int contains_recurse(struct commit *candidate,
> - const struct commit_list *want)
> -{
> - struct commit_list *p;
> -
> - /* was it previously marked as containing a want commit? */
> - if (candidate->object.flags & TMP_MARK)
> - return 1;
> - /* or marked as not possibly containing a want commit? */
> - if (candidate->object.flags & UNINTERESTING)
> - return 0;
> - /* or are we it? */
> - if (in_commit_list(want, candidate))
> - return 1;
> +struct commit_list_list {
> + struct commit *item;
> + struct commit_list *next_item;
> + struct commit_list_list *next;
> +};
>
> - if (parse_commit(candidate) < 0)
> - return 0;
> +static void mark_path(struct commit_list_list *path, int status)
> +{
> + struct commit_list_list *temp;
> + while (path) {
> + path->item->object.flags |= status;
> + temp = path;
> + path = temp->next;
> + free(temp);
> + }
> +}
>
> - /* Otherwise recurse and mark ourselves for future traversals. */
> - for (p = candidate->parents; p; p = p->next) {
> - if (contains_recurse(p->item, want)) {
> - candidate->object.flags |= TMP_MARK;
> +static int contains(struct commit *candidate,
> + const struct commit_list *want)
> +{
> + /* previously implemented with a recursion, but could stack overflow
> in large repos */
> + struct commit_list_list *p, *tmp;
> + p = xmalloc(sizeof(struct commit_list_list));
> + p->item = candidate;
> + p->next_item = NULL;
> + p->next = NULL;
> +
> + while (p) {
> + candidate = p->item;
> +
> + /* is it ok : */
> + /* was it previously marked as containing a want commit? */
> + /* or are we it? */
> + if (candidate->object.flags & TMP_MARK || in_commit_list(want,
> candidate)) {
> + mark_path(p, TMP_MARK);
> return 1;
> }
> + /* is it not ok : */
> + /* was it previously marked as not possibly containing a want
> commit? */
> + /* do we have parents? */
> + if (candidate->object.flags & UNINTERESTING ||
> parse_commit(candidate) < 0 || !candidate->parents) {
> + candidate->object.flags |= UNINTERESTING;
> + /* then backtrack, marking as UNINTERESTING along the way */
> + while (p && !p->next_item) {
> + p->item->object.flags |= UNINTERESTING;
> + tmp = p;
> + p = tmp->next;
> + free(tmp);
> + }
> + if (p) {
> + p->item = p->next_item->item;
> + p->next_item = p->next_item->next;
> + }
> + } else {
> + /* let's check the parents */
> + tmp = xmalloc(sizeof(struct commit_list_list));
> + tmp->item = candidate->parents->item;
> + tmp->next_item = candidate->parents->next;
> + tmp->next = p;
> + p = tmp;
> + }
> }
> - candidate->object.flags |= UNINTERESTING;
> return 0;
> }
>
> -static int contains(struct commit *candidate, const struct
> commit_list *want)
> -{
> - return contains_recurse(candidate, want);
> -}
> -
> static void show_tag_lines(const unsigned char *sha1, int lines)
> {
> int i;
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 5189446..196ac54 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1365,4 +1365,25 @@ test_expect_success 'multiple --points-at are
> OR-ed together' '
> test_cmp expect actual
> '
>
> +# what about a deep repo ?
> +
> +>expect
> +test_expect_success '--contains works in a deep repo' '
> + i=1
> + while test $i -lt 40000
> + do
> + echo "commit refs/heads/master
> +committer A U Thor <author@example.com> $((1000000000 + $i * 100))
> +0200
> +data <<EOF
> +commit #$i
> +EOF"
> + test $i == 1 && echo "from refs/heads/master^0"
> + i=$(($i + 1))
> + done | git fast-import
> + git checkout master
> + git tag far-far-away HEAD^
> + git tag --contains HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> test_done
> --
> 1.8.0.msysgit.0.1.geed93bd.dirty
>
> --
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Junio C Hamano @ 2012-11-10 19:56 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Jeff King, Felipe Contreras, git, Sverre Rabbelier
In-Reply-To: <20121110123250.GR12052@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> writes:
>> I think it is better to keep the tests simple and maintainable.
>
> Maintainable? There is nothing to maintain here....
> ...
> OTOH, this series has some serious drawbacks.
>
> It makes debugging more difficult....
Are these referring to the same aspect of the series? The concern
you described about debuggability matches my impression IIRC back
when I took a look at the series, which I would count as a large
part of keeping tests maintainable.
But you may be referring to something different (sorry, not on my
primary machine yet).
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Kalle Olavi Niemitalo @ 2012-11-10 19:32 UTC (permalink / raw)
To: Paul Fox; +Cc: git
In-Reply-To: <20121110155209.75EFC2E8B68@grass.foxharp.boston.ma.us>
Paul Fox <pgf@foxharp.boston.ma.us> writes:
> when i implemented the change, i wondered if some twisted emacs
> workflow would be an issue. ;-) and i almost blocked SIGQUIT as
> well -- the two programs i looked at for precedent (CVS and MH) both
> block both SIGQUIT and SIGINT when spawning an editor.
>
> but since emacs users must have dealt with CVS for a long time before
> dealing with git, how might they have done so?
I think I usually ran CVS via vc.el, which prompts for a commit
message in Emacs before it runs cvs commit. So CVS did not need
to run $EDITOR.
I just tried emacsclient with CVS 1.12.13-MirDebian-9, and it
behaves somewhat differently from Git with pf/editor-ignore-sigint.
When I tell Emacs to send SIGINT to the *Shell* buffer, CVS prompts:
cvs commit: warning: editor session failed
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
Action: (continue)
and then I can choose to abort.
With strace, it looks like CVS sets SIG_IGN as the handler of
SIGINT and SIGQUIT only in the parent process after forking, not
in the child process that executes the editor.
CVS also temporarily blocks signals by calling sigprocmask, but
it undoes that before it forks or waits for the child process.
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: A Large Angry SCM @ 2012-11-10 19:25 UTC (permalink / raw)
To: Felipe Contreras, Michael J Gruber, Git Mailing List; +Cc: Jeff King
In-Reply-To: <CAMP44s219Zi2NPt2vA+6Od_sVstFK85OXZK-9K1OCFpVh220+A@mail.gmail.com>
On 11/10/2012 01:43 PM, Felipe Contreras wrote:
> On Sat, Nov 10, 2012 at 6:28 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 09.11.2012 15:34:
>>> On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>
>>>> Hg seems to store just anything in the author field ("committer"). The
>>>> various interfaces that are floating around do some behind-the-back
>>>> conversion to git format. The more conversions they do, the better they
>>>> seem to work (no erroring out) but I'm wondering whether it's really a
>>>> good thing, or whether we should encourage a more diligent approach
>>>> which requires a user to map non-conforming author names wilfully.
>>>
>>> So you propose that when somebody does 'git clone hg::hg hg-git' the
>>> thing should fail. I hope you don't think it's too unbecoming for me
>>> to say that I disagree.
>>
>> There is no need to disagree with a proposal I haven't made. I would
>> disagree with the proposal that I haven't made, too.
>
> All right, we shouldn't encourage a more diligent approach which
> requires a user to map author names then.
>
>>> IMO it should be git fast-import the one that converts these bad
>>> authors, not every single tool out there. Maybe throw a warning, but
>>> that's all. Or maybe generate a list of bad authors ready to be filled
>>> out. That way when a project is doing a real conversion, say, when
>>> moving to git, they can run the conversion once and see which authors
>>> are bad and not multiple times, each try taking longer than the next.
>>
>> As Jeff pointed out, git-fast-import expects output conforming to a
>> certain standard, and that's not going to change. import is agnostic to
>> where its import stream is coming from. Only the producer of that stream
>> can have additional information about the provenience of the stream's
>> data which may aid (possibly together with user input or choices) in
>> transforming that into something conforming.
>
> We already know where the import of those streams come from:
> mercurial, bazaar, etc. There's absolutely nothing the tools exporting
> data from those repositories can do, except try to convert all kind of
> weird names--and many tools do it poorly.
>
> So, the options are:
>
> a) Leave the name conversion to the export tools, and when they miss
> some weird corner case, like 'Author<email', let the user face the
> consequences, perhaps after an hour of the process.
>
> We know there are sources of data that don't have git-formatted author
> names, so we know every tool out there must do this checking.
>
> In addition to that, let the export tool decide what to do when one of
> these bad names appear, which in many cases probably means do nothing,
> so the user would not even see that such a bad name was there, which
> might not be what they want.
>
> b) Do the name conversion in fast-import itself, perhaps optionally,
> so if a tool missed some weird corner case, the user does not have to
> face the consequences.
>
> The tool writers don't have to worry about this, so we would not have
> tools out there doing a half-assed job of this.
>
> And what happens when such bad names end up being consistent: warning,
> a scaffold mapping of bad names, etc.
>
>
> One is bad for the users, and the tools writers, only disadvantages,
> the other is good for the users and the tools writers, only
> advantages.
>
c) Do the name conversion, and whatever other cleanup and manipulations
you're interesting in, in a filter between the exporter and git-fast-import.
^ 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