* 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: [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: [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
* 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: 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
* 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
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