* 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: [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
* 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: 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: 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: [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: [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 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] 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] 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: 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: Python extension commands in git - request for policy change
From: Nguyen Thai Ngoc Duy @ 2012-11-25 3:15 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git, msysGit
In-Reply-To: <20121125024451.1ADD14065F@snark.thyrsus.com>
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.
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> Live free or die; death is not the worst of evils.
> -- General George Stark.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Duy
--
*** 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
* Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-25 2:44 UTC (permalink / raw)
To: git
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.
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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Live free or die; death is not the worst of evils.
-- General George Stark.
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Eric S. Raymond @ 2012-11-25 0:06 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20121124151127.GA24459@padd.com>
Working on my revised patch...
Pete Wyckoff <pw@padd.com>:
> Nice start. A few other details; I recently did this for git-p4
> (python).
>
> .gitignore: ignore the auto-generated script, e.g. when
> git-foo.py is built into git-foo.
Added:
3. If your command is implemented in an interpreted language with a
p-code intermediate form, make sure .gitignore in the main directory
includes a pattern entry that ignores such files. Python .pyc and
.pyo files will already be covered.
> INSTALL: note language requirements if odd (see python section)
Added:
4. If your command has dependency on a particular version, document
it in the INSTALL file.
> command-list.txt: categorization of commands for git(1) etc.
Are the values in the right-hand column documented somewhere? What
uses them, and for what purposes.
> RelNotes: Junio generally does this.
Added:
6. When your patch is merged, remind the maintainer to add something
about it in the RelNotes file.
> Also please read Documentation/technical/api-builtin.txt to
> see how to add a built-in command. It also has comments that
> are identical for both built-in and stand-alone command. Could
> be that your text would better go near or with that one, as perhaps
> api-command.txt.
I think this is a good suggestion and will implement it.
If someone can explain the values used in command-list.txt, or (better) point
me to documentation of them, that will enable me to finish the revised patch.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH 0/2] second try
From: Sven Strickroth @ 2012-11-24 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jakub Narebski
In-Reply-To: <509FD4F6.5050606@gym-oha.de>
Hi,
Am 11.11.2012 17:40 schrieb Sven Strickroth:
> Am 06.10.2012 20:28 schrieb Junio C Hamano:
>> It is either that it was simply forgotten, or after I wrote the part
>> you quoted early in January there were discussions later that showed
>> the patch was not desirable for some reason. I do not recall which.
>
> I noticed no threads about possible problems, so I try again.
On November 11th I submitted the updated patches again, however, without
any reaction or comments.
git pull git://github.com/csware/git.git gitsvn-askpass
Maybe the reason that this was forgotten was, that the git-svn code was
rearranged and splitted into different files in the past and the code
did not apply cleanly any more.
So, what's the status of this issue? It's now open for nearly one year.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: Know how much to download before clonig
From: Shawn Pearce @ 2012-11-24 18:10 UTC (permalink / raw)
To: arif; +Cc: git
In-Reply-To: <k8qd1l$l7o$1@ger.gmane.org>
On Sat, Nov 24, 2012 at 4:02 AM, arif <aftnix@gmail.com> wrote:
> Is there any way so that i can tell how much i have to download to
> obtain a full clone (not a shallow one) of a respository?
Ask the repository owner to tell you?
There is no information sent by the server about size of repository,
so no, you can't really know without having the repository owner tell
you through some other side channel.
^ permalink raw reply
* Re: Possible vulnerability to SHA-1 collisions
From: Shawn Pearce @ 2012-11-24 18:09 UTC (permalink / raw)
To: Michael Hirshleifer; +Cc: git
In-Reply-To: <50B0AB9C.2040802@caltech.edu>
I don't think there is an issue the way you have tried to describe
this scenario.
On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111mth@caltech.edu> wrote:
> Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> checksum (including Git header). Mr. Evil creates a local branch with an
> innocuous name like “test-bugfix”, and adds a commit containing a reference
> to the evil file. Separately, using a sockpuppet, Evil Guy creates an
> innocuous bugfix (very likely to be accepted) containing the innocuous file,
> and submits it to Good Guy. Before Good Guy can commit the bugfix, Evil Guy
> pushes the evil branch to Github, and then immediately deletes it; or
> equivalently --force pushes any innocuous commit on top of it. (This is
> unlikely to arouse suspicion, and he can always say he deleted it because it
> didn’t work.)
Here you assume Evil Guy has write access to the same repository as
Good Guy. Lets assume this is possible, e.g. Evil Guy is actually
impersonating White Hat because he managed to steal White Hat's
credentials through a compromised host. Typically Evil Guy doesn't
have write access to Good Guy's repository, and thus can't introduce
objects into it without Good Guy being the one that creates the
objects.
But lets just keep he assumption that Evil Guy can write to the same
repository as Good Guy, and that he managed to create the bad branch
and delete it, leaving the bad object in an unreachable state for 2
weeks.
> Git keeps unreferenced objects around for a few weeks, so when Good Guy
> commits the patch and pushes to Github, an object with an sha1sum that
> matches the good file will already exist in the main repository. Since Git
> keeps the local copy of files when sha1sums match, the main Github
> repository will then contain the evil file associated with Good Guy’s
> commit. Any users cloning from Github will get the evil version. This is an
> exploit.
Typically... Git will fail with an error message when Good Guy pushes.
Good Guy's client will (rightly) believe that the object doesn't exist
on the remote side, after all it is unreachable. So his client will
include it in the pack being transmitted during push. When this pack
arrives on the remote side, the remote will identify it already has an
object named the same as an object coming in the pack. The remote will
do a byte-for-byte compare of both objects. As soon as a single byte
differs, it will abort with an error.
At this point Good Guy can't push to his repository. `git gc
--expire=now` will fix the repository by removing the unreachable
object, at which point Evil Guy's evil object is gone.
> And Good Guy’s local repository will contain the good file; he will not
> notice anything amiss unless he nukes his local repository and clones from
> Github again. Even when the compromise is discovered, there will be no
> reason to suspect Evil Guy; the evil file seems to have been committed by
> Good Guy.
See above. Good Guy would have noticed something is amiss because the
object he sent already existed and didn't match.
> Previous discussion about hash collisions in Git seems to conclude that they
> aren’t a security threat. See
> http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob/9392525#9392525,
> Linus Torvalds arguing that Git’s security doesn’t depend on SHA-1 collision
> resistance.
This is largely true because there are additional defenses (e.g. the
byte for byte compare on identical objects), and for projects like the
Linux kernel there are many eyes looking at files all of the time.
Anything that is amiss would be announced quickly on LKML and
discussed until the root cause is identified and resolved.
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Eric S. Raymond @ 2012-11-24 15:23 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20121124151127.GA24459@padd.com>
Pete Wyckoff <pw@padd.com>:
> Nice start. A few other details; I recently did this for git-p4
> (python).
>
> .gitignore: ignore the auto-generated script, e.g. when
> git-foo.py is built into git-foo.
>
> INSTALL: note language requirements if odd (see python section)
>
> command-list.txt: categorization of commands for git(1) etc.
>
> RelNotes: Junio generally does this.
>
>
> Also please read Documentation/technical/api-builtin.txt to
> see how to add a built-in command. It also has comments that
> are identical for both built-in and stand-alone command. Could
> be that your text would better go near or with that one, as perhaps
> api-command.txt.
Good points. I will submit a revised patch later today.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Pete Wyckoff @ 2012-11-24 15:11 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121124122333.BAD7B4065F@snark.thyrsus.com>
esr@thyrsus.com wrote on Sat, 24 Nov 2012 07:23 -0500:
> +== Integrating a command ==
> +
> +Here are the things you need to do when you want to merge a new
> +subcommand into the git tree.
> +
> +1. Append your command name to one of the variables BUILTIN_OBJS,
> +EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON.
> +
> +2. Drop its test in the t directory.
> +
> +That's all there is to it.
Nice start. A few other details; I recently did this for git-p4
(python).
.gitignore: ignore the auto-generated script, e.g. when
git-foo.py is built into git-foo.
INSTALL: note language requirements if odd (see python section)
command-list.txt: categorization of commands for git(1) etc.
RelNotes: Junio generally does this.
Also please read Documentation/technical/api-builtin.txt to
see how to add a built-in command. It also has comments that
are identical for both built-in and stand-alone command. Could
be that your text would better go near or with that one, as perhaps
api-command.txt.
-- Pete
^ permalink raw reply
* [PATCH] Add documentation on how to integrate commands.
From: Eric S. Raymond @ 2012-11-24 12:23 UTC (permalink / raw)
To: git
---
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 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git.
+
+== Runtime environment ==
+
+git subcommands are standalone executables that live in the git
+execution directory, normally /usr/lib/git-core. The git executable itself
+is a thin wrapper that sets GIT_DIR and passes command-line arguments
+to the subcommand.
+
+(If "git foo" is not found in the git execution directory, the wrapper
+will look in the rest of your $PATH for it. Thus, it's possible
+to write local git extensions that don't live in system space.)
+
+== Implementation languages ==
+
+Most subcommands are written in C or shell. A few are written in
+Perl. A tiny minority are written in Python.
+
+While we strongly encourage coding in portable C for portability, these
+specific scripting languages are also acceptable. We won't accept more
+without a very strong technical case, as we don't want to broaden the
+git suite's required dependencies.
+
+C commands are normally written as single modules, named after the
+command, that link a core library called libgit. Thus, your command
+'git-foo' would normally be implemented as a single "git-foo.c"; this
+organization makes it easy for people reading the code to find things.
+
+See the CodingGuidelines document for other guidance on what we consider
+good practice in C and shell.
+
+== What every extension command needs ==
+
+You must have a man page, written in asciidoc (this is what git help
+followed by your subcommand name will display). Be aware that there is
+a local asciidoc configuration and macros which you should use. It's
+often helpful to start by cloning an existing page and replacing the
+text content.
+
+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.
+
+== Integrating a command ==
+
+Here are the things you need to do when you want to merge a new
+subcommand into the git tree.
+
+1. Append your command name to one of the variables BUILTIN_OBJS,
+EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON.
+
+2. Drop its test in the t directory.
+
+That's all there is to it.
--
1.7.9.5
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The same applies for other kinds of long-lasting low-level pain. [...]
The body's response to being jabbed, pierced, and cut is to produce
endorphins. [...] So here's my programme for breaking that cycle of
dependency on Windows: get left arm tattooed with dragon motif, buy a
crate of Jamaican Hot! Pepper Sauce, get nipples pierced. With any
luck that will produce enough endorphins to make Windows completely
redundant, and I can then upgrade to Linux and get on with things.
-- Pieter Hintjens
^ permalink raw reply related
* Know how much to download before clonig
From: arif @ 2012-11-24 12:02 UTC (permalink / raw)
To: git
Hi,
Is there any way so that i can tell how much i have to download to
obtain a full clone (not a shallow one) of a respository?
--
Cheers
arif
^ permalink raw reply
* Possible vulnerability to SHA-1 collisions
From: Michael Hirshleifer @ 2012-11-24 11:12 UTC (permalink / raw)
To: git
Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
checksum (including Git header). Mr. Evil creates a local branch with an
innocuous name like “test-bugfix”, and adds a commit containing a
reference to the evil file. Separately, using a sockpuppet, Evil Guy
creates an innocuous bugfix (very likely to be accepted) containing the
innocuous file, and submits it to Good Guy. Before Good Guy can commit
the bugfix, Evil Guy pushes the evil branch to Github, and then
immediately deletes it; or equivalently --force pushes any innocuous
commit on top of it. (This is unlikely to arouse suspicion, and he can
always say he deleted it because it didn’t work.)
Git keeps unreferenced objects around for a few weeks, so when Good Guy
commits the patch and pushes to Github, an object with an sha1sum that
matches the good file will already exist in the main repository. Since
Git keeps the local copy of files when sha1sums match, the main Github
repository will then contain the evil file associated with Good Guy’s
commit. Any users cloning from Github will get the evil version. This is
an exploit.
And Good Guy’s local repository will contain the good file; he will not
notice anything amiss unless he nukes his local repository and clones
from Github again. Even when the compromise is discovered, there will be
no reason to suspect Evil Guy; the evil file seems to have been
committed by Good Guy.
Previous discussion about hash collisions in Git seems to conclude that
they aren’t a security threat. See
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob/9392525#9392525,
Linus Torvalds arguing that Git’s security doesn’t depend on SHA-1
collision resistance.
This proposed exploit does not involve social engineering, or any good
guys failing to spot or accepting patches containing evil data (what
Good Guy accepts is a genuine bugfix). It contaminates the main public
repository in a way that Good Guy won’t immediately notice. It does not
require a second-preimage attack; Bad Guy creates both versions of the
file. While this does require the bad guy to have commit access, the bad
guy can avoid suspicion after the attack.
^ permalink raw reply
* [PATCH v3] send-email: avoid questions when user has an ident
From: Felipe Contreras @ 2012-11-24 11:16 UTC (permalink / raw)
To: git
Cc: Jeff King, Junio C Hamano, Thomas Rast, Christian Couder,
Stephen Boyd, Ævar Arnfjörð Bjarmason,
Felipe Contreras
Currently we keep getting questions even when the user has properly
configured his full name and password:
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
And once a question pops up, other questions are turned on. This is
annoying.
The reason it's safe to avoid this question is because currently the
script fails completely when the author (or committer) is not correct,
so we won't even be reaching this point in the code.
The scenarios, and the current situation:
1) No information at all, no fully qualified domain name
fatal: empty ident name (for <felipec@nysa.(none)>) not allowed
2) Only full name
fatal: unable to auto-detect email address (got 'felipec@nysa.(none)')
3) Full name + fqdm
Who should the emails appear to be from?
[Felipe Contreras <felipec@nysa.felipec.org>]
4) Full name + EMAIL
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
5) User configured
6) GIT_COMMITTER
7) GIT_AUTHOR
All these are the same as 4)
After this patch:
1) 2) won't change: git send-email would still die
4) 5) 6) 7) will change: git send-email won't ask the user
This is good, that's what we would expect, because the identity is
explicit.
3) will change: git send-email won't ask the user
This is bad, because we will try with an address such as
'felipec@nysa.felipec.org', which is most likely not what the user
wants, but the user will get warned by default (confirm=auto), and if
not, most likely the sending won't work, which the user would readily
note and fix.
The worst possible scenario is that such mail address does work, and the
user sends an email from that address unintentionally, when in fact the
user expected to correct that address in the prompt. This is a very,
very, very unlikely scenario, with many dependencies:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
7) A sendmail configuration that allows sending from this domain name
8) confirm=never, or
8.1) confirm configuration not hitting, or
8.2) Getting the error, not being aware of it
9) The user expecting to correct this address in the prompt
In a more likely scenario where 7) is not the case (can't send from
nysa.felipec.org), the user will simply see the mail was not sent
properly, and fix the problem.
The much more likely scenario though, is where 5) is not the case
(nysa.(none)), and git send-email will fail right away like it does now.
So the likelihood of this affecting anybody seriously is very very slim,
and the chances of this affecting somebody slightly are still very
small. The vast majority, if not all, of git users won't be affected
negatively, and a lot will benefit from this.
Tests-by: Jeff King <peff@peff.net>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Changes since v2:
* Merge the relevant tests by Jeff King (the rest of the tests might be
useful, but they belong in a separate patch series)
git-send-email.perl | 7 +------
t/t9001-send-email.sh | 5 ++---
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..503e551 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -748,16 +748,11 @@ if (!$force) {
}
}
-my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
- $sender = ask("Who should the emails appear to be from? [$sender] ",
- default => $sender,
- valid_re => qr/\@.*\./, confirm_only => 1);
- print "Emails will be sent from: ", $sender, "\n";
- $prompting++;
}
+my $prompting = 0;
if (!@initial_to && !defined $to_cmd) {
my $to = ask("Who should the emails be sent to (if any)? ",
default => "",
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 0351228..f77f68e 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -191,14 +191,13 @@ test_expect_success $PREREQ 'Show all headers' '
test_expect_success $PREREQ 'Prompting works' '
clean_fake_sendmail &&
- (echo "Example <from@example.com>"
- echo "to@example.com"
+ (echo "to@example.com"
echo ""
) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
2>errors &&
- grep "^From: Example <from@example.com>\$" msgtxt1 &&
+ grep "^From: A U Thor <author@example.com>\$" msgtxt1 &&
grep "^To: to@example.com\$" msgtxt1
'
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-24 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Felipe Contreras
In-Reply-To: <1352643598-8500-1-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> This is a re-roll of the previous series to add support to fetch and push
> special modes, and refactor some related code.
It seems this one got forgotten, I only see v2 in pu.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] fast-export: Allow pruned-references in mark file
From: Antoine Pelisse @ 2012-11-24 9:47 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
fast-export can fail because of some pruned-reference when importing a
mark file.
The problem happens in the following scenario:
$ git fast-export --export-marks=MARKS master
(rewrite master)
$ git prune
$ git fast-export --import-marks=MARKS master
This might fail if some references have been removed by prune
because some marks will refer to non-existing commits.
Let's warn when we have a mark for a commit we don't know.
Also, increment the last_idnum before, so we don't override
the mark.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
builtin/fast-export.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..141b245 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -607,16 +607,19 @@ static void import_marks(char *input_file)
|| *mark_end != ' ' || get_sha1(mark_end + 1, sha1))
die("corrupt mark line: %s", line);
+ if (last_idnum < mark)
+ last_idnum = mark;
+
object = parse_object(sha1);
- if (!object)
- die ("Could not read blob %s", sha1_to_hex(sha1));
+ if (!object) {
+ warning("Could not read blob %s", sha1_to_hex(sha1));
+ continue;
+ }
if (object->flags & SHOWN)
error("Object %s already has a mark", sha1_to_hex(sha1));
mark_object(object, mark);
- if (last_idnum < mark)
- last_idnum = mark;
object->flags |= SHOWN;
}
--
1.7.9.5
^ 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