* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 5:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, msysGit
In-Reply-To: <CACsJy8BbUjrJtfpEvbcK==Y2gFNsFhFBN93CL36J5uVe=Ca4wQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> These may apply to other languages as well. Where do we draw a line?
I'm in favor of the general policy of avoiding scripting languages
other than the top three most widely deployed. At the moment that
means shell, Python, Perl; on present trends, in a few years Perl
(dropping in popularity) might be passed by Ruby on the way up.
Or, to put it another way, I'm *not* actually arguing that we ought
to encourage extension commands in Guile or Haskell or whatever else
the in-language-of-the-week is. It would be bad for maintainability
to fragment git's codebase that way.
What I'm arguing is that the tradeoffs within the group {C, shell, Perl,
Python} have changed in ways that favor Python as it has become more
stable and widely deployed. So instead of grudgingly allowing a few
Python extensions in through a back door we ought to be encouraging
more use of it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] emacs: make 'git-status' work with separate git dirs
From: Junio C Hamano @ 2012-11-25 6:22 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Enrico Scholz
In-Reply-To: <1353599934-23222-1-git-send-email-enrico.scholz@sigma-chemnitz.de>
Enrico Scholz <enrico.scholz@sigma-chemnitz.de> writes:
> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
> git, the command fails with
>
> | ... is not a git working tree
>
> This is caused by creating submodules with '--separate-git-dir' but
> still checking for a working tree by testing for a '.git' directory.
>
> The patch fixes this by relaxing the existing detection a little bit.
>
> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
> ---
This script already relies on the assumption that nobody sane would
create a directory named ".git" that is not a git repository, and
this loosens the assumption that nobody would create a file named
".git", either. So I would think it is a sane thing to do, but just
in case if the area expert has better ideas, I am forwarding it.
Ack?
> contrib/emacs/git.el | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 65c95d9..5ffc506 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1671,7 +1671,7 @@ Commands:
> "Entry point into git-status mode."
> (interactive "DSelect directory: ")
> (setq dir (git-get-top-dir dir))
> - (if (file-directory-p (concat (file-name-as-directory dir) ".git"))
> + (if (file-exists-p (concat (file-name-as-directory dir) ".git"))
> (let ((buffer (or (and git-reuse-status-buffer (git-find-status-buffer dir))
> (create-file-buffer (expand-file-name "*git-status*" dir)))))
> (switch-to-buffer buffer)
^ permalink raw reply
* Re: [PATCH] gitk tag delete/rename support
From: Junio C Hamano @ 2012-11-25 6:26 UTC (permalink / raw)
To: Leon KUKOVEC; +Cc: git, Paul Mackerras
In-Reply-To: <1353688894-2526-1-git-send-email-leon.kukovec@gmail.com>
Leon KUKOVEC <leon.kukovec@gmail.com> writes:
> Right clicking on a tag pops up a menu, which allows
> tag to be renamed or deleted.
>
> Signed-off-by: Leon KUKOVEC <leon.kukovec@gmail.com>
> ---
Thanks, but I prefer not to take patches to gitk-git/ directly;
could you prepare a patch against Paul's tree at
git://ozlabs.org/~paulus/gitk
and send it in that direction (paulus@) instead?
> gitk-git/gitk | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 154 insertions(+)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..38cc233 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -2032,6 +2032,7 @@ proc makewindow {} {
> global have_tk85 use_ttk NS
> global git_version
> global worddiff
> + global tagctxmenu
>
> # The "mc" arguments here are purely so that xgettext
> # sees the following string as needing to be translated
> @@ -2581,6 +2582,13 @@ proc makewindow {} {
> {mc "Run git gui blame on this line" command {external_blame_diff}}
> }
> $diff_menu configure -tearoff 0
> +
> + set tagctxmenu .tagctxmenu
> + makemenu $tagctxmenu {
> + {mc "Rename this tag" command mvtag}
> + {mc "Delete this tag" command rmtag}
> + }
> + $tagctxmenu configure -tearoff 0
> }
>
> # Windows sends all mouse wheel events to the current focused window, not
> @@ -6400,6 +6408,7 @@ proc drawtags {id x xt y1} {
> -font $font -tags [list tag.$id text]]
> if {$ntags >= 0} {
> $canv bind $t <1> [list showtag $tag_quoted 1]
> + $canv bind $t $ctxbut [list showtagmenu %X %Y $id $tag_quoted]
> } elseif {$nheads >= 0} {
> $canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
> }
> @@ -8931,6 +8940,113 @@ proc domktag {} {
> return 1
> }
>
> +proc mvtag {} {
> + global mvtagtop
> + global tagmenuid tagmenutag tagctxmenu maintag NS
> + global mvtagtag
> +
> + set mvtagtag $tagmenutag
> + set top .movetag
> + set mvtagtop $top
> + catch {destroy $top}
> + ttk_toplevel $top
> + make_transient $top .
> +
> + ${NS}::label $top.msg -text [mc "Enter a new tag name:"]
> + ${NS}::entry $top.tag -width 60 -textvariable mvtagtag
> +
> + grid $top.msg -sticky w -row 0 -column 0
> + grid $top.tag -sticky w -row 0 -column 1
> +
> + ${NS}::frame $top.buts
> + ${NS}::button $top.buts.gen -text [mc "Rename"] -command mvtaggo
> + ${NS}::button $top.buts.can -text [mc "Cancel"] -command mvtagcan
> + bind $top <Key-Return> mvtaggo
> + bind $top <Key-Escape> mvtagcan
> + grid $top.buts.gen $top.buts.can
> + grid columnconfigure $top.buts 0 -weight 1 -uniform a
> + grid columnconfigure $top.buts 1 -weight 1 -uniform a
> + grid $top.buts - -pady 10 -sticky ew
> +}
> +
> +proc domvtag {} {
> + global mvtagtop env tagids idtags tagmenutag tagmenuid mvtagtag
> +
> + set tag $mvtagtag
> + set id $tagmenuid
> +
> + # add tag
> + # XXX: reuse domktag including keeping comment from the original tag.
> + if {[catch {
> + exec git tag $tag $id
> + } err]} {
> + error_popup "[mc "Error renaming tag:"] $err" $mvtagtop
> + return 0
> + }
> +
> + # delete old tag, content stored in $tagmenutag and $tagmenuid
> + dormtag
> +
> + set tagids($tag) $id
> + lappend idtags($id) $tag
> + redrawtags $id
> + addedtag $id
> + dispneartags 0
> + run refill_reflist
> + return 1
> +}
> +
> +proc rmtag {} {
> + global rmtagtop
> + global tagmenuid tagmenutag tagctxmenu maintag NS
> +
> + set top .maketag
> + set rmtagtop $top
> + catch {destroy $top}
> + ttk_toplevel $top
> + make_transient $top .
> + ${NS}::label $top.title -text [mc "Delete tag"]
> + grid $top.title - -pady 10
> +
> + ${NS}::label $top.msg -text [mc "You are about to delete a tag"]
> + ${NS}::label $top.tagname -foreground Red -text [mc "$tagmenutag"]
> + grid $top.msg -sticky w -row 0 -column 0
> + grid $top.tagname -sticky w -row 0 -column 1
> +
> + ${NS}::frame $top.buts
> + ${NS}::button $top.buts.gen -text [mc "Delete"] -command rmtaggo
> + ${NS}::button $top.buts.can -text [mc "Cancel"] -command rmtagcan
> + bind $top <Key-Return> rmtaggo
> + bind $top <Key-Escape> rmtagcan
> + grid $top.buts.gen $top.buts.can
> + grid columnconfigure $top.buts 0 -weight 1 -uniform a
> + grid columnconfigure $top.buts 1 -weight 1 -uniform a
> + grid $top.buts - -pady 10 -sticky ew
> +}
> +
> +proc dormtag {} {
> + global rmtagtop env tagids idtags tagmenutag tagmenuid
> +
> + set tag $tagmenutag
> + set id $tagmenuid
> +
> + if {[catch {
> + exec git tag -d $tag
> + } err]} {
> + error_popup "[mc "Error deleting tag:"] $err" $rmtagtop
> + return 0
> + }
> +
> + unset tagids($tag)
> + set idx [lsearch $idtags($id) $tag]
> + set idtags($id) [lreplace $idtags($id) $idx $idx]
> +
> + redrawtags $id
> + dispneartags 0
> + run refill_reflist
> + return 1
> +}
> +
> proc redrawtags {id} {
> global canv linehtag idpos currentid curview cmitlisted markedid
> global canvxmax iddrawn circleitem mainheadid circlecolors
> @@ -8974,6 +9090,30 @@ proc mktaggo {} {
> mktagcan
> }
>
> +proc rmtagcan {} {
> + global rmtagtop
> +
> + catch {destroy $rmtagtop}
> + unset rmtagtop
> +}
> +
> +proc rmtaggo {} {
> + if {![dormtag]} return
> + rmtagcan
> +}
> +
> +proc mvtagcan {} {
> + global mvtagtop
> +
> + catch {destroy $mvtagtop}
> + unset mvtagtop
> +}
> +
> +proc mvtaggo {} {
> + if {![domvtag]} return
> + mvtagcan
> +}
> +
> proc writecommit {} {
> global rowmenuid wrcomtop commitinfo wrcomcmd NS
>
> @@ -9288,6 +9428,20 @@ proc headmenu {x y id head} {
> tk_popup $headctxmenu $x $y
> }
>
> +# context menu for a tag
> +proc showtagmenu {x y id tag} {
> + global tagmenuid tagmenutag tagctxmenu maintag
> +
> + stopfinding
> + set tagmenuid $id
> + set tagmenutag $tag
> + set state normal
> +
> + $tagctxmenu entryconfigure 0 -state normal
> + $tagctxmenu entryconfigure 1 -state normal
> + tk_popup $tagctxmenu $x $y
> +}
> +
> proc cobranch {} {
> global headmenuid headmenuhead headids
> global showlocalchanges
^ permalink raw reply
* Re: [PATCH v3] Completion must sort before using uniq
From: Junio C Hamano @ 2012-11-25 6:32 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <CAFj1UpH8h6c7xHuRG6F+pLy5YMvsJ0QdXsotCpLKnht0PsdiNw@mail.gmail.com>
Marc Khouzam <marc.khouzam@gmail.com> writes:
> The user can be presented with invalid completion results
> when trying to complete a 'git checkout' command. This can happen
> when using a branch name prefix that matches multiple remote branches.
>
> For example, if available branches are:
> master
> remotes/GitHub/maint
> remotes/GitHub/master
> remotes/origin/maint
> remotes/origin/master
>
> When performing completion on 'git checkout ma' the user will be
> given the choices:
> maint
> master
> ...
> When dealing with 'git checkout mai', the list will be:
> maint
> maint
Wow, the description feels a tad repetitive for a one liner (it
describes "uniq -u" without pre-sort is wrong at least three times),
it would be better than no log message ;-)
I originally thought "uniq -u" was a misspelled "sort -u" when I
first saw your shorter version, but reading the code to see what is
fed to the command made it immediately obvious "sort | uniq -u" is
the right fix. With the above explanation, you do not even need to
read the code to see what is fed to the command (it is explained ;-).
So, thanks for the fix.
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Michael Haggerty @ 2012-11-25 7:12 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121124122333.BAD7B4065F@snark.thyrsus.com>
On 11/24/2012 01:23 PM, Eric S. Raymond wrote:
> ---
> Documentation/CommandIntegration | 69 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/CommandIntegration
>
> diff --git a/Documentation/CommandIntegration b/Documentation/CommandIntegration
> new file mode 100644
> index 0000000..be248f7
> --- /dev/null
> +++ b/Documentation/CommandIntegration
> @@ -0,0 +1,69 @@
> [...]
> +You must have a test, written to report in TAP (Test Anything Protocol).
> +Tests are executables (usually shell scripts) that live in the 't'
> +subdirectory of the tree. Each test name begins with 't' and a sequence
> +number that controls where in the test sequence it will be executed;
> +conventionally the rest of the name stem is that of the command
> +being tested.
> +
> +If your test requires an example repository, create it yourself in the
> +test script. There is a test library of shell functions that assists
> +wit this; when you use it, the environment is set in a predictable way
> +so the author, committer and timestamps are all set to a single well
> +known value, allowing git to create a commit that is reproducible on
> +all platforms. A test_tick function is used in the scripts to move the
> +clock, allowing different times to be used. For an example see
> +t7502-commit.sh, or really any script in that directory.
I think that here a reference to the file t/README would help (and
perhaps make part of your text redundant).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Eric S. Raymond @ 2012-11-25 8:29 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50B1C4E3.9070500@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> I think that here a reference to the file t/README would help (and
> perhaps make part of your text redundant).
Thank you, done.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-25 8:53 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121125024451.1ADD14065F@snark.thyrsus.com>
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> git presently contains one Python extension command, Pete Wycoff's p4
> importer. If my git-weave code is merged it will acquire another.
> I think we can expect more submissions of Python extensions in the
> future, for two good reasons:
According to the Git User Survey 2012, 1% of the responders used the
'git p4' tool. I don't know how much widely used 'git weave' would be,
but I wouldn't want to star changing policies for issues that are
practically non-existent or irrelevant for the vast majority of git
users.
> We're behind the best-practices curve here. The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a decade ago, and the decision has
> served them well.
If your friends jump off a bridge, would you? Yes, using python has
served them well, but as opposed to what? Other scripting languages? I
don't think so.
> I should also point out that none of Mercurial's problems seem to
> have anything to do with the fact that it's written in Python...
I agree that the _current_ major problems with mercurial are not
related to python, but once those are solved, who says python won't be
an issue?. That's an exercise in guesswork, because we can't know.
> I think we can choose a better policy based on some simple premises.
>
> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
> 2008) and be pretty much guaranteed it will be anywhere we want to
> deploy except Windows. Windows will remain a problem because Python
> isn't part of the stock install, but that's an equal or worse problem
> for shell and Perl - and at least the Python project ships a binary
> installer for Windows.
What if my extension only supports python 2.7? Or what if my extension
wants to support 2.0?
> 2) Python extension commands should test the Python version on startup
> and die loudly but gracefully in the rare case that they don't find
> what they need.
Yes, they should _if_ they know what version they need. In my
extensions I really have no idea.
> 3) We should be unconditionally be encouraging extensions to move
> from shell and Perl to Python. This would be a clear net gain is
> portability and maintainability.
NO! It's up to the developer to choose what language to use, and I
find it very chauvinist of you to say "python is better, so let's all
use python". So far you have listed a few advantages of python, but
you haven't explained so far what is wrong with shell and perl.
In fact, while advancing python you have made clear a problem with
python; the version requirements. So far I have *never* encountered a
problem with git because of my bash version, or my perl version. And
we haven't touched to the python3 mess yet. To me, those are
advantages of shell and perl.
Actually, I don't care if 'git foo' is written in perl, or shell, or
c; as long as it *works*. And I would hate it if 'git rebase' ever
told me that I need a newer version of python, or worst; that I don't
have python in my system (Arch Linux ships 'python2', not 'python').
And what if X developer that wrote Y tool loves perl, and hates
python? Or loves ruby? Are we going to kick him out of the project
because (s)he refuses to switch to python? Are we going to threat him
like an outsider, a rogue developer?
> 4) We should be encouraging C code to move to Python, too. There's
> little gain in portability on this path because modern C has cleaned
> up its act a lot, but the drop in expected bug loads would be well
> worth the porting effort. Segfaults are not your friend, and the x2 to
> x5 drop in line count would do very good things for long-term
> maintainability.
Definitely NO! I really really doubt git in python would be able to
achieve the same performance as git in c, but to show me wrong, it
wouldn't be very difficult to run a few measurements with python
dulwich *if* we are even to begin considering this point.
And are segmentation faults really that different from python's
exceptions? Not to the user.
And why not ruby instead?
If you are serious about this, I think there's a lot more to work to
show that there's anything wrong with the current situation, and that
other alternatives (e.g. ruby) are not good solutions. I for one would
like to see more tools move away from perl/shell, and into C. And
other tools move to ruby, but that it's up to the developers of those
tools, unless I myself do it.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-25 8:56 UTC (permalink / raw)
To: esr; +Cc: Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <20121125051809.GA3670@thyrsus.com>
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>> These may apply to other languages as well. Where do we draw a line?
>
> I'm in favor of the general policy of avoiding scripting languages
> other than the top three most widely deployed. At the moment that
> means shell, Python, Perl; on present trends, in a few years Perl
> (dropping in popularity) might be passed by Ruby on the way up.
Top three according to whom?
According to TIOBE it's python, perl, and ruby (if you don't count VB
or PHP), and perl is beating ruby only by a small margin that will
probably disappear soon. However, shell has advantages none of the
above have.
http://1.1.1.4/bmi/www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Johannes Sixt @ 2012-11-25 8:57 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121125024451.1ADD14065F@snark.thyrsus.com>
Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> That, among other things, means up-to-date versions of Python are
> ubiquitous unless we're looking at Windows - in which case Perl and
> shell actually become much bigger portability problems.
You seem to ignore that more than a quater of users are on Windows[1].
This is not negligible.
Therefore, we *are* looking at Windows. But where is there a portability
problem? There is a POSIX shell available in all git installations on
Windows. So is Perl. Python is not.
[1]
https://git.wiki.kernel.org/index.php/GitSurvey2011#10._On_which_operating_system.28s.29_do_you_use_Git.3F
> 4) We should be encouraging C code to move to Python, too.
Absolutely not. To achieve best portability, all code should move to C
instead.
-- Hannes
^ permalink raw reply
* Re: [PATCH] emacs: make 'git-status' work with separate git dirs
From: Alexandre Julliard @ 2012-11-25 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Enrico Scholz
In-Reply-To: <7v4nkeyzfb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Enrico Scholz <enrico.scholz@sigma-chemnitz.de> writes:
>
>> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
>> git, the command fails with
>>
>> | ... is not a git working tree
>>
>> This is caused by creating submodules with '--separate-git-dir' but
>> still checking for a working tree by testing for a '.git' directory.
>>
>> The patch fixes this by relaxing the existing detection a little bit.
>>
>> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
>> ---
>
> This script already relies on the assumption that nobody sane would
> create a directory named ".git" that is not a git repository, and
> this loosens the assumption that nobody would create a file named
> ".git", either. So I would think it is a sane thing to do, but just
> in case if the area expert has better ideas, I am forwarding it.
>
> Ack?
Sure, that's fine.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Query for certain branches, but not the rest
From: Felipe Contreras @ 2012-11-25 9:24 UTC (permalink / raw)
To: git
Hi,
Suppose I have these branches:
fc/feature-a
fc/feature-b
master
next
I want to show this: fc/feature-a fc/feature-b ^master ^next. I can do
'git log --branches=fc' to show the branches that begin with fc/, but
there's no way to specify the rest. If they were under a prefix, I
could do '--not --branches=prefix', but they are not.
Anybody knows a way to query branches that don't have any prefix?
It appears this works:
% git for-each-ref refs/heads/*
But I would like something parsable by rev-parse.
Any ideas?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 9:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> If your friends jump off a bridge, would you? Yes, using python has
> served them well, but as opposed to what? Other scripting languages? I
> don't think so.
The competition that Python won was *precisely* against other scripting
languages, notably shell and Perl. Both used to be much more heavily
used in system scripting than they are now.
> What if my extension only supports python 2.7? Or what if my extension
> wants to support 2.0?
I propose that if 2.6 can't support it, then that should be considered
grounds to reject it.
> Yes, they should _if_ they know what version they need. In my
> extensions I really have no idea.
Then you shouldn't submit those extensions to be folded into core git.
> > 3) We should be unconditionally be encouraging extensions to move
> > from shell and Perl to Python. This would be a clear net gain is
> > portability and maintainability.
>
> NO! It's up to the developer to choose what language to use,
I agree. You seem to be raising a lot of straw men. 'Encouragement'
does not equate to beating anyone who makes an unpopular choice over
the head.
I am also not suggesting that the whole git core ought to be hoicked
over to Python. I was thinking mainly about extension subcommands,
not what's in libgit now.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 9:54 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <CAMP44s0r1J=aOuEpKQ1+ew9FzODwLX-w5z9rG-WN6AjU0o97yw@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> >> These may apply to other languages as well. Where do we draw a line?
> >
> > I'm in favor of the general policy of avoiding scripting languages
> > other than the top three most widely deployed. At the moment that
> > means shell, Python, Perl; on present trends, in a few years Perl
> > (dropping in popularity) might be passed by Ruby on the way up.
>
> Top three according to whom?
According to the LOC counts in git's codebase.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: git bash does not access drive f:
From: Sebastian Leske @ 2012-11-23 0:58 UTC (permalink / raw)
To: git
In-Reply-To: <CAB9Jk9Ae46PNRex9QrEy9gTgqAbn8KUFifmxQU4s5K5mDDmDZQ@mail.gmail.com>
On 2012-11-22, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:
> Hi
>
> I have attached an external disc, which appears on Windows as drive f:
> in Windows Explorer.
> Right-clicking on it displays a context menu showing (among other
> items) Git Init Here, Git Gui and
> Git Bash. The first two work properly on that drive.
> However, the git bash does not. Not even the one that is run from the icon:
>
> $ cd f:
> sh.exe": cd: f:: No such file or directory
This is probably a known limitation of MSYS (the shell environment that
Git Bash uses, which is part of MingW):
Drive letters added after MSYS has started only become visible if all
MSYS processes are stopped and restarted. See e.g.
How to register newly mounted drive in git bash?
http://stackoverflow.com/questions/5197540/
for some more details.
It seems there is no easy workaround, so you'll need to close all Git
Bash windows and reopen them.
^ permalink raw reply
* Re: Re: Python extension commands in git - request for policy change
From: Pat Thoyts @ 2012-11-25 10:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Eric S. Raymond, git, msysGit
In-Reply-To: <CACsJy8BbUjrJtfpEvbcK==Y2gFNsFhFBN93CL36J5uVe=Ca4wQ@mail.gmail.com>
On 25 November 2012 03:15, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> CCing msysgit. I vaguely remember they had problems with building
> Python on Windows. I don't know if it's still an issue.
>
> On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> git presently contains one Python extension command, Pete Wycoff's p4
>> importer. If my git-weave code is merged it will acquire another.
>> I think we can expect more submissions of Python extensions in the
>> future, for two good reasons:
>>
>> 1. Python has a much richer type ontology than shell; there are many
>> things this makes relatively easy that are quite painful in shell.
>>
>> 2. While Perl shares advantage #1, compared to Python it's a
>> maintainability mess - much more difficult to read 6 months later.
>>
>> On the other hand,
>>
>> 3. Attitudes in the git dev group seem to be influenced by a
>> perception that up-to-date Python versions are not as reliably present
>> on our target platforms as Perl is.
>>
>> 4. Python has the disadvantage that comes with robust growth; you have
>> to specify "version x.y or later" as a dependency, mainly because new
>> modules keep getting getting folded into the stock Python environment.
>
> These may apply to other languages as well. Where do we draw a line?
>
>
>> Previous conversation on the list suggests that there has been a tacit
>> policy of managing these problems by (a) discouraging (though not entirely
>> forbidding) Python extensions, and (b) requiring extension submitters to
>> document some dependency on language version.
>>
>> I think this is suboptimal. By not forbidding the Python language
>> entirely, we guarantee having to deal with problems 3 and 4 anyway -
>> but by discouraging it, we're buying significant long-term
>> maintainability costs. It especially disturbed me to hear of Python
>> commands being recoded in C - that is definitely not the right
>> direction for reducing expected defect counts, if only because of
>> memory-management issues.
>>
>> We're behind the best-practices curve here. The major Linux
>> distributions, which have to deal with almost the same set of
>> tradeoffs we do, went to Python for pretty much all glue and
>> administration scripts outside /etc a decade ago, and the decision has
>> served them well.
>>
>> That, among other things, means up-to-date versions of Python are
>> ubiquitous unless we're looking at Windows - in which case Perl and
>> shell actually become much bigger portability problems. Mac OS X
>> has kept up to date, too; Lion shipped 2.7.1 and that was a major
>> release back at this point.
>>
>> To be fair, there was a time when being a bit twitchy about Python
>> version skew and deployment breadth was justified, but I believe that
>> time is now well past us. My basis for believing this is very simple -
>> I maintain a lot of Python code for systems programmers with stiff
>> portability requirements (things like reposurgeon, coverity-submit,
>> freecode-submit, shipper, and the Python tools in gpsd). I know what
>> kinds of bug reports I get and what kinds I don't, and in the last
>> few years "this breaks on my Python version" has gone from unusual
>> to doesn't-happen.
>>
>> I think my experience with gpsd is particularly instructive. Like
>> git, that project has a C core with Python wrappers and extension
>> components. Like git, it gets deployed in a lot of odd places by people
>> who cannot afford the time to be tolerant about cross-platform
>> problems and are quite willing to hit the maintainer with a clue-bat
>> when they encounter them. The good news is - they don't have to.
>>
>> I should also point out that none of Mercurial's problems seem to
>> have anything to do with the fact that it's written in Python...
>>
>> I think we can choose a better policy based on some simple premises.
>>
>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>> 2008) and be pretty much guaranteed it will be anywhere we want to
>> deploy except Windows. Windows will remain a problem because Python
>> isn't part of the stock install, but that's an equal or worse problem
>> for shell and Perl - and at least the Python project ships a binary
>> installer for Windows.
>>
>> 2) Python extension commands should test the Python version on startup
>> and die loudly but gracefully in the rare case that they don't find
>> what they need.
>>
>> 3) We should be unconditionally be encouraging extensions to move
>> from shell and Perl to Python. This would be a clear net gain is
>> portability and maintainability.
>>
>> 4) We should be encouraging C code to move to Python, too. There's
>> little gain in portability on this path because modern C has cleaned
>> up its act a lot, but the drop in expected bug loads would be well
>> worth the porting effort. Segfaults are not your friend, and the x2 to
>> x5 drop in line count would do very good things for long-term
>> maintainability.
Git for Windows simply ships everything we need to run git - so if a
desirable module requires a version of python, we will add that
version plus any required modules into the installer. We already have
a patch to provide python in the msysgit tree - it would just require
polishing up a little. I'm certain this is no problem for the other
windows port (cygwin) either.
--
*** 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: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 10:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <50B1DD78.5040907@kdbg.org>
Johannes Sixt <j6t@kdbg.org>:
> Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> > That, among other things, means up-to-date versions of Python are
> > ubiquitous unless we're looking at Windows - in which case Perl and
> > shell actually become much bigger portability problems.
>
> You seem to ignore that more than a quater of users are on Windows[1].
> This is not negligible.
I'm not ignoring that at all. There are questions of fact here:
Are Perl and a POSIX shell part of the stock installation of Windows?
I believe the answer is "no". You are free to correct me, but if that's
true they don't have any obvious portability advantage over Python.
That means the 25% percent of Windows users are not actually a reason
to prefer them.
> Absolutely not. To achieve best portability, all code should move to C
> instead.
I wrote the (first) book on C portability. I mean that literally -
"Portable C and Unix Systems Programming", Prentice-Hall 1987. Please
don't feel insulted when I point out that over the last 25 years I
have probably forgotten more about this topic than you know. Just
listen when I tell you that it is not at all obvious that raw C is the
maximally portable language.
It may very well be the case that some random scripting language (not
necessarily Python) achieves greater portability simply because its
maintainers get to pay more concentrated attention to the portability
of the environment bindings at the bottom of their C implementation than
we can.
In any case, I don't believe the difference in portability between raw
C and Python is large enough in either direction to be a reason to
favor either, and I speak as a domain expert on this issue. This is
not Python advocacy talking; the same could be said of Perl or Ruby.
The real advantages of a scripting language are in maintainability and
expected defect rates, not portability. The three relevant things we kbnow
from large-scale studies of software defect patterns are these:
1) Expected defect counts are predictable from LOC.
2) Moving to any given scripting language from C dramatically reduces LOC,
and thus expected defects over time.
3) Moving to any scripting language from C eliminates a class of
memory-management problems that dominate C defect statistics.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 10:33 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <CABNJ2G+CevGU=-DjC073yGv0gupd9QK6eyjhrrQTNNmTkq_fxg@mail.gmail.com>
Pat Thoyts <patthoyts@gmail.com>:
> Git for Windows simply ships everything we need to run git - so if a
> desirable module requires a version of python, we will add that
> version plus any required modules into the installer. We already have
> a patch to provide python in the msysgit tree - it would just require
> polishing up a little. I'm certain this is no problem for the other
> windows port (cygwin) either.
Thank you - I think this completely disposes of the "Windows is a blocker
for scripting language X" argument, with the case X = Python in point.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
--
*** 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
* [PATCH 4/4] git-svn: Note about tags.
From: Sebastian Leske @ 2012-11-23 7:29 UTC (permalink / raw)
Cc: Eric Wong
In-Reply-To: <b115a546fa783b4121d118bb8fdb9270443f90fa.1353691892.git.Sebastian.Leske@sleske.name>
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 92780ef..6212b24 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -938,6 +938,12 @@ the possible corner cases (git doesn't do it, either). Committing
renamed and copied files is fully supported if they're similar enough
for git to detect them.
+In SVN, it is possible (though discouraged) to commit changes to a tag
+(because a tag is just a directory copy, thus technically the same as a
+branch). When cloning an SVN repository, 'git svn' cannot know if such a
+commit to a tag will happen in the future. Thus it acts conservatively
+and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
+
CONFIGURATION
-------------
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/4] git-svn: Expand documentation for --follow-parent
From: Sebastian Leske @ 2012-11-23 7:13 UTC (permalink / raw)
Cc: Eric Wong
In-Reply-To: <b115a546fa783b4121d118bb8fdb9270443f90fa.1353691892.git.Sebastian.Leske@sleske.name>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 928a961..92780ef 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -628,11 +628,19 @@ ADVANCED OPTIONS
Default: "svn"
--follow-parent::
+ This option is only relevant if we are tracking branches (using
+ one of the repository layout options --trunk, --tags,
+ --branches, --stdlayout). For each tracked branch, try to find
+ out where its revision was copied (i.e. branched) from, and set
+ a suitable parent in the first git commit for the branch.
This is especially helpful when we're tracking a directory
- that has been moved around within the repository, or if we
- started tracking a branch and never tracked the trunk it was
- descended from. This feature is enabled by default, use
- --no-follow-parent to disable it.
+ that has been moved around within the repository (note that you
+ must track both the old and the new name for the whole history
+ to be imported). If this feature is disabled, the branches
+ created by 'git svn' will all be linaear and not share any
+ history, meaning that there will be no information on where
+ branches where branched off or merged. This feature is enabled
+ by default, use --no-follow-parent to disable it.
+
[verse]
config key: svn.followparent
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/4] git-svn: Document branches with at-sign(@).
From: Sebastian Leske @ 2012-11-18 17:08 UTC (permalink / raw)
Cc: Eric Wong
git svn will sometimes create branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn will create them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
I found various important features of git-svn that are not documented.
Thus I created a series of patches to add and update documentation for
git-svn. I am sending this as four patches (of which this mail is the
first). I have tried my best to make the patches ready for inclusion
into git, but if there's any feedback, I'll gladly incorporate it.
Documentation/git-svn.txt | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 8b0d3ad..482d60d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -881,6 +881,32 @@ different name spaces. For example:
branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*
+If 'git svn' is configured to fetch branches (and --follow-branches
+is in effect), it will sometimes create multiple branches for one SVN
+branch, where the addtional branches have names of the form
+'branchname@nnn' (with nnn an SVN revision number). These additional
+branches are created if 'git svn' cannot find a parent commit for the
+first commit in the branch, to connect the branch to the history of the
+other branches. Normally, 'git svn' will find the git commit that
+corresponds to the SVN revision a branch was created (copied) from and
+use that as the parent. However, it is possible that there is no
+suitable git commit to serve as parent. This will happen, among other
+reasons, if the SVN branch is a copy of a revision that was not fetched
+by 'git svn' (e.g. because it is an old revision that was skipped with
+'--revision'), or if in SVN a directory was copied that is not tracked
+by 'git svn' (a branch that is not tracked at all, or a subdirectory of
+a tracked branch). In these cases, 'git svn' will still create a git
+branch, but the branch will not be connected to the history of the other
+branches. 'git svn' will also create a commit from the SVN revision the
+branch was copied from, and use that as the parent commit of the branch
+(this is indicated by the message "Initializing parent: <branchname>").
+Additionally, it will create a special branch named
+'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
+number the branch was copied from. This branch will point to the
+specially created parent commit.
+If in SVN the branch was deleted and later recreated from a different
+version, there will be multiple such branches with an '@'.
+
BUGS
----
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] Recommend use of structure options for git svn.
From: Sebastian Leske @ 2012-11-21 7:13 UTC (permalink / raw)
Cc: Eric Wong
In-Reply-To: <b115a546fa783b4121d118bb8fdb9270443f90fa.1353691892.git.Sebastian.Leske@sleske.name>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 482d60d..928a961 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -871,6 +871,16 @@ already dcommitted. It is considered bad practice to --amend commits
you've already pushed to a remote repository for other users, and
dcommit with SVN is analogous to that.
+When cloning an SVN repository, if none of the options for describing
+the repository layout is used (--trunk, --tags, --branches,
+--stdlayout), 'git svn clone' will create a git repository with
+completely linear history, where branches and tags appear as separate
+folders in the working copy. For projects with many branches this will
+lead to a working copy many times larger than just the trunk. It is
+recommended to either use the the options for trunk / tag / branch
+directory, or to only clone the trunk (or a subdirectory of the
+trunk).
+
When using multiple --branches or --tags, 'git svn' does not automatically
handle name collisions (for example, if two branches from different paths have
the same name, or if a branch and a tag have the same name). In these cases,
--
1.7.10.4
^ permalink raw reply related
* Re: Python extension commands in git - request for policy change
From: Michael Haggerty @ 2012-11-25 10:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Eric S. Raymond, git
In-Reply-To: <CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com>
On 11/25/2012 09:53 AM, Felipe Contreras wrote:
> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>> 2008) and be pretty much guaranteed it will be anywhere we want to
>> deploy except Windows. Windows will remain a problem because Python
>> isn't part of the stock install, but that's an equal or worse problem
>> for shell and Perl - and at least the Python project ships a binary
>> installer for Windows.
>
> What if my extension only supports python 2.7? Or what if my extension
> wants to support 2.0?
There would obviously have to be a policy like "all Python code in core
git must run on any Python interpreter with 2.6 <= version < 3.0", just
as there are policies about what C and shell features are allowed. If
you happen to want to support earlier versions of Python, I don't see
why anybody would stop you as long as your code also runs in the
mandated versions.
(In practice, backwards compatibility within Python versions 2.x is very
good and almost any code that runs in Python 2.6 would automatically run
in all later 2.x versions. Moreover, the Python documentation covering
what is available in each version and the deltas between versions is
high-quality and easily available online.)
There is, of course, the awkward issue of how/when to transition to
Python 3.x, which is *not* backwards compatible with Python 2.x. I
expect that when the time comes there will be volunteers (myself
included) willing to help adapt Python scripts to the new version, but
the problem shouldn't be minimized.
Of course Perl will have the same problem if Perl6 ever materializes.
>> 2) Python extension commands should test the Python version on startup
>> and die loudly but gracefully in the rare case that they don't find
>> what they need.
>
> Yes, they should _if_ they know what version they need. In my
> extensions I really have no idea.
Then simply (with the help of the mailing list) ensure that your
extensions run under 2.6 (or whatever the chosen minimum version is) and
everything will be OK. It is not an error to specify 2.6 as the minimum
version even though your script happens also to run on older versions :-)
>> 3) We should be unconditionally be encouraging extensions to move
>> from shell and Perl to Python. This would be a clear net gain is
>> portability and maintainability.
>
> NO! It's up to the developer to choose what language to use, and I
> find it very chauvinist of you to say "python is better, so let's all
> use python". So far you have listed a few advantages of python, but
> you haven't explained so far what is wrong with shell and perl.
Given that some languages are accepted in git-core and others are not,
it's already not "up to the developer to choose what language to use".
At best there is a short list of "blessed" languages, and the developer
can choose among only those.
> In fact, while advancing python you have made clear a problem with
> python; the version requirements. So far I have *never* encountered a
> problem with git because of my bash version, or my perl version. And
> we haven't touched to the python3 mess yet. To me, those are
> advantages of shell and perl.
On the contrary, there is *constant* traffic on the mailing list about
incompatibilities between different shell implementations (sh, dash,
bash, etc), not to mention those in other utilities (sed, grep, etc)
that one is forced to work with in shell scripts. Compatibility is a
*huge* pain when developing shell code for git. The fact that users
typically don't encounter such problems is due to the hard work of POSIX
lawyers on the mailing list correcting the compatibility errors of
mortal programmers.
> Actually, I don't care if 'git foo' is written in perl, or shell, or
> c; as long as it *works*. And I would hate it if 'git rebase' ever
> told me that I need a newer version of python, or worst; that I don't
> have python in my system (Arch Linux ships 'python2', not 'python').
The configure script would locate the correct interpreter and the build
would adjust the scripts' shebang lines, just as things are tweaked
within Perl scripts at build time.
>> 4) We should be encouraging C code to move to Python, too. There's
>> little gain in portability on this path because modern C has cleaned
>> up its act a lot, but the drop in expected bug loads would be well
>> worth the porting effort. Segfaults are not your friend, and the x2 to
>> x5 drop in line count would do very good things for long-term
>> maintainability.
>
> Definitely NO! I really really doubt git in python would be able to
> achieve the same performance as git in c, but to show me wrong, it
> wouldn't be very difficult to run a few measurements with python
> dulwich *if* we are even to begin considering this point.
>
> And are segmentation faults really that different from python's
> exceptions? Not to the user.
There is one huge difference: it C it is all too easy to write code that
leads to a security hole due to buffer overflows and other memory
management errors. Code written in a scripting language are largely
immune to such problems (except of course for any such bugs in the
interpreter itself, but the testing of the interpreter is shared across
many projects and users).
It would be insane to rewrite performance-critical C code in any
scripting language, but there is a huge penumbra of code that is not
performance critical and that mutates rapidly. Such code is much easier
to write and maintain in a sane scripting language if the portability
issues can be mastered.
The most important issues to consider when imagining a future with a
hybrid of code in C and some scripting language "X" are:
* Portability: is "X" available on all platforms targeted by git, in
usable and mutually-compatible versions?
* Startup time: Is the time to start the "X" interpreter prohibitive?
(On my computer, "python -c pass", which starts the Python
interpreter and does nothing, takes about 24ms.) This overhead would
be incurred by every command that is not pure C.
* Should the scripting language access the C functionality only by
calling pure-C executables or by dynamically or statically linking to
a binary module interface? If the former, then the granularity of
interactions between "X" and C is necessarily coarse, and "X" cannot
be used to implement anything but the outermost layer of
functionality. If the latter, then the way would be clear to
implement much more of git in "X" (and lua would also be worth
considering).
* Learning curve for developers: how difficult is it for a typical git
developer to become conversant with "X", considering both (1) how
likely is it that the typical git developer already knows "X" and
(2) how straightforward and predictable is the language "X"?
In this category I think that Python has a huge advantage over
Perl, though certainly opinions will differ and Ruby would also be
a contender.
Personally, I regret wasting my time programming pointer arithmetic in
git modules that are not performance-critical (and correcting bugs by
others in these areas). And I'm tired of having an idea to improve a
git feature only to find that it is implemented in shell, where not even
arrays are available. I would therefore welcome more friendliness
towards a decent scripting language in the git project.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 10:57 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Felipe Contreras, git
In-Reply-To: <50B1F684.5020805@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> There is, of course, the awkward issue of how/when to transition to
> Python 3.x, which is *not* backwards compatible with Python 2.x. I
> expect that when the time comes there will be volunteers (myself
> included) willing to help adapt Python scripts to the new version, but
> the problem shouldn't be minimized.
2to3 actually does a pretty good job. It doesn't reduce the
transition cost to zero, but I find it does reduce that cost to an
easily manageable level even on quite large codebases.
> It would be insane to rewrite performance-critical C code in any
> scripting language, but there is a huge penumbra of code that is not
> performance critical and that mutates rapidly.
Indeed. In the git architecture there is a pretty clear dividing line -
to a first approximation, plumbing should remain C but porcelain should
probably not. (Not that I am advocating forcing such a move - but it would
be good to allow it to happen.)
The 80-20 rule (80% of the execution time is spent in 20% of the code)
helps us here. The *other* 80% of the code can move to a scripting
language with no significant performance loss. To find out what needs
to stay in C, run a profiler!
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH 0/8] Add function strbuf_addstr_xml_quoted() and more
From: Michael Haggerty @ 2012-11-25 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Michael Haggerty
There were two functions doing almost the same XML quoting of
character entities, so implement a library function
strbuf_addstr_xml_quoted() and use that in both places.
Along the way, do a lot of simplification within imap-send.c, which
was doing a lot of its own string management instead of using strbuf.
Please note that "git imap-send" is utterly absent from the test
suite, probably due to the difficulty of testing without a real IMAP
server. I ran some manual tests after my changes and didn't find any
problems.
The bug that I reported on 2012-11-12, namely that
git format-patch --signoff --stdout --attach origin | git imap-send
is broken, is not addressed by these patches.
Michael Haggerty (8):
Add new function strbuf_add_xml_quoted()
xml_entities(): use function strbuf_addstr_xml_quoted()
lf_to_crlf(): NUL-terminate msg_data::data
imap-send: store all_msgs as a strbuf
imap-send: correctly report errors reading from stdin
imap-send: change msg_data from storing (char *, len) to storing
strbuf
wrap_in_html(): use strbuf_addstr_xml_quoted()
wrap_in_html(): process message in bulk rather than line-by-line
http-push.c | 23 +--------
imap-send.c | 157 +++++++++++++++++++++++++++---------------------------------
strbuf.c | 26 ++++++++++
strbuf.h | 6 +++
4 files changed, 104 insertions(+), 108 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 1/8] Add new function strbuf_add_xml_quoted()
From: Michael Haggerty @ 2012-11-25 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Michael Haggerty
In-Reply-To: <1353841721-16269-1-git-send-email-mhagger@alum.mit.edu>
Substantially the same code is present in http-push.c and imap-send.c,
so make a library function out of it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
strbuf.c | 26 ++++++++++++++++++++++++++
strbuf.h | 6 ++++++
2 files changed, 32 insertions(+)
diff --git a/strbuf.c b/strbuf.c
index 05d0693..9a373be 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -425,6 +425,32 @@ void strbuf_add_lines(struct strbuf *out, const char *prefix,
strbuf_complete_line(out);
}
+void strbuf_addstr_xml_quoted(struct strbuf *buf, const char *s)
+{
+ while (*s) {
+ size_t len = strcspn(s, "\"<>&");
+ strbuf_add(buf, s, len);
+ s += len;
+ switch (*s) {
+ case '"':
+ strbuf_addstr(buf, """);
+ break;
+ case '<':
+ strbuf_addstr(buf, "<");
+ break;
+ case '>':
+ strbuf_addstr(buf, ">");
+ break;
+ case '&':
+ strbuf_addstr(buf, "&");
+ break;
+ case 0:
+ return;
+ }
+ s++;
+ }
+}
+
static int is_rfc3986_reserved(char ch)
{
switch (ch) {
diff --git a/strbuf.h b/strbuf.h
index aa386c6..ecae4e2 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -136,6 +136,12 @@ extern void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap);
extern void strbuf_add_lines(struct strbuf *sb, const char *prefix, const char *buf, size_t size);
+/*
+ * Append s to sb, with the characters '<', '>', '&' and '"' converted
+ * into XML entities.
+ */
+extern void strbuf_addstr_xml_quoted(struct strbuf *sb, const char *s);
+
static inline void strbuf_complete_line(struct strbuf *sb)
{
if (sb->len && sb->buf[sb->len - 1] != '\n')
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox