* [Proof of concept PATCH] implement --prune-empty switch for filter-branch
From: Pierre Habouzit @ 2008-10-30 16:18 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier, Pierre Habouzit
In-Reply-To: <1225383538-23666-2-git-send-email-madcoder@debian.org>
This is not a real patch (lacks a test at least) and is absolutely not
tested, though should basically work as expected.
This is only meant as a basis for discussion.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-filter-branch.txt | 14 ++++++++++++++
git-filter-branch.sh | 26 +++++++++++++++++++++++++-
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..451950b 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -122,6 +122,10 @@ You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use 'git-rebase' instead).
++
+You can also use the 'git_commit_non_empty_tree "$@"' instead of
+'git commit-tree "$@"' if you don't wish to keep commits with a single parent
+and that makes no change to the tree.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -151,6 +155,16 @@ to other tags will be rewritten to point to the underlying commit.
The result will contain that directory (and only that) as its
project root.
+--prune-empty::
+ Some kind of filters will generate empty commits, that left the tree
+ untouched. This switch allow git-filter-branch to ignore such
+ commits. Though, this switch only applies for commits that have one
+ and only one parent, it will hence keep merges points. Also, this
+ option is not compatible with the use of '--commit-filter'. Though you
+ just need to use the function 'git_commit_non_empty_tree "$@"' instead
+ of the 'git commit-tree "$@"' idiom in your commit filter to make that
+ happen.
+
--original <namespace>::
Use this option to set the namespace where the original commits
will be stored. The default value is 'refs/original'.
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 8af3126..9c83402 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -49,6 +49,15 @@ die()
echo "$*" >&2
exit 1
}
+
+git_commit_non_empty_tree()
+{
+ if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
+ map "$3"
+ else
+ git commit-tree "$@"
+ fi
+}
EOF
)
@@ -95,6 +104,7 @@ d= temporary path to use for rewriting
f,force force filter-branch to run
subdirectory-filter= only look at the history touching that specific subdirectory
original= namespace where the original commits will be stored (default: refs/original)
+prune-empty use this if you want to automatically prune empty commits
Filters that you can run:
@@ -121,11 +131,12 @@ filter_tree=
filter_index=
filter_parent=
filter_msg=cat
-filter_commit='git commit-tree "$@"'
+filter_commit=
filter_tag_name=
filter_subdir=
orig_namespace=refs/original/
force=
+prune_empty=
while :
do
case "$1" in
@@ -138,6 +149,8 @@ do
--original)
orig_namespace=$(expr "$2/" : '\(.*[^/]\)/*$')/
shift;;
+ --prune-empty)
+ prune_empty=t;;
--env-filter)
filter_env="$2"; shift;;
@@ -161,6 +174,17 @@ do
shift
done
+case "$prune_empty,$filter_commit" in
+',')
+ filter_commit='git commit-tree "$@"';;
+'t,')
+ filter_commit='git_commit_non_empty_tree "$@"';;
+','*)
+ ;;
+*)
+ die "Cannot set --prune-empty and --filter-commit at the same time"
+esac
+
case "$force" in
t)
rm -rf "$tempdir"
--
1.6.0.3.758.gc29b0
^ permalink raw reply related
* [PATCH] make git-filter-branch use parse-options.
From: Pierre Habouzit @ 2008-10-30 16:18 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier, Pierre Habouzit
In-Reply-To: <1225383538-23666-1-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-filter-branch.sh | 93 +++++++++++++++++++++-----------------------------
1 files changed, 39 insertions(+), 54 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 81392ad..8af3126 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -87,14 +87,26 @@ set_ident () {
echo "case \"\$GIT_${uid}_NAME\" in \"\") GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\" && export GIT_${uid}_NAME;; esac"
}
-USAGE="[--env-filter <command>] [--tree-filter <command>] \
-[--index-filter <command>] [--parent-filter <command>] \
-[--msg-filter <command>] [--commit-filter <command>] \
-[--tag-name-filter <command>] [--subdirectory-filter <directory>] \
-[--original <namespace>] [-d <directory>] [-f | --force] \
-[<rev-list options>...]"
-
-OPTIONS_SPEC=
+OPTIONS_KEEPDASHDASH=
+OPTIONS_SPEC="\
+git filter-branch [options] [<rev-list options>...]
+--
+d= temporary path to use for rewriting
+f,force force filter-branch to run
+subdirectory-filter= only look at the history touching that specific subdirectory
+original= namespace where the original commits will be stored (default: refs/original)
+
+ Filters that you can run:
+
+env-filter= environment filter to run
+tree-filter= tree rewriting filter to run
+index-filter= index rewriting filter to run
+parent-filter= parent rewriting filter to run
+msg-filter= commit message rewriting filter to run
+commit-filter= commit rewriting filter to run
+tag-name-filter= tag name rewriting filter to run
+"
+
. git-sh-setup
if [ "$(is_bare_repository)" = false ]; then
@@ -117,63 +129,36 @@ force=
while :
do
case "$1" in
- --)
- shift
- break
- ;;
--force|-f)
- shift
- force=t
- continue
- ;;
- -*)
- ;;
- *)
- break;
- esac
-
- # all switches take one argument
- ARG="$1"
- case "$#" in 1) usage ;; esac
- shift
- OPTARG="$1"
- shift
-
- case "$ARG" in
+ force=t;;
-d)
- tempdir="$OPTARG"
- ;;
+ tempdir="$2"; shift;;
+ --subdirectory-filter)
+ filter_subdir="$2"; shift;;
+ --original)
+ orig_namespace=$(expr "$2/" : '\(.*[^/]\)/*$')/
+ shift;;
+
--env-filter)
- filter_env="$OPTARG"
- ;;
+ filter_env="$2"; shift;;
--tree-filter)
- filter_tree="$OPTARG"
- ;;
+ filter_tree="$2"; shift;;
--index-filter)
- filter_index="$OPTARG"
- ;;
+ filter_index="$2"; shift;;
--parent-filter)
- filter_parent="$OPTARG"
- ;;
+ filter_parent="$2"; shift;;
--msg-filter)
- filter_msg="$OPTARG"
- ;;
+ filter_msg="$2"; shift;;
--commit-filter)
- filter_commit="$functions; $OPTARG"
- ;;
+ filter_commit="$functions; $2"; shift;;
--tag-name-filter)
- filter_tag_name="$OPTARG"
- ;;
- --subdirectory-filter)
- filter_subdir="$OPTARG"
- ;;
- --original)
- orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
- ;;
+ filter_tag_name="$2"; shift;;
+ --)
+ shift; break;;
*)
- usage
- ;;
+ usage;;
esac
+ shift
done
case "$force" in
--
1.6.0.3.758.gc29b0
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-10-30 16:30 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030144321.GF24098@artemis.corp>
On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
>
> git format-patch origin/next.. works already. I'm used to the asymetric
> git format-patch origin/next syntax, and I would be sorry if it
> disappeared though, and I see no really good reason to get rid of it.
The reason why it annoys me is because I often what to cherry-pick a
single patch to send to someone, and so while "git show 332d2e78"
shows me the patch, but if I want to use git-send-email for that
particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
type "git format-patch 332d2e78^..332d2e78" instead. I've learned to
live with it, but it's annoying each time I have to do it.
More generally, the fact that the CLI has different ways the same set
of arguments can be decoded can be quite confusing. The most obvious
way this turns up is to consider which set of commits are
displayed/formatted via these three commands:
git format-patch 332d2e78
git show 332d2e78
git log -p 332d2e78
The first formats all patches that follow commit 332d2e78 (not
including commit 332d2e78), the second shows just commit 332d2e78, and
the last prints all commits starting at 332d2e78 and before it.
For many workflows, the default way a single commit-id is interpreted
makes a lot of sense. But for a newcomer, it's very confusing. I'm
not saying that we should collapse everything down to a single way of
doing things, but git format-patch is an exception, and I don't think
anything else actually works that way; looking at the man page makes
it clear that it treats its argument as a revision range EXCEPT when
only a single commit is specified.
It can be justified, and maybe it's convenient enough that this is one
of those places where tutorials should just explicitly call this out
as one of those exceptions that make sense given common workflows.
But just as English can be heard to learn because "though", "through",
"plough", "cough", and "tough" don't rhyme even though they look like
they should (even though native speakers have no problem with it),
similarly this is one of those inconsistencies that makes git hard to
learn.
(And I get annoyed when I want to run git format-patch on a single
patch not at the tip of the tree; but if it's just me, I can write a
"git format-single-patch" wrapper script to get around it.)
- Ted
^ permalink raw reply
* [PATCH] Documented --no-checkout option in git-svn
From: _vi @ 2008-10-30 16:08 UTC (permalink / raw)
To: git; +Cc: gitster, Vitaly "_Vi" Shukela
From: Vitaly "_Vi" Shukela <public_vi@tut.by>
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
---
Documentation/git-svn.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 84c8f3c..90784a5 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
tracking. The name of the [svn-remote "..."] section in the
.git/config file may be specified as an optional command-line
argument.
+
+--no-checkout
+ Do not checkout latest revision after fetching.
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
@@ -103,6 +106,9 @@ COMMANDS
the working tree; and the 'rebase' command will be able
to update the working tree with the latest changes.
+--no-checkout
+ Do not checkout latest revision after fetching.
+
'rebase'::
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-30 16:43 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030163056.GA8899@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
On Thu, Oct 30, 2008 at 04:30:56PM +0000, Theodore Tso wrote:
> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
> >
> > git format-patch origin/next.. works already. I'm used to the asymetric
> > git format-patch origin/next syntax, and I would be sorry if it
> > disappeared though, and I see no really good reason to get rid of it.
>
> The reason why it annoys me is because I often what to cherry-pick a
> single patch to send to someone, and so while "git show 332d2e78"
> shows me the patch, but if I want to use git-send-email for that
> particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
> type "git format-patch 332d2e78^..332d2e78" instead. I've learned to
> live with it, but it's annoying each time I have to do it.
[...]
> (And I get annoyed when I want to run git format-patch on a single
> patch not at the tip of the tree; but if it's just me, I can write a
> "git format-single-patch" wrapper script to get around it.)
In fact I believe that what we lack is a shorthand for:
$sha1^..$sha1 because that would solve both of your issues, and it's
something that has bothered me in the past too for other commands.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Sam Vilain @ 2008-10-30 16:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, git
In-Reply-To: <4909A7C4.30507@op5.se>
On Thu, 2008-10-30 at 13:25 +0100, Andreas Ericsson wrote:
> >> Ok, now I'm confused. The ONLY thing I want to prevent is the
> >> "crossing of streams" issue. If I am on branch X and issue 'git
> >> push', I want X, and ONLY X, to be pushed to the remote repository's X
> >> branch --- I don't care if other branches are pushed to their
> >> respective remote branches, as long as they don't get merged to X.
> This particular bikeshed was painted a long time ago, with the consensus
> going in favour of "git push" pushing all *matching* refspecs.
I realise that - I just found it interesting that there was a user who
explicitly expected this not to be the case.
Which I think is reasonable, because it's what 'git pull' does. I
myself have encountered many people who did not like the current default
behaviour. I think far from "bikeshedding" this is quite an important
part of the ui experience.
Sam.
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Sam Vilain @ 2008-10-30 5:29 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Junio C Hamano, Jeff King, René Scharfe
In-Reply-To: <81b0412b0810290338j1beaa25bx9fb373a69f5dfe7@mail.gmail.com>
On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
> I could not find what exactly does the ActiveState's Perl use for its stat
> implementation (and honestly, have no motivation to look harder).
> It seems to honor TZ, but the produced time does not seem to be either
> local or GMT.
See, the difference is that the perl is portable and your patch isn't.
Can you at least reveal how far out the value printed by the perl
fragment was from the expected value, and what your TZ offset is in
seconds. It might be pointing to a deeper problem that could affect
more than just this test case.
Sam.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Nicolas Pitre @ 2008-10-30 16:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Mike Hommey, Shawn O. Pearce, Sam Vilain, git
In-Reply-To: <20081030150135.GG24098@artemis.corp>
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
> On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:
> > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > +1 to Nico's NAK.
> > >
> > > Although I was at the GitTogether I don't remember this change to
> > > checkout being discussed. I must have been asleep reading email
> > > or something. I am _NOT_ in favor of this change; I think the
> > > current behavior of "git checkout origin/master" is correct and as
> > > sane as we can make it.
> >
> > Except he was talking about 'git checkout branch', not 'git checkout
> > origin/branch'. And I would be fine with 'git checkout branch' doing
> > what 'git checkout -b branch $remote/branch' does if $remote is unique
> > (i.e. there is no other 'branch' branch in any other remote) and the
> > 'branch' branch doesn't already exist.
>
> Seconded.
>
> Having git-checkout $foo being a shorthand for git checkout -b $foo
> origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
No. This is only the first step towards insanity.
In many cases origin/$foo == origin/master so this can't work in that
case which is, after all, the common case. Therefore I think this is
wrong to add magic operations which are not useful for the common case
and actively _hide_ how git actually works. Not only will you have to
explain how git works anyway for that common origin/master case, but
you'll also have to explain why sometimes the magic works and sometimes
not. Please keep such convenience shortcuts for your own scripts and/or
aliases.
Nicolas
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Nicolas Pitre @ 2008-10-30 17:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Theodore Tso, Sam Vilain, git
In-Reply-To: <vpqmygmw1mr.fsf@bauges.imag.fr>
On Thu, 30 Oct 2008, Matthieu Moy wrote:
> I've already argued in favor of allowing "git reset --hard <files>",
> which is consistant with existing terminology and doesn't add an extra
> command, but without success.
If you have a file argument, the --hard option is redundant, isn't it?
So what about simply "git reset <file>" ?
Nicolas
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Nicolas Pitre @ 2008-10-30 17:03 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030163056.GA8899@mit.edu>
On Thu, 30 Oct 2008, Theodore Tso wrote:
> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
> >
> > git format-patch origin/next.. works already. I'm used to the asymetric
> > git format-patch origin/next syntax, and I would be sorry if it
> > disappeared though, and I see no really good reason to get rid of it.
>
> The reason why it annoys me is because I often what to cherry-pick a
> single patch to send to someone, and so while "git show 332d2e78"
> shows me the patch, but if I want to use git-send-email for that
> particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
> type "git format-patch 332d2e78^..332d2e78" instead.
try:
git show --pretty=email 332d2e78
Nicolas
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-30 17:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, Theodore Tso, Sam Vilain, git
In-Reply-To: <alpine.LFD.2.00.0810301259130.13034@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
> On Thu, 30 Oct 2008, Matthieu Moy wrote:
>
> > I've already argued in favor of allowing "git reset --hard <files>",
> > which is consistant with existing terminology and doesn't add an extra
> > command, but without success.
>
> If you have a file argument, the --hard option is redundant, isn't it?
> So what about simply "git reset <file>" ?
errrrm, git reset <file> resets the index notion of the file to its status
in HEAD... which I'm sure is *somehow* useful to "some" people ;P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Nicolas Pitre @ 2008-10-30 17:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Matthieu Moy, Theodore Tso, Sam Vilain, git
In-Reply-To: <20081030170329.GK24098@artemis.corp>
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
> > On Thu, 30 Oct 2008, Matthieu Moy wrote:
> >
> > > I've already argued in favor of allowing "git reset --hard <files>",
> > > which is consistant with existing terminology and doesn't add an extra
> > > command, but without success.
> >
> > If you have a file argument, the --hard option is redundant, isn't it?
> > So what about simply "git reset <file>" ?
>
> errrrm, git reset <file> resets the index notion of the file to its status
> in HEAD... which I'm sure is *somehow* useful to "some" people ;P
Too bad...
Nicolas
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-30 17:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Mike Hommey, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.2.00.0810301105350.13034@xanadu.home>
On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:
> > Seconded.
> >
> > Having git-checkout $foo being a shorthand for git checkout -b $foo
> > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
>
> No. This is only the first step towards insanity.
>
> In many cases origin/$foo == origin/master so this can't work in that
> case which is, after all, the common case.
I don't understand that argument at all, can you explain further?
> Therefore I think this is
> wrong to add magic operations which are not useful for the common case
> and actively _hide_ how git actually works. Not only will you have to
> explain how git works anyway for that common origin/master case, but
> you'll also have to explain why sometimes the magic works and sometimes
> not. Please keep such convenience shortcuts for your own scripts and/or
> aliases.
It's not about magic, it's about sensible defaults. Currently this use
case is an error, and the resultant command is very long to type, and
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
For the user who doesn't know to use the ksh-style {} blocks this is
voodoo. The longer form is cumbersome.
For the case where the thing you type is a resolvable reference, it
would just check it out, as now.
Sam.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-30 17:44 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Theodore Tso, git, Sam Vilain
In-Reply-To: <20081030164357.GJ24098@artemis.corp>
On Thu, 2008-10-30 at 17:43 +0100, Pierre Habouzit wrote:
> In fact I believe that what we lack is a shorthand for:
>
> $sha1^..$sha1 because that would solve both of your issues, and it's
> something that has bothered me in the past too for other commands.
There is already a shorthand for that;
$sha1^!
Indeed passing that to git-format-patch has the intended effect; it
causes it to save a patch for just the commit in question.
I agree that it would make more sense for the current behaviour to be
changed;
git format-patch origin/master..
Isn't that much more to type than:
git format-patch origin/master
And it makes the case where you just want to format a single patch work
better.
However, I worry about the backwards incompatibility. The other changes
I listed didn't really violate existing expectations.
That being said, the case where a single commit reference is passed,
with no range, should be relatively easy to detect. In this situation
it could return an error, and encourage the user to use "--since" or
"--only"; or to configure one of those to be the default.
I'm wondering whether it's worth building some kind of mechanism to
notice that settings like this have not been set, and to print a warning
like "warning: you are using a git that introduced minor command
changes; use 'git config --new' to pick your defaults" - that way,
changes to command operation could be introduced that would not annoy
older users so much.
Sam.
^ permalink raw reply
* [JGIT PATCH 0/3] Improved object validation
From: Shawn O. Pearce @ 2008-10-30 17:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This is mostly a resend as I haven't heard anything on the series.
One new patch at the end, to handle '.' and '..' cases.
Shawn O. Pearce (3):
Check object connectivity during fetch if fsck is enabled
Add --[no-]thin and --[no-]fsck optiosn to fetch command line tool
Don't permit '.' or '..' in tree entries
.../src/org/spearce/jgit/pgm/Fetch.java | 20 +++++++++++++
.../org/spearce/jgit/lib/ObjectCheckerTest.java | 31 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/ObjectChecker.java | 7 ++++
.../jgit/transport/BasePackFetchConnection.java | 4 ++
.../spearce/jgit/transport/FetchConnection.java | 22 ++++++++++++++
.../org/spearce/jgit/transport/FetchProcess.java | 13 +++++++-
.../spearce/jgit/transport/TransportBundle.java | 4 ++
.../jgit/transport/WalkFetchConnection.java | 4 ++
8 files changed, 103 insertions(+), 2 deletions(-)
^ permalink raw reply
* [JGIT PATCH 1/3] Check object connectivity during fetch if fsck is enabled
From: Shawn O. Pearce @ 2008-10-30 17:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1225388785-26818-1-git-send-email-spearce@spearce.org>
If we are fetching over a pack oriented connection and we are doing
object-level fsck validation we need to also verify the graph is
fully connected after the fetch is complete. This additional check
is necessary to ensure the peer didn't omit objects that we don't
have, but which are listed as needing to be present.
On the walk style fetch connection we can bypass this check, as the
connectivity was implicitly verified by the walker as it downloaded
objects and built its queue of things to fetch. Native pack and
bundle transports however do not have this check built into them,
and require that we execute the work ourselves.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../jgit/transport/BasePackFetchConnection.java | 4 +++
.../spearce/jgit/transport/FetchConnection.java | 22 ++++++++++++++++++++
.../org/spearce/jgit/transport/FetchProcess.java | 13 ++++++++++-
.../spearce/jgit/transport/TransportBundle.java | 4 +++
.../jgit/transport/WalkFetchConnection.java | 4 +++
5 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
index a542eb7..542a8a9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
@@ -146,6 +146,10 @@ public boolean didFetchIncludeTags() {
return false;
}
+ public boolean didFetchTestConnectivity() {
+ return false;
+ }
+
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
try {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
index 9d25b0d..d93972d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
@@ -111,4 +111,26 @@ public void fetch(final ProgressMonitor monitor, final Collection<Ref> want)
* false if tags were not implicitly obtained.
*/
public boolean didFetchIncludeTags();
+
+ /**
+ * Did the last {@link #fetch(ProgressMonitor, Collection)} validate graph?
+ * <p>
+ * Some transports walk the object graph on the client side, with the client
+ * looking for what objects it is missing and requesting them individually
+ * from the remote peer. By virtue of completing the fetch call the client
+ * implicitly tested the object connectivity, as every object in the graph
+ * was either already local or was requested successfully from the peer. In
+ * such transports this method returns true.
+ * <p>
+ * Some transports assume the remote peer knows the Git object graph and is
+ * able to supply a fully connected graph to the client (although it may
+ * only be transferring the parts the client does not yet have). Its faster
+ * to assume such remote peers are well behaved and send the correct
+ * response to the client. In such tranports this method returns false.
+ *
+ * @return true if the last fetch had to perform a connectivity check on the
+ * client side in order to succeed; false if the last fetch assumed
+ * the remote peer supplied a complete graph.
+ */
+ public boolean didFetchTestConnectivity();
}
\ No newline at end of file
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
index 654572d..bb2d051 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
@@ -118,7 +118,7 @@ else if (tagopt == TagOpt.FETCH_TAGS)
final boolean includedTags;
if (!askFor.isEmpty() && !askForIsComplete()) {
- conn.fetch(monitor, askFor.values());
+ fetchObjects(monitor);
includedTags = conn.didFetchIncludeTags();
// Connection was used for object transfer. If we
@@ -143,7 +143,7 @@ else if (tagopt == TagOpt.FETCH_TAGS)
if (!askFor.isEmpty() && (!includedTags || !askForIsComplete())) {
reopenConnection();
if (!askFor.isEmpty())
- conn.fetch(monitor, askFor.values());
+ fetchObjects(monitor);
}
}
} finally {
@@ -171,6 +171,15 @@ else if (tagopt == TagOpt.FETCH_TAGS)
}
}
+ private void fetchObjects(final ProgressMonitor monitor)
+ throws TransportException {
+ conn.fetch(monitor, askFor.values());
+ if (transport.isCheckFetchedObjects()
+ && !conn.didFetchTestConnectivity() && !askForIsComplete())
+ throw new TransportException(transport.getURI(),
+ "peer did not supply a complete object graph");
+ }
+
private void closeConnection() {
if (conn != null) {
conn.close();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
index 5b321a0..7d38b02 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
@@ -165,6 +165,10 @@ private String readLine(final byte[] hdrbuf) throws IOException {
return RawParseUtils.decode(Constants.CHARSET, hdrbuf, 0, lf);
}
+ public boolean didFetchTestConnectivity() {
+ return false;
+ }
+
@Override
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
index 5638454..d089f7b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
@@ -189,6 +189,10 @@ WalkFetchConnection(final WalkTransport wt, final WalkRemoteObjectDatabase w) {
workQueue = new LinkedList<ObjectId>();
}
+ public boolean didFetchTestConnectivity() {
+ return true;
+ }
+
@Override
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
--
1.6.0.3.756.gb776d
^ permalink raw reply related
* [JGIT PATCH 2/3] Add --[no-]thin and --[no-]fsck optiosn to fetch command line tool
From: Shawn O. Pearce @ 2008-10-30 17:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1225388785-26818-2-git-send-email-spearce@spearce.org>
This way users can force verification on the fly, such as when
fetching from an untrusted URL pasted on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/pgm/Fetch.java | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
index e14e213..ad7e08f 100644
--- a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
+++ b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
@@ -54,6 +54,22 @@
@Option(name = "--verbose", aliases = { "-v" }, usage = "be more verbose")
private boolean verbose;
+ @Option(name = "--fsck", usage = "perform fsck style checks on receive")
+ private Boolean fsck;
+
+ @Option(name = "--no-fsck")
+ void nofsck(final boolean ignored) {
+ fsck = Boolean.FALSE;
+ }
+
+ @Option(name = "--thin", usage = "fetch thin pack")
+ private Boolean thin;
+
+ @Option(name = "--no-thin")
+ void nothin(final boolean ignored) {
+ thin = Boolean.FALSE;
+ }
+
@Argument(index = 0, metaVar = "uri-ish")
private String remote = "origin";
@@ -63,6 +79,10 @@
@Override
protected void run() throws Exception {
final Transport tn = Transport.open(db, remote);
+ if (fsck != null)
+ tn.setCheckFetchedObjects(fsck.booleanValue());
+ if (thin != null)
+ tn.setFetchThin(thin.booleanValue());
final FetchResult r;
try {
r = tn.fetch(new TextProgressMonitor(), toget);
--
1.6.0.3.756.gb776d
^ permalink raw reply related
* [JGIT PATCH 3/3] Don't permit '.' or '..' in tree entries
From: Shawn O. Pearce @ 2008-10-30 17:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1225388785-26818-3-git-send-email-spearce@spearce.org>
A Git tree must not have '.' or '..' within the structure as these
names are reserved in every directory by the client operating system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/lib/ObjectCheckerTest.java | 31 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/ObjectChecker.java | 7 ++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java
index fa37fb5..7befde8 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java
@@ -980,6 +980,13 @@ public void testValidTree5() throws CorruptObjectException {
checker.checkTree(data);
}
+ public void testValidTree6() throws CorruptObjectException {
+ final StringBuilder b = new StringBuilder();
+ entry(b, "100644 .a");
+ final byte[] data = Constants.encodeASCII(b.toString());
+ checker.checkTree(data);
+ }
+
public void testValidTreeSorting1() throws CorruptObjectException {
final StringBuilder b = new StringBuilder();
entry(b, "100644 fooaaa");
@@ -1166,6 +1173,30 @@ public void testInvalidTreeNameIsEmpty() {
}
}
+ public void testInvalidTreeNameIsDot() {
+ final StringBuilder b = new StringBuilder();
+ entry(b, "100644 .");
+ final byte[] data = Constants.encodeASCII(b.toString());
+ try {
+ checker.checkTree(data);
+ fail("incorrectly accepted an invalid tree");
+ } catch (CorruptObjectException e) {
+ assertEquals("invalid name '.'", e.getMessage());
+ }
+ }
+
+ public void testInvalidTreeNameIsDotDot() {
+ final StringBuilder b = new StringBuilder();
+ entry(b, "100644 ..");
+ final byte[] data = Constants.encodeASCII(b.toString());
+ try {
+ checker.checkTree(data);
+ fail("incorrectly accepted an invalid tree");
+ } catch (CorruptObjectException e) {
+ assertEquals("invalid name '..'", e.getMessage());
+ }
+ }
+
public void testInvalidTreeTruncatedInName() {
final StringBuilder b = new StringBuilder();
b.append("100644 b");
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java
index d403119..b303d6f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java
@@ -318,6 +318,13 @@ public void checkTree(final byte[] raw) throws CorruptObjectException {
}
if (thisNameB + 1 == ptr)
throw new CorruptObjectException("zero length name");
+ if (raw[thisNameB] == '.') {
+ final int nameLen = (ptr - 1) - thisNameB;
+ if (nameLen == 1)
+ throw new CorruptObjectException("invalid name '.'");
+ if (nameLen == 2 && raw[thisNameB + 1] == '.')
+ throw new CorruptObjectException("invalid name '..'");
+ }
if (duplicateName(raw, thisNameB, ptr - 1))
throw new CorruptObjectException("duplicate entry names");
--
1.6.0.3.756.gb776d
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-30 17:51 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
On Thu, 2008-10-30 at 10:39 -0400, Theodore Tso wrote:
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
>
> Rationale: Many other SCM's have a way of undoing local edits to a
> file very simply, i.e."hg revert <file>" or "svn revert <file>", and
> for many developers's workflow, it's useful to be able to undo local
> edits to a single file, but not to everything else in the working
> directory. And "git checkout HEAD -- <file>" is rather cumbersome
> to type, and many beginning users don't find it intuitive to look in
> the "git-checkout" man page for instructions on how to revert a
> local file.
Well, I don't have strong feelings on the exact command name used; I
suggested "undo", probably also ambiguous. But still, a significant
number of users are surprised when they type 'git revert' and they get a
backed out patch. It's such an uncommon operation, it doesn't deserve
to be triggered so easily. And reverting files to the state in the
index and/or HEAD is a common operation that deserves being short to
type.
Making it plain "revert" would violate expectations of existing users;
it seems a better idea to just deprecate it, and point the users to the
new method - cherry-pick --revert - or the command they might have meant
- whatever that becomes.
Sam.
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Sam Vilain @ 2008-10-30 17:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Samuel Tardieu, Bill Lear, git
In-Reply-To: <4909CABD.1040708@op5.se>
On Thu, 2008-10-30 at 15:54 +0100, Andreas Ericsson wrote:
> > I am curious of what other people workflows are. Do you often push
> > multiple branches at the same time?
>
> Quite often, yes.
>
> > More often than one at a time?
>
> No.
>
> > Many times a day?
> >
>
> Define "many". Perhaps as often as 2-3 times per day. Not very often,
> but frequent enough that I definitely want some short sweet way of
> doing it.
I think your use case is the unusual one, not the common one. Most
users will want the moral equivalent of "push = HEAD" by default, and
those who prefer the existing behaviour can configure it.
Sam.
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Sam Vilain @ 2008-10-30 18:00 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Pierre Habouzit, Andreas Ericsson, Bill Lear, git
In-Reply-To: <2008-10-30-15-56-34+trackit+sam@rfc1149.net>
On Thu, 2008-10-30 at 15:56 +0100, Samuel Tardieu wrote:
> * Pierre Habouzit <madcoder@debian.org> [2008-10-30 15:41:07 +0100]
>
> | On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
> | > I think it would be better to have :
> | >
> | > git push <= push the current branch
> | > git push --all <= push all matching refs
> | > git push --all --create <= push all matching refs, create if needed
> | >
> | > The latest command is probably used so rarely (compared to the others)
> | > that it wouldn't be a problem to make it longer. Of course, if a
> | > refspec is given explicitely, it should be honored and remote refs
> | > created if needed.
> |
> | Fwiw I'm in favor of that, and it was what I advocated at the time.
> |
> | Though I think than as soon as you add an explicit remote name, like:
> | git push origin, pushing all matched references makes sense. Which is
> | also what I advocated at the time.
>
> Indeed, it makes sense. We could then have:
>
> git push <= push the current branch on default remote
> (which is, at least in my case, the most
> frequent use I want to make of "git push",
> on all the projects [work or volunteer]
> I work on)
> git push remote <= push all matching refs on named remote
I think that 'git push origin' should be the same as 'git push'; so,
'git push remote' would then just push the current head to the tracking
branch of that remote. This exposes another issue with the current
method of configuring the tracking branch, which is that only one remote
and branch may be configured for each local branch. In reality, someone
might be pushing and pulling from multiple remotes; expecting them to
keep naming the current branch all the time seems arduous.
I think if you want matching refs to be pushed, say so:
git push remote --matching
> git push --all [remote] <= push and create all refs on remote (or default)
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-30 18:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Matthieu Moy, Theodore Tso, git
In-Reply-To: <alpine.LFD.2.00.0810301316220.13034@xanadu.home>
On Thu, 2008-10-30 at 13:17 -0400, Nicolas Pitre wrote:
> > errrrm, git reset <file> resets the index notion of the file to its status
> > in HEAD... which I'm sure is *somehow* useful to "some" people ;P
>
> Too bad...
The changes need to not unnecessarily break scripts or let down people's
expectations. I'd be happy to deprecate the use of reset with file
arguments, to keep 'reset' focused on resetting the current HEAD and not
concerned with files; but changing its behaviour on a subtle level like
this is sure to annoy...
Sam.
^ permalink raw reply
* Re: [PATCH] Documented --no-checkout option in git-svn
From: Deskin Miller @ 2008-10-30 18:07 UTC (permalink / raw)
To: _vi; +Cc: git, gitster, Vitaly _Vi Shukela
In-Reply-To: <1225382900-22482-1-git-send-email-_vi@list.ru>
On Thu, Oct 30, 2008 at 06:08:20PM +0200, _vi@list.ru wrote:
> From: Vitaly "_Vi" Shukela <public_vi@tut.by>
>
> Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
> ---
> Documentation/git-svn.txt | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 84c8f3c..90784a5 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -91,6 +91,9 @@ COMMANDS
> tracking. The name of the [svn-remote "..."] section in the
> .git/config file may be specified as an optional command-line
> argument.
> +
> +--no-checkout
> + Do not checkout latest revision after fetching.
This isn't quite how the other options are listed in the source; for one, this
ends up formatted in the final manpage like
--no-checkout Do not checkout latest revision after fetching.
Instead of
--no-checkout
Do not checkout latest revision after fetching.
Also, the wording seems slightly imprecise; in fact, if the repository already
has a checkout, git svn fetch would not attempt to check anything out in its
place, nor will it check anything out if there is a local master branch
already. With clone this is not typically a problem, but in fact it is
possible to clone into a preexisting git repository, so the same concerns
exist.
Deskin Miller
^ permalink raw reply
* [PATCH] Introduce receive.denyDeletes
From: Jan Krüger @ 2008-10-30 18:11 UTC (permalink / raw)
To: git; +Cc: gitster
Occasionally, it may be useful to prevent branches from getting deleted from
a centralized repository, particularly when no administrative access to the
server is available to undo it via reflog. It also makes
receive.denyNonFastForwards more useful if it is used for access control, since
it prevents force-updating refs by deleting and re-creating a ref.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Fairly low invasiveness. Includes documentation and test case. I have run all
parts of the test suite that use receive-pack, send-pack and friends.
Documentation/config.txt | 4 ++++
builtin-receive-pack.c | 12 ++++++++++++
t/t5400-send-pack.sh | 11 +++++++++++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 29369d0..965ed74 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1188,6 +1188,10 @@ receive.unpackLimit::
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
+receive.denyDeletes::
+ If set to true, git-receive-pack will deny a ref update that deletes
+ the ref. Use this to prevent such a ref deletion via a push.
+
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index 9f60f31..2c0225c 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -11,6 +11,7 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
+static int deny_deletes = 0;
static int deny_non_fast_forwards = 0;
static int receive_fsck_objects;
static int receive_unpack_limit = -1;
@@ -23,6 +24,11 @@ static int capabilities_sent;
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ if (strcmp(var, "receive.denydeletes") == 0) {
+ deny_deletes = git_config_bool(var, value);
+ return 0;
+ }
+
if (strcmp(var, "receive.denynonfastforwards") == 0) {
deny_non_fast_forwards = git_config_bool(var, value);
return 0;
@@ -185,6 +191,12 @@ static const char *update(struct command *cmd)
"but I can't find it!", sha1_to_hex(new_sha1));
return "bad pack";
}
+ if (deny_deletes && is_null_sha1(new_sha1) &&
+ !is_null_sha1(old_sha1) &&
+ !prefixcmp(name, "refs/heads/")) {
+ error("denying ref deletion for %s", name);
+ return "deletion prohibited";
+ }
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
!is_null_sha1(old_sha1) &&
!prefixcmp(name, "refs/heads/")) {
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 544771d..6db9e18 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -104,6 +104,17 @@ HOME=`pwd`/no-such-directory
export HOME ;# this way we force the victim/.git/config to be used.
test_expect_success \
+ 'pushing a delete should be denied with denyDeletes' '
+ cd victim &&
+ git config receive.denyDeletes true &&
+ git branch extra master &&
+ cd .. &&
+ test -f victim/.git/refs/heads/extra &&
+ git send-pack ./victim/.git/ :extra master && return 1
+ rm -f victim/.git/refs/heads/extra
+'
+
+test_expect_success \
'pushing with --force should be denied with denyNonFastforwards' '
cd victim &&
git config receive.denyNonFastforwards true &&
--
1.6.0.3.523.g304d0.dirty
^ permalink raw reply related
* Re: [PATCH] Documented --no-checkout option in git-svn
From: Sam Vilain @ 2008-10-30 18:20 UTC (permalink / raw)
To: git, Deskin Miller
Cc: Sam Vilain,
_vi@list.ru, git@vger.kernel.org, gitster@pobox.com, Vitaly _Vi Shukela,
Vitaly "_Vi" Shukela
In-Reply-To: <20081030180736.GA20322@euler>
On Thu, 2008-10-30 at 14:07 -0400, Deskin Miller wrote:
> > +--no-checkout
> > + Do not checkout latest revision after fetching.
>
> This isn't quite how the other options are listed in the source; for one, this
> ends up formatted in the final manpage like
>
> --no-checkout Do not checkout latest revision after fetching.
>
> Instead of
>
> --no-checkout
> Do not checkout latest revision after fetching.
>
> Also, the wording seems slightly imprecise; in fact, if the repository already
> has a checkout, git svn fetch would not attempt to check anything out in its
> place, nor will it check anything out if there is a local master branch
> already. With clone this is not typically a problem, but in fact it is
> possible to clone into a preexisting git repository, so the same concerns
> exist.
I think the wording is close enough; here's a version which looks good
to me and fixes the asciidoc differences.
Subject: git-svn: document --no-checkout option
From: Vitaly "_Vi" Shukela <public_vi@tut.by>
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
Signed-off-by: Sam Vilain <sam@vilain.net>
---
Documentation/git-svn.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 84c8f3c..2298512 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
tracking. The name of the [svn-remote "..."] section in the
.git/config file may be specified as an optional command-line
argument.
+
+--no-checkout;;
+ Do not checkout the latest revision after fetching.
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
@@ -103,6 +106,9 @@ COMMANDS
the working tree; and the 'rebase' command will be able
to update the working tree with the latest changes.
+--no-checkout;;
+ Do not checkout the latest revision after cloning.
+
'rebase'::
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
--
debian.1.5.6.1
^ 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