* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-03 18:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121203181519.GC14981@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
As an example to make this clearer:
$ cat .gitmodules
[submodule "sub1"]
path = sub1
url = git://example.com/sub1.git
remote = remote1
branch = branch1
update-source = submodule-upstream
update = rebase
[submodule "sub2"]
...
Means that `git submodule update sub1` will fetch remote1 and rebase
the current sub1 checkout against the tip of remote1/branch1. The
git://example.com/sub1.git URL is not actually used during this
update. Presumably the user setup remote1 intentionally in the
submodule, and wants to use the URL they've configured there.
Perhaps I need to ammend my
submodule update: add submodule.<name>.remote config option
patch (#4) to adjust the remote that has it's URL changed by `sync`?
I may also want to append some form of the following commit (from my
submodule.<name>.active proposal):
submodule add: configure existing submodule url if not set [1]
Cheers,
Trevor
[1]: https://github.com/wking/git/commit/b045c16cffe6eb86c157a6c7397166a46e147442
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Jeff King @ 2012-12-03 18:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vr4n7rrgb.fsf@alter.siamese.dyndns.org>
On Mon, Dec 03, 2012 at 09:11:32AM -0800, Junio C Hamano wrote:
> > On top of mm/status-push-pull-advise.
> >
> > I left "git checkout" alone, though I'd also like to turn it off there,
> > too. Should it get a separate advice option there? Should it simply
> > respect statusHints (it seems odd because I know that "status" there
> > means "git status", not "hints about the status of your repo")?
>
> I agree that we should have a toggle to turn it off and I think it
> is OK to reuse the same "hints about the status" option for this
> purpose. It is not like there is a released version that already
> gives the advice (possibly with some other option to turn it off)
> and you are changing the behaviour of "checkout" by suddenly making
> it honor statusHints advice.
>
> So let's do a lot simpler patch instead.
>
> -- >8 --
Perfect, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-03 18:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7v8v9ft761.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 5148 bytes --]
On Mon, Dec 03, 2012 at 08:46:46AM -0800, Junio C Hamano wrote:
> As you hinted in the first paragraph, you could flip between merge,
> rebase, and detach with a command line option when running the
> "update" subcommand, but I would imagine that the expected use
> pattern is that for a particular project, you would choose one mode
> and consistently stick to that mode. To make it easier, the user
> can set submodule.$name.update once and run "update" without having
> to give any flags.
Sure.
> And this is about adding another mode to the "update" subcommand
> where the HEAD is not detached, nor merged, nor rebased, but is set
> to follow whatever commit a remote branch points at.
This is about adding another suite of modes. Currently you can
rebase/merge/checkout the superproject-recorded $sha1. I'm adding the
ability to rebase/merge/checkout a submodule-upstream branch. I
discuss this explicitly in Documentation/git-submodule.txt when
describing --remote.
> Shouldn't the patch add a way for the user to set a configuration
> variable to signal that this new mode is always used when "update"
> is run without a command line flag?
How about a new submodule.<name>.update-source with (which can be
either superproject-gitlink or submodule-upstream)? Or to be a bit
simpler and less explicit, a submodule.<name>.update-remote boolean?
For lack of a better name, I'll call this submodule.<name>.<something>
below.
> As the user has to configure submodule.$name.branch in order to use
> this mode anyway, I have a feeling that taking that as a signal, and
> ignoring submodule.$name.update altogether, might be a simpler
> interface from the end user's point of view. That is,
As I mention earlier, submodule.<name>.update is still important. I
think it's good to add a new submodule.<name>.<something> config and a
--no-remote option (to override a configured
submodule.<name>.<something>). This way a user that generally updates
via the superproject's gitlink can still configure a branch to update
from when they use --remote.
> (1) if you are not interested in the submodule $name, you do not
> "init" it; you "init" it for all of the following.
>
> (2) if you want to have the tree state as recorded in the
> superproject, you do "update" without any option to make the
> HEAD of the submodule detached at the commit the superproject's
> tree records;
>
> (3) if you want to follow the upstream project of the submodule,
> you set submodule.$name.branch to the branch you want to
> follow, and you do "update"---submodule.$name.update is ignored
> and you will make the HEAD of the submodule detached at the tip
> of the branch at the remote (using remote-tracking branch);
>
> (4) if you want to --merge or --rebase, you give them from the
> command line, or use submodule.$name.update.
But what if your whant to merge the upstream project into a currently
checked out submodule branch? Or rebase a currently detached head
against the upstream branch?
> I may be oversimplifying a bit, but a separate
> submodule.$name.remote feels very wrong;
I use submodule.<name>.remote in patch 4 to specify the name of the
superproject's remote (for when get_default_remote doesn't give the
value you want), but I think you're referring to the potential
submodule.<name>.<something> and the presense of the --remote option.
> How does this compare with the floating submodules Heiko has been
> working on?
Heiko's older hv/floating_submodules also uses submodule.<name>.branch
(with a similar interpretation). There's also a --branch option to
`update` for command-line overrides (which I don't have, perhaps I
should add them?). He reverts to the original behavior in the
presense of submodule.<name>.branch with `update --checkout`, or when
submodule.<name>.branch=HEAD.
He also fetches all remotes, while I fetch just the explicitly
configured submodule.<name>.remote falling back on
$(get_default_remote. His submodule.<name>.branch is the full local
ref for the branch (e.g. 'origin/master'), while mine is just the
remote branch (e.g. 'master'). I split the remote (e.g. 'origin')
into submodule.<name>.remote in patch 4 so you can explicitly fetch
just that remote (and not all the remotes you may have configured for
that submodule).
For reasons that I don't understand, he only supports the `checkout`
update logic for remote branches.
Heiko's newer hv/floating_submodules_draft builds on my earlier v4
--local-branch option, but he uses his own processing logic. He pulls
the existing 'update to $sha1' logic out into a new
handle_on_demand_update() and uses the stored submodule.<name>.branch
as the name of a local submodule branch to check out when tracking.
Then he pulls that local branches default upstream (configured in
.git/modules/<name>/config) with --ff-only.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Ubuntu: gitweb always looks for projects in /var/cache/git (“404 - no projects found”)
From: Alfonso Muñoz-Pomer Fuentes @ 2012-12-03 17:10 UTC (permalink / raw)
Cc: git
In-Reply-To: <20121129182826.GB17309@sigill.intra.peff.net>
Thank you very much for the clarification. Noticing how this wasn’t
documented anywhere I had the feeling that I was missing something.
On Thu 29 Nov 2012 19:28:26 CET, Jeff King wrote:
> On Thu, Nov 29, 2012 at 01:55:57PM +0000, Alfonso Muñoz-Pomer Fuentes wrote:
>
>> I’ve discovered this weird behaviour in gitweb and documented a workaround in
>> StackOverflow:
>> http://stackoverflow.com/questions/13609475/ubuntu-gitweb-always-looks-for-projects-in-var-cache-git-404-no-projects-f
>>
>> Basically, the variable $projectroot in gitweb.cgi in the beginning is reset to
>> the system default value in git_get_projects_list, when it is declared again.
>>
>> Is this a known bug? Or am I missing something?
>
> I think the analysis in that stack overflow post is wrong. The use of
> "our" in git_get_projects_list is not the culprit.
>
> The problem is that one should not edit gitweb.cgi directly; its
> built-in defaults (which you are tweaking) are overridden by
> /etc/gitweb.conf, which is shipped by the Ubuntu package. You should
> be making your changes in the config file, not the CGI script.
>
> -Peff
--
Alfonso Muñoz-Pomer Fuentes
Johann Heinrich von Thünen-Institut
Bundesforschungsinstitut für Ländliche Räume, Wald und Fischerei
Institut für Forstgenetik
Sieker Landstrasse 2
22927 Grosshansdorf
Telefon: +49 (0)4102/696-145
Fax: +49 (0)4102/696-200
Email: alfonso.munozpomer@vti.bund.de
Web: http://www.vti.bund.de
^ permalink raw reply
* Re: [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Junio C Hamano @ 2012-12-03 17:11 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20121203061656.GA20164@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If the user has unset advice.statusHints, we already
> suppress the "use git reset to..." hints in each stanza. The
> new "use git push to publish..." hint is the same type of
> hint. Let's respect statusHints for it, rather than making
> the user set yet another advice flag.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On top of mm/status-push-pull-advise.
>
> I left "git checkout" alone, though I'd also like to turn it off there,
> too. Should it get a separate advice option there? Should it simply
> respect statusHints (it seems odd because I know that "status" there
> means "git status", not "hints about the status of your repo")?
I agree that we should have a toggle to turn it off and I think it
is OK to reuse the same "hints about the status" option for this
purpose. It is not like there is a released version that already
gives the advice (possibly with some other option to turn it off)
and you are changing the behaviour of "checkout" by suddenly making
it honor statusHints advice.
So let's do a lot simpler patch instead.
-- >8 --
From: Jeff King <peff@peff.net>
Date: Mon, 3 Dec 2012 01:16:57 -0500
If the user has unset advice.statusHints, we already
suppress the "use git reset to..." hints in each stanza. The
new "use git push to publish..." hint is the same type of
hint. Let's respect statusHints for it, rather than making
the user set yet another advice flag.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
remote.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/remote.c b/remote.c
index 9c19689..18dc8ec 100644
--- a/remote.c
+++ b/remote.c
@@ -1633,8 +1633,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"Your branch is ahead of '%s' by %d commits.\n",
num_ours),
base, num_ours);
- strbuf_addf(sb,
- _(" (use \"git push\" to publish your local commits)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git push\" to publish your local commits)\n"));
} else if (!num_ours) {
strbuf_addf(sb,
Q_("Your branch is behind '%s' by %d commit, "
@@ -1643,8 +1644,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"and can be fast-forwarded.\n",
num_theirs),
base, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to update your local branch)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to update your local branch)\n"));
} else {
strbuf_addf(sb,
Q_("Your branch and '%s' have diverged,\n"
@@ -1655,8 +1657,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"respectively.\n",
num_theirs),
base, num_ours, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to merge the remote branch into yours)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to merge the remote branch into yours)\n"));
}
return 1;
}
--
1.8.0.1.420.g52a5207
^ permalink raw reply related
* Re: [RFC] Add basic syntax check on shell scripts
From: Junio C Hamano @ 2012-12-03 16:56 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201212021417.25525.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> The test suite needs to be run on different platforms.
> As it may be difficult for contributors to catch syntax
> which work on GNU/linux, but is unportable, make a quick check
> for the most common problems.
> "sed -i", "echo -n" or "array in shell scripts"
> This list is not complete, and may need to be extended
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> We add 1 second test execution time
> Is this a useful idea at all?
Please do not name it after t/t[0-9]*.sh pattern, which are about
testing git.
This (once it gets cleaned up to reduce false positives) belongs to
"cd t && make test-lint".
>
> t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100755 t/t99999-syntax-check.sh
>
> diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
> new file mode 100755
> index 0000000..c4a9289
> --- /dev/null
> +++ b/t/t99999-syntax-check.sh
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +
> +test_description='Basic check if shell syntax is portable'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'No arrays in shell scripts' '
> + >expected &&
> + (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +
> +test_expect_success 'No sed -i' '
> + >expected &&
> + (grep -n "^[ ]*sed[ ][ ]*\-i" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +
> +test_expect_success 'No echo -n' '
> + >expected &&
> + (grep -n "^[ ]*echo[ ][ ]*\-n" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +test_done
^ permalink raw reply
* Re: [PATCH] t9402: sed -i is not portable
From: Junio C Hamano @ 2012-12-03 16:53 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, mmogilvi_git
In-Reply-To: <201212021322.45418.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> On some systems sed allows the usage of e.g.
> sed -i -e "s/line1/line2/" afile
> to edit the file "in place".
> Other systems don't allow that: one observed behaviour is that
> sed -i -e "s/line1/line2/" afile
> creates a backup file called afile-e, which breaks the test.
> As sed -i is not part of POSIX, avoid it.
>
> Use test_cmp, makes the test easier to debug.
> Chain all shell commands with && to detect all kinds of failure.
> While at it, Use TAB to indent.
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> Note: this should go on top of pu
>
> t/t9402-git-cvsserver-refs.sh | 764 +++++++++++++++++++++---------------------
> 1 file changed, 383 insertions(+), 381 deletions(-)
>
> diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
> index 858ef0f..39c6b01 100755
> --- a/t/t9402-git-cvsserver-refs.sh
> +++ b/t/t9402-git-cvsserver-refs.sh
> @@ -10,59 +10,58 @@ tags, branches and other git refspecs'
> #########
>
> check_start_tree() {
> - rm -f "$WORKDIR/check.list"
> - echo "start $1" >> "${WORKDIR}/check.log"
> + rm -f "$WORKDIR/check.list"
> + echo "start $1" >> "${WORKDIR}/check.log"
I think the indentation is broken throughout the patch. Why two
tabs at the beginning?
Please do not do many unrelated things at once in a commit, as it
makes the changes unnecessarily noisy for reviewing. When a
reviewer wants to concentrate on formatting, changes to other text
become distracting. When a reviewer wants to concentrate on the
logic of replacing "sed -i" with a temporary file, formatting
changes become distracting.
If you want to fix "sed -i", do that and only that in one patch. If
you want to fix indentation and other style fixes (which is a good
thing to do), do that and only that in a separate patch, either
before or after the main patch.
Thanks.
> }
>
> check_file() {
> - sandbox="$1"
> - file="$2"
> - ver="$3"
> - GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> + sandbox="$1"
> + file="$2"
> + ver="$3"
> + GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> > "$WORKDIR/check.got" 2> "$WORKDIR/check.stderr"
> - test_cmp "$WORKDIR/check.got" "$sandbox/$file"
> - stat=$?
> - echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
> - echo "$file" >> "$WORKDIR/check.list"
> - return $stat
> + test_cmp "$WORKDIR/check.got" "$sandbox/$file"
> + stat=$?
> + echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
> + echo "$file" >> "$WORKDIR/check.list"
> + return $stat
> }
>
> check_end_tree() {
> - sandbox="$1"
> - expectCount=$(wc -l < "$WORKDIR/check.list")
> - cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
> - test x"$cvsCount" = x"$expectCount"
> - stat=$?
> - echo "check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount" \
> - >> "$WORKDIR/check.log"
> - return $stat
> + sandbox="$1" &&
> + wc -l < "$WORKDIR/check.list" > expected &&
> + find "$sandbox" -type f | grep -v "/CVS" > "$WORKDIR/check.cvsCount" &&
> + wc -l < "$WORKDIR/check.cvsCount" >actual &&
> + test_cmp expected actual &&
> + rm expected actual &&
> + sort < "$WORKDIR/check.list" > expected &&
> + sort < "$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
> + test_cmp expected actual &&
> + rm expected actual
> }
>
> check_end_full_tree() {
> - sandbox="$1"
> - ver="$2"
> - expectCount=$(wc -l < "$WORKDIR/check.list")
> - cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
> - gitCount=$(git ls-tree -r "$2" | wc -l)
> - test x"$cvsCount" = x"$expectCount" -a x"$gitCount" = x"$expectCount"
> - stat=$?
> - echo "check_end $sandbox : $stat cvs=$cvsCount git=$gitCount expect=$expectCount" \
> - >> "$WORKDIR/check.log"
> - return $stat
> + sandbox="$1" &&
> + sort < "$WORKDIR/check.list" >expected &&
> + find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
> + test_cmp expected act1 &&
> + git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort > act2 &&
> + test_cmp expected act2 &&
> + rm expected act1 act2
> }
>
> #########
>
> check_diff() {
> - diffFile="$1"
> - vOld="$2"
> - vNew="$3"
> - rm -rf diffSandbox
> - git clone -q -n . diffSandbox &&
> - ( cd diffSandbox &&
> - git checkout "$vOld" &&
> - git apply -p0 --index <"../$diffFile" &&
> - git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
> + diffFile="$1"
> + vOld="$2"
> + vNew="$3"
> + rm -rf diffSandbox
> + git clone -q -n . diffSandbox &&
> + ( cd diffSandbox &&
> + git checkout "$vOld" &&
> + git apply -p0 --index <"../$diffFile" &&
> + git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
> }
>
> #########
> @@ -70,17 +69,17 @@ check_diff() {
> cvs >/dev/null 2>&1
> if test $? -ne 1
> then
> - skip_all='skipping git-cvsserver tests, cvs not found'
> - test_done
> + skip_all='skipping git-cvsserver tests, cvs not found'
> + test_done
> fi
> if ! test_have_prereq PERL
> then
> - skip_all='skipping git-cvsserver tests, perl not available'
> - test_done
> + skip_all='skipping git-cvsserver tests, perl not available'
> + test_done
> fi
> "$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> - skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
> - test_done
> + skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
> + test_done
> }
>
> unset GIT_DIR GIT_CONFIG
> @@ -94,465 +93,468 @@ export CVSROOT CVS_SERVER
>
> rm -rf "$CVSWORK" "$SERVERDIR"
> test_expect_success 'setup v1, b1' '
> - echo "Simple text file" > textfile.c &&
> - echo "t2" > t2 &&
> - mkdir adir &&
> - echo "adir/afile line1" > adir/afile &&
> - echo "adir/afile line2" >> adir/afile &&
> - echo "adir/afile line3" >> adir/afile &&
> - echo "adir/afile line4" >> adir/afile &&
> - echo "adir/a2file" >> adir/a2file &&
> - mkdir adir/bdir &&
> - echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
> - echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
> - echo "adir/bdir/b2file" > adir/bdir/b2file &&
> - git add textfile.c t2 adir &&
> - git commit -q -m "First Commit (v1)" &&
> - git tag v1 &&
> - git branch b1 &&
> - git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
> - GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
> - GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
> + echo "Simple text file" > textfile.c &&
> + echo "t2" > t2 &&
> + mkdir adir &&
> + echo "adir/afile line1" > adir/afile &&
> + echo "adir/afile line2" >> adir/afile &&
> + echo "adir/afile line3" >> adir/afile &&
> + echo "adir/afile line4" >> adir/afile &&
> + echo "adir/a2file" >> adir/a2file &&
> + mkdir adir/bdir &&
> + echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
> + echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
> + echo "adir/bdir/b2file" > adir/bdir/b2file &&
> + git add textfile.c t2 adir &&
> + git commit -q -m "First Commit (v1)" &&
> + git tag v1 &&
> + git branch b1 &&
> + git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
> + GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
> + GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
> '
>
> rm -rf cvswork
> test_expect_success 'cvs co v1' '
> - cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> rm -rf cvswork
> test_expect_success 'cvs co b1' '
> - cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs co b1 [cvswork3]' '
> - cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v1 &&
> - check_file cvswork3 t2 v1 &&
> - check_file cvswork3 adir/afile v1 &&
> - check_file cvswork3 adir/a2file v1 &&
> - check_file cvswork3 adir/bdir/bfile v1 &&
> - check_file cvswork3 adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork3 v1
> + cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v1 &&
> + check_file cvswork3 t2 v1 &&
> + check_file cvswork3 adir/afile v1 &&
> + check_file cvswork3 adir/a2file v1 &&
> + check_file cvswork3 adir/bdir/bfile v1 &&
> + check_file cvswork3 adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork3 v1
> '
>
> test_expect_success 'edit cvswork3 and save diff' '
> - ( cd cvswork3 &&
> - sed -i -e "s/line1/line1 - data/" adir/afile &&
> - echo "afile5" > adir/afile5 &&
> - rm t2 &&
> - cvs -f add adir/afile5 &&
> - cvs -f rm t2 &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
> - )
> + ( cd cvswork3 &&
> + sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
> + mv -f adir/afileNEW adir/afile &&
> + echo "afile5" > adir/afile5 &&
> + rm t2 &&
> + cvs -f add adir/afile5 &&
> + cvs -f rm t2 &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
> + )
> '
>
> test_expect_success 'setup v1.2 on b1' '
> - git checkout b1 &&
> - echo "new v1.2" > t3 &&
> - rm t2 &&
> - sed -i -e "s/line3/line3 - more data/" adir/afile &&
> - rm adir/a2file &&
> - echo "a3file" >> adir/a3file &&
> - echo "bfile line 3" >> adir/bdir/bfile &&
> - rm adir/bdir/b2file &&
> - echo "b3file" > adir/bdir/b3file &&
> - mkdir cdir &&
> - echo "cdir/cfile" > cdir/cfile &&
> - git add -A cdir adir t3 t2 &&
> - git commit -q -m 'v1.2' &&
> - git tag v1.2 &&
> - git push --tags gitcvs.git b1:b1
> + git checkout b1 &&
> + echo "new v1.2" > t3 &&
> + rm t2 &&
> + sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
> + mv -f adir/afileNEW adir/afile &&
> + rm adir/a2file &&
> + echo "a3file" >> adir/a3file &&
> + echo "bfile line 3" >> adir/bdir/bfile &&
> + rm adir/bdir/b2file &&
> + echo "b3file" > adir/bdir/b3file &&
> + mkdir cdir &&
> + echo "cdir/cfile" > cdir/cfile &&
> + git add -A cdir adir t3 t2 &&
> + git commit -q -m 'v1.2' &&
> + git tag v1.2 &&
> + git push --tags gitcvs.git b1:b1
> '
>
> test_expect_success 'cvs -f up (on b1 adir)' '
> - ( cd cvswork/adir &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork/adir &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up (on b1 /)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_tree cvswork
> '
>
> # Make sure "CVS/Tag" files didn't get messed up:
> test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_tree cvswork
> '
>
> # update to another version:
> test_expect_success 'cvs up -r v1' '
> - ( cd cvswork &&
> - cvs -f up -r v1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -r v1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up' '
> - ( cd cvswork &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up (again; check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'setup simple b2' '
> - git branch b2 v1 &&
> - git push --tags gitcvs.git b2:b2
> + git branch b2 v1 &&
> + git push --tags gitcvs.git b2:b2
> '
>
> test_expect_success 'cvs co b2 [into cvswork2]' '
> - cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'root dir edit [cvswork2]' '
> - ( cd cvswork2 &&
> - echo "Line 2" >> textfile.c &&
> - test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
> - cvs -f commit -m "edit textfile.c" textfile.c
> - ) >cvsEdit1.log 2>&1
> + ( cd cvswork2 &&
> + echo "Line 2" >> textfile.c &&
> + test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
> + cvs -f commit -m "edit textfile.c" textfile.c
> + ) >cvsEdit1.log 2>&1
> '
>
> test_expect_success 'root dir rm file [cvswork2]' '
> - ( cd cvswork2 &&
> - cvs -f rm -f t2 &&
> - cvs -f diff -u > ../cvsEdit2-empty.diff &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
> - cvs -f commit -m "rm t2"
> - ) > cvsEdit2.log 2>&1
> + ( cd cvswork2 &&
> + cvs -f rm -f t2 &&
> + cvs -f diff -u > ../cvsEdit2-empty.diff &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
> + cvs -f commit -m "rm t2"
> + ) > cvsEdit2.log 2>&1
> '
>
> test_expect_success 'subdir edit/add/rm files [cvswork2' '
> - ( cd cvswork2 &&
> - sed -i -e "s/line 1/line 1 (v2)/" adir/bdir/bfile &&
> - rm adir/bdir/b2file &&
> - cd adir &&
> - cvs -f rm bdir/b2file &&
> - echo "4th file" > bdir/b4file &&
> - cvs -f add bdir/b4file &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
> - git fetch gitcvs.git b2:b2 &&
> - ( cd .. &&
> + ( cd cvswork2 &&
> + sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
> + mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
> + rm adir/bdir/b2file &&
> + cd adir &&
> + cvs -f rm bdir/b2file &&
> + echo "4th file" > bdir/b4file &&
> + cvs -f add bdir/b4file &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
> + git fetch gitcvs.git b2:b2 &&
> + ( cd .. &&
> test_must_fail cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
> test_must_fail cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
> - ) &&
> - cvs -f commit -m "various add/rm/edit"
> - ) >cvs.log 2>&1
> + ) &&
> + cvs -f commit -m "various add/rm/edit"
> + ) >cvs.log 2>&1
> '
>
> test_expect_success 'validate result of edits [cvswork2]' '
> - git fetch gitcvs.git b2:b2 &&
> - git tag v2 b2 &&
> - git push --tags gitcvs.git b2:b2 &&
> - check_start_tree cvswork2 &&
> - check_file cvswork2 textfile.c v2 &&
> - check_file cvswork2 adir/afile v2 &&
> - check_file cvswork2 adir/a2file v2 &&
> - check_file cvswork2 adir/bdir/bfile v2 &&
> - check_file cvswork2 adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork2 v2
> + git fetch gitcvs.git b2:b2 &&
> + git tag v2 b2 &&
> + git push --tags gitcvs.git b2:b2 &&
> + check_start_tree cvswork2 &&
> + check_file cvswork2 textfile.c v2 &&
> + check_file cvswork2 adir/afile v2 &&
> + check_file cvswork2 adir/a2file v2 &&
> + check_file cvswork2 adir/bdir/bfile v2 &&
> + check_file cvswork2 adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork2 v2
> '
>
> test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
> - test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
> - test ! -s cvsEdit2-empty.diff &&
> - test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
> - test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
> - rm -rf diffSandbox &&
> - git clone -q -n . diffSandbox &&
> - ( cd diffSandbox &&
> - git checkout v1 &&
> - git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
> - git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
> - git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
> - git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
> + test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
> + test ! -s cvsEdit2-empty.diff &&
> + test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
> + test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
> + rm -rf diffSandbox &&
> + git clone -q -n . diffSandbox &&
> + ( cd diffSandbox &&
> + git checkout v1 &&
> + git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
> + git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
> + git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
> + git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
> '
>
> test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
> - test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
> - check_diff cvsEdit3-v1.2.diff v1.2 v2
> + test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
> + check_diff cvsEdit3-v1.2.diff v1.2 v2
> '
>
> test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
> - test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
> - check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
> + test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
> + check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
> '
>
> test_expect_success 'cvs up [cvswork2]' '
> - ( cd cvswork2 &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork2 &&
> - check_file cvswork2 textfile.c v2 &&
> - check_file cvswork2 adir/afile v2 &&
> - check_file cvswork2 adir/a2file v2 &&
> - check_file cvswork2 adir/bdir/bfile v2 &&
> - check_file cvswork2 adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork2 v2
> + ( cd cvswork2 &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork2 &&
> + check_file cvswork2 textfile.c v2 &&
> + check_file cvswork2 adir/afile v2 &&
> + check_file cvswork2 adir/a2file v2 &&
> + check_file cvswork2 adir/bdir/bfile v2 &&
> + check_file cvswork2 adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork2 v2
> '
>
> test_expect_success 'cvs up -r b2 [back to cvswork]' '
> - ( cd cvswork &&
> - cvs -f up -r b2 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v2 &&
> - check_file cvswork adir/afile v2 &&
> - check_file cvswork adir/a2file v2 &&
> - check_file cvswork adir/bdir/bfile v2 &&
> - check_file cvswork adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork v2
> + ( cd cvswork &&
> + cvs -f up -r b2 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v2 &&
> + check_file cvswork adir/afile v2 &&
> + check_file cvswork adir/a2file v2 &&
> + check_file cvswork adir/bdir/bfile v2 &&
> + check_file cvswork adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork v2
> '
>
> test_expect_success 'cvs up -r b1' '
> - ( cd cvswork &&
> - cvs -f up -r b1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_full_tree cvswork v1.2
> + ( cd cvswork &&
> + cvs -f up -r b1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_full_tree cvswork v1.2
> '
>
> test_expect_success 'cvs up -A' '
> - ( cd cvswork &&
> - cvs -f up -A ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + ( cd cvswork &&
> + cvs -f up -A ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> test_expect_success 'cvs up (check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + ( cd cvswork &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> # This is not really legal CVS, but it seems to work anyway:
> test_expect_success 'cvs up -r heads/b1' '
> - ( cd cvswork &&
> - cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_full_tree cvswork v1.2
> + ( cd cvswork &&
> + cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_full_tree cvswork v1.2
> '
>
> # But this should work even if CVS client checks -r more carefully:
> test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
> - ( cd cvswork &&
> - cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v2 &&
> - check_file cvswork adir/afile v2 &&
> - check_file cvswork adir/a2file v2 &&
> - check_file cvswork adir/bdir/bfile v2 &&
> - check_file cvswork adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork v2
> + ( cd cvswork &&
> + cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v2 &&
> + check_file cvswork adir/afile v2 &&
> + check_file cvswork adir/a2file v2 &&
> + check_file cvswork adir/bdir/bfile v2 &&
> + check_file cvswork adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork v2
> '
>
> v1hash=$(git rev-parse v1)
> test_expect_success 'cvs up -r $(git rev-parse v1)' '
> - test -n "$v1hash" &&
> - ( cd cvswork &&
> - cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + test -n "$v1hash" &&
> + ( cd cvswork &&
> + cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> test_expect_success 'cvs diff -r v1 -u' '
> - ( cd cvswork &&
> - cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvsDiff.out &&
> - test ! -s cvs.log
> + ( cd cvswork &&
> + cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvsDiff.out &&
> + test ! -s cvs.log
> '
>
> test_expect_success 'cvs diff -N -r v2 -u' '
> - ( cd cvswork &&
> - test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
> + ( cd cvswork &&
> + test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
> '
>
> test_expect_success 'cvs diff -N -r v2 -r v1.2' '
> - ( cd cvswork &&
> - test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
> + ( cd cvswork &&
> + test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
> '
>
> test_expect_success 'apply early [cvswork3] diff to b3' '
> - git clone -q . gitwork3 &&
> - ( cd gitwork3 &&
> - git checkout -b b3 v1 &&
> - git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
> - git commit -m "cvswork3 edits applied" ) &&
> - git fetch gitwork3 b3:b3 &&
> - git tag v3 b3
> + git clone -q . gitwork3 &&
> + ( cd gitwork3 &&
> + git checkout -b b3 v1 &&
> + git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
> + git commit -m "cvswork3 edits applied" ) &&
> + git fetch gitwork3 b3:b3 &&
> + git tag v3 b3
> '
>
> test_expect_success 'check [cvswork3] diff' '
> - ( cd cvswork3 &&
> - test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - test $(grep Index: cvsDiff.out | wc -l) = 3 &&
> - test_cmp cvsDiff.out cvswork3edit.diff &&
> - check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
> + ( cd cvswork3 &&
> + test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + test $(grep Index: cvsDiff.out | wc -l) = 3 &&
> + test_cmp cvsDiff.out cvswork3edit.diff &&
> + check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
> '
>
> test_expect_success 'merge early [cvswork3] b3 with b1' '
> - ( cd gitwork3 &&
> - git merge "message" HEAD b1 )
> - git fetch gitwork3 b3:b3 &&
> - git tag v3merged b3 &&
> - git push --tags gitcvs.git b3:b3
> + ( cd gitwork3 &&
> + git merge "message" HEAD b1 )
> + git fetch gitwork3 b3:b3 &&
> + git tag v3merged b3 &&
> + git push --tags gitcvs.git b3:b3
> '
>
> # This test would fail if cvsserver properly created a ".#afile"* file
> # for the merge.
> # TODO: Validate that the .# file was saved properly, and then
> -# delete/ignore it when checking the tree.
> +# delete/ignore it when checking the tree.
> test_expect_success 'cvs up dirty [cvswork3]' '
> - ( cd cvswork3 &&
> - cvs -f up &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
> - test -s cvsDiff.out &&
> - test $(grep Index: cvsDiff.out | wc -l) = 2
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v3merged &&
> - check_file cvswork3 t3 v3merged &&
> - check_file cvswork3 adir/afile v3merged &&
> - check_file cvswork3 adir/a3file v3merged &&
> - check_file cvswork3 adir/afile5 v3merged &&
> - check_file cvswork3 adir/bdir/bfile v3merged &&
> - check_file cvswork3 adir/bdir/b3file v3merged &&
> - check_file cvswork3 cdir/cfile v3merged &&
> - check_end_full_tree cvswork3 v3merged
> + ( cd cvswork3 &&
> + cvs -f up &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
> + test -s cvsDiff.out &&
> + test $(grep Index: cvsDiff.out | wc -l) = 2
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v3merged &&
> + check_file cvswork3 t3 v3merged &&
> + check_file cvswork3 adir/afile v3merged &&
> + check_file cvswork3 adir/a3file v3merged &&
> + check_file cvswork3 adir/afile5 v3merged &&
> + check_file cvswork3 adir/bdir/bfile v3merged &&
> + check_file cvswork3 adir/bdir/b3file v3merged &&
> + check_file cvswork3 cdir/cfile v3merged &&
> + check_end_full_tree cvswork3 v3merged
> '
>
> # TODO: test cvs status
>
> test_expect_success 'cvs commit [cvswork3' '
> - ( cd cvswork3 &&
> - cvs -f commit -m "dirty sandbox after auto-merge"
> - ) > cvs.log 2>&1 &&
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v3merged &&
> - check_file cvswork3 t3 v3merged &&
> - check_file cvswork3 adir/afile v3merged &&
> - check_file cvswork3 adir/a3file v3merged &&
> - check_file cvswork3 adir/afile5 v3merged &&
> - check_file cvswork3 adir/bdir/bfile v3merged &&
> - check_file cvswork3 adir/bdir/b3file v3merged &&
> - check_file cvswork3 cdir/cfile v3merged &&
> - check_end_full_tree cvswork3 v3merged &&
> - git fetch gitcvs.git b3:b4 &&
> - git tag v4.1 b4 &&
> - git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
> + ( cd cvswork3 &&
> + cvs -f commit -m "dirty sandbox after auto-merge"
> + ) > cvs.log 2>&1 &&
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v3merged &&
> + check_file cvswork3 t3 v3merged &&
> + check_file cvswork3 adir/afile v3merged &&
> + check_file cvswork3 adir/a3file v3merged &&
> + check_file cvswork3 adir/afile5 v3merged &&
> + check_file cvswork3 adir/bdir/bfile v3merged &&
> + check_file cvswork3 adir/bdir/b3file v3merged &&
> + check_file cvswork3 cdir/cfile v3merged &&
> + check_end_full_tree cvswork3 v3merged &&
> + git fetch gitcvs.git b3:b4 &&
> + git tag v4.1 b4 &&
> + git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
> '
>
> test_done
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-03 16:46 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <ec5d0235322619aff6c1c64b0a346efb0e4d0a32.1354417618.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> The current `update` command incorporates the superproject's gitlinked
> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
> options you use, it may checkout $sha1, rebase the $subsha1 onto
> $sha1, or merge $sha1 into $subsha1. This helps you keep up with
> changes in the upstream superproject.
>
> However, it's also useful to stay up to date with changes in the
> upstream subproject. Previous workflows for incorporating such
> changes include the ungainly:
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With this patch, all of the useful functionality for incorporating
> superproject changes can be reused to incorporate upstream subproject
> updates. When you specify --remote, the target $sha1 is replaced with
> a $sha1 of the submodule's origin/master tracking branch. If you want
> to merge a different tracking branch, you can configure the
> `submodule.<name>.branch` option in `.gitmodules`. You can override
> the `.gitmodules` configuration setting for a particular superproject
> by configuring the option in that superproject's default configuration
> (using the usual configuration hierarchy, e.g. `.git/config`,
> `~/.gitconfig`, etc.).
>
> Previous use of submodule.<name>.branch
> =======================================
>
> Because we're adding a new configuration option, it's a good idea to
> check if anyone else is already using the option. The foreach-pull
> example above was described by Ævar in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date: Fri May 21 16:10:10 2010 +0000
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses the same interpretation for the setting, but because
> Gerrit has direct access to the subproject repositories, it updates
> the superproject repositories automatically when a subproject changes.
> Gerrit also accepts the special value '.', which it expands into the
> superproject's branch name.
>
> Although the --remote functionality is using `submodule.<name>.branch`
> slightly differently, the effect is the same. The foreach-pull
> example uses the option to record the name of the local branch to
> checkout before pulls. The tracking branch to be pulled is recorded
> in `.git/modules/<name>/config`, which was initialized by the module
> clone during `submodule add` or `submodule init`. Because the branch
> name stored in `submodule.<name>.branch` was likely the same as the
> branch name used during the initial `submodule add`, the same branch
> will be pulled in each workflow.
>
> Implementation details
> ======================
>
> In order to ensure a current tracking branch state, `update --remote`
> fetches the submodule's remote repository before calculating the
> SHA-1. However, I didn't change the logic guarding the existing fetch:
>
> if test -z "$nofetch"
> then
> # Run fetch only if $sha1 isn't present or it
> # is not reachable from a ref.
> (clear_local_git_env; cd "$path" &&
> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
> die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
> fi
>
> There will not be a double-fetch, because the new $sha1 determined
> after the `--remote` triggered fetch should always exist in the
> repository. If it doesn't, it's because some racy process removed it
> from the submodule's repository and we *should* be re-fetching.
As you hinted in the first paragraph, you could flip between merge,
rebase, and detach with a command line option when running the
"update" subcommand, but I would imagine that the expected use
pattern is that for a particular project, you would choose one mode
and consistently stick to that mode. To make it easier, the user
can set submodule.$name.update once and run "update" without having
to give any flags.
And this is about adding another mode to the "update" subcommand
where the HEAD is not detached, nor merged, nor rebased, but is set
to follow whatever commit a remote branch points at.
Shouldn't the patch add a way for the user to set a configuration
variable to signal that this new mode is always used when "update"
is run without a command line flag?
As the user has to configure submodule.$name.branch in order to use
this mode anyway, I have a feeling that taking that as a signal, and
ignoring submodule.$name.update altogether, might be a simpler
interface from the end user's point of view. That is,
(1) if you are not interested in the submodule $name, you do not
"init" it; you "init" it for all of the following.
(2) if you want to have the tree state as recorded in the
superproject, you do "update" without any option to make the
HEAD of the submodule detached at the commit the superproject's
tree records;
(3) if you want to follow the upstream project of the submodule,
you set submodule.$name.branch to the branch you want to
follow, and you do "update"---submodule.$name.update is ignored
and you will make the HEAD of the submodule detached at the tip
of the branch at the remote (using remote-tracking branch);
(4) if you want to --merge or --rebase, you give them from the
command line, or use submodule.$name.update.
I may be oversimplifying a bit, but a separate
submodule.$name.remote feels very wrong; if it were a new token
"remote" that can be set as the value of submodule.$name.update (in
addition to existing "none", "rebase" and "merge"), it might be a
bit more understandable, though.
How does this compare with the floating submodules Heiko has been
working on?
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-03 15:38 UTC (permalink / raw)
To: Jens Lehmann, Phil Hord
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121201165404.GD4823@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]
On Sun, Dec 02, 2012 at 04:11:59PM -0500, W. Trevor King wrote:
> On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 18:49, schrieb W. Trevor King:
> > > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
> > >> What real world problems do we have with the current init/sync that
> > >> this approach would solve?
> > >
> > > I don't have any, ...
> >
> > We don't want to change working code and cause compatibility issues
> > just because we /could/ do things differently, no?
>
> In principle, yes, but in this case I think changing the
> implementation does not risk much in the way of compatibility issues
> (it only hurts users who rely on `submodule init` setting
> submodule.<name>.url for reasons of their own. A few of the existing
> tests explictly check the url setting, so perhaps there are a number
> of users who do require this side effect?
>
> I think this risk is outweighed by the benefits of having a clearer
> activation option.
For anyone interested in an implementation of my
submodule.<name>.active proposal, I've posted an initial version:
git://github.com/wking/git.git wtk/submodule.name.active
I can re-post it here as a PATCH series, but I don't think we're at
the level of patch-specific feedback yet.
I'm currently pretty happy with it except for the last commit:
HACK work around missing index entry for existing empty submodules
To solve that cleanly, I'd need a solution to the commit-less existing
repository problem which I mentioned earlier:
On Sat, Dec 01, 2012 at 11:54:04AM -0500, W. Trevor King wrote:
> I'm currently stuck with adding a commit-less existing repository as a
> submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c
> works with relative local path):
>
> $ mkdir -p super/sub
> $ cd super
> $ git init
> $ (cd sub && git init)
> $ git submodule add ./ sub
> $ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: .gitmodules
> #
>
> What I'm missing is a gitlink form sub for 'Subproject commit
> 00000...' or some such. When the subproject has an actual commit,
> things work as expected:
>
> $ mkdir -p super/sub
> $ cd super
> $ git init
> $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file)
> $ git submodule add ./ sub
> $ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: sub
> #
>
> This means that module_list isn't aware of the empty submodule, when
> the user has just explicitly added it. Fixing this would seem to need
> either 'Subproject commit 00000...' as I suggested earlier, or an
> adjustment to module_list that also spits out submodules that are in
> .gitmodules but not in the index.
Other than that, I think all the changes in the test suite are
logically sound and unlikely to cause problems with existing usage.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 22 new messages
From: Michael J Gruber @ 2012-12-03 15:09 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, jk, stimming, git
In-Reply-To: <1354510146-2919-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 03.12.2012 05:49:
> Translate 22 new messages came from git.pot
> updates in 9306b5b (l10n: Update git.pot (3 new,
> 6 removed messages)), fe52cd6 (l10n: Update git.pot
> (14 new, 3 removed messages)) and f9472e3
> (l10n: Update git.pot (5 new, 1 removed messages)).
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> po/de.po | 68 ++++++++++++++++++++++++++++++++++------------------------------
> 1 file changed, 36 insertions(+), 32 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index a0bf3da..7350818 100644
> --- a/po/de.po
> +++ b/po/de.po
...
> #: remote.c:1659
> -#, fuzzy
> msgid " (use \"git pull\" to merge the remote branch into yours)\n"
> msgstr ""
> -" (benutze \"git am --abort\" um den ursprünglichen Zweig wiederherzustellen)"
> +" (benutze \"git pull\" um den externen Zweig mit Deinem zusammenzuführen)\n"
That sounds as if git-pull did something to the remote branch, whereas
it would do something with your local branch. Reverting the roles may help:
+" (benutze \"git pull\" um Deinen Zweig mit dem externen
zusammenzuführen)\n"
BTW: Is there a standard about capitalising or not "Deine/Du" in de.pot?
I think I've seen both here. (New spelling after the reform(s)
recommends du/deine but Sie/Ihr, me thinks.)
> #: builtin/grep.c:740
> msgid "pager"
> @@ -8029,6 +8024,9 @@ msgid ""
> "submodule '%s' (or one of its nested submodules) uses a .git directory\n"
> "(use 'rm -rf' if you really want to remove it including all of its history)"
> msgstr ""
> +"Unterprojekt '%s' (oder ein geschachteltes Unterprojekt dessen) verwendet \n"
s/dessen/hiervon/ ?
> +"ein .git-Verzeichnis (benutze 'rm -rf' wenn du dieses wirklich mit seiner\n"
> +"Historie löschen möchtest)"
s/mit/mitsamt/ ?
(to emphasize "including" like in the original and avoid "mit=by"
misinterpretation)
Michael
^ permalink raw reply
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Thiago Farina @ 2012-12-03 15:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, git, Jeremy White, Johannes Schindelin,
Jeff King
In-Reply-To: <7v624lns00.fsf@alter.siamese.dyndns.org>
On Sat, Dec 1, 2012 at 11:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I suggest a separate patch series dedicated to deleting *all* the extra
>> imap infrastructure at once. That being said, I'm not committing to do
>> so. (We could add it to an "straightforward projects for aspiring git
>> developers" list, if we had such a thing.)
>
> A "low-hanging fruit and/or janitorial work" stack may be worth
> having.
That would be good for not so versed developers, I think. Do we have a
place for listing janitor projects?
^ permalink raw reply
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Michael J Gruber @ 2012-12-03 14:59 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, git, git, jk, stimming
In-Reply-To: <1354510131-2881-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 03.12.2012 05:48:
> Thanks Thomas and Michael!
>
> 2012/11/30 Thomas Rast <trast@inf.ethz.ch>:
>
>>> #: builtin/update-index.c:756
>>> msgid "mark files as \"index-only\""
>>> -msgstr ""
>>> +msgstr "markiert Dateien als \"index-only\""
>>
>> Likewise, but here I don't even understand what the manpage is trying to
>> tell me, in particular I don't see how it would be different from
>> assume-unchanged. Maybe "see manpage" would be the best documentation.
>
> I'm not really sure what to do with it. In this version (see below) I kept
> it. Did you mean we should add "(siehe Hilfeseite)" or something in the
> translation, or does it belong to the original message and the translation
> would just follow?
>
I'd say the translation above is fine, and no matter what language the
user messages are in, the user would have to consult the man page for
this very special feature, but I don't think we have to say so explicitly.
>>> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
>>
>> ISTR we settled on something for 'stage', but it's not in the glossary.
>> Either way I don't think this is it. "Ausführung der Phasen" would mean
>> that it's some part of a process, whereas the stages are a state.
>>
> I've changed it to
> "wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
> What do you think?
>
> ---
> po/de.po | 123 +++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 61 insertions(+), 62 deletions(-)
...
> #: builtin/fsck.c:620
> msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""
Oops ;)
> #: builtin/push.c:391
> msgid "check"
> -msgstr "Überprüfung"
> +msgstr ""
Is this meant to omit the text? (I may have missed the pertaining
discussion.)
> #: builtin/update-index.c:753
> msgid "clear assumed-unchanged bit"
> @@ -8568,7 +8567,7 @@ msgstr "fügt Einträge von der Standard-Eingabe der Bereitstellung hinzu"
> #: builtin/update-index.c:776
> msgid "repopulate stages #2 and #3 for the listed paths"
> msgstr ""
> -"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
> +"wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
I can't seem to find the other occurence in de.po, but state should be
the same as in
"copy out the files from named stage" (checkout-index).
"Zustand" seems to be appropriate.
Cheers,
Michael
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Junio C Hamano @ 2012-12-03 14:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <vpq4nk3uu39.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> But a "gc" does not necessarily run "repack -a" when it does not see
>> too many pack files, so it can end up scanning only the surface of
>> the history to collect the recently created loose objects into a
>> pack, and stop its traversal without going into existing packfiles.
>
> Isn't that the behavior of "git gc --auto", not plain "git gc" ?
True; I missed that Sitaram was running "gc" manually.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Matthieu Moy @ 2012-12-03 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <7vlidgls09.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But a "gc" does not necessarily run "repack -a" when it does not see
> too many pack files, so it can end up scanning only the surface of
> the history to collect the recently created loose objects into a
> pack, and stop its traversal without going into existing packfiles.
Isn't that the behavior of "git gc --auto", not plain "git gc" ?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-03 13:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlidgls09.fsf@alter.siamese.dyndns.org>
On Sun, Dec 2, 2012 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time. Hence my question.
>
> When it does "repack -a", it at least scans the whole history so you
> would be sure that all the commits and trees are readable for the
> purpose of enumerating the objects referred by them (and a bit flip
> in them will likely be noticed by zlib inflation).
>
> But a "gc" does not necessarily run "repack -a" when it does not see
> too many pack files, so it can end up scanning only the surface of
> the history to collect the recently created loose objects into a
> pack, and stop its traversal without going into existing packfiles.
Thanks; I'd missed this nuance as well...
--
Sitaram
^ permalink raw reply
* Re: [BUG?] git-subtree behavior when the -P tree is removed and recreated
From: Tomi Belan @ 2012-12-03 10:39 UTC (permalink / raw)
To: git
In-Reply-To: <CACUV5odffQoCxr=hTuP+S+DU4+6qD7y=YkTCN3iRr7rjar1bLQ@mail.gmail.com>
Another bump. I reported this back in October, but there hasn't been
any response yet...
Note that the bug is still present in git 1.8.0.1.
Tomi
On Sun, Oct 21, 2012 at 11:18 PM, Tomi Belan <tomi.belan@gmail.com> wrote:
> This probably got lost in the mail. Could somebody familiar with
> git-subtree take a look?
> Tomi
>
> On Sat, Oct 13, 2012 at 3:47 PM, Tomi Belan <tomi.belan@gmail.com> wrote:
>>
>> Hello folks,
>>
>> I think I might've found a bug in git-subtree: I have a repository
>> containing a directory "foo". I'd like to use its code in other
>> projects, so I want to split it off into its own repository with
>> git-subtree. But it doesn't work as it should. I found out that long
>> ago, my repository contained an unrelated directory also called "foo"
>> which has since been deleted.
>>
>> Steps to reproduce (after installing git-subtree from contrib):
>> git init repo
>> cd repo
>> mkdir foo; touch foo/v1
>> git add -A .; git commit -m v1
>> rm -rf foo; touch v2
>> git add -A .; git commit -m v2
>> mkdir foo; touch foo/v3
>> git add -A .; git commit -m v3
>> git subtree split -P foo -b splitfoo --annotate="split "
>>
>> What should happen: Either (A) splitfoo only contains "split v3", or
>> (B) splitfoo contains "split v1" and "split v3"
>>
>> What happens instead: The parent of "split v3" is "v2", so splitfoo's
>> full history is: "v1" -> "v2" -> "split v3".
>>
>> Git version: 1.7.12.2
>>
>> Bonus questions:
>> - which is the intended behavior, (A) or (B)?
>> - if it's (B), how do I convince git-subtree to do (A) once this bug
>> gets fixed? (I might be getting too far ahead of myself here...)
>>
>> Tomi
^ permalink raw reply
* Re: [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Matthieu Moy @ 2012-12-03 8:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121203061656.GA20164@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If the user has unset advice.statusHints, we already
> suppress the "use git reset to..." hints in each stanza. The
> new "use git push to publish..." hint is the same type of
> hint. Let's respect statusHints for it, rather than making
> the user set yet another advice flag.
Sorry, I should have made this in the patch.
With or without my suggestion below,
Acknowledged-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> I left "git checkout" alone, though I'd also like to turn it off there,
> too. Should it get a separate advice option there? Should it simply
> respect statusHints (it seems odd because I know that "status" there
> means "git status", not "hints about the status of your repo")?
I'd respect the same statusHint indeed. It's the same message, so I
think the same category of users will want to disable it. The name
"statusHint" may not be the ideal one, but if you see the messages in
"git checkout" as an excerpt of "git status", it actually makes sense.
As a nice side effect, it also makes the code/patch simpler (no need to
add the "advice" argument).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-03 7:58 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, W. Trevor King, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BBB22A.7050901@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Maybe the principle of least surprise is better followed when we
> nuke the whole section, as it might surprise the user more to have
> a setting resurrected he customized in the last life cycle of the
> submodule than seeing that after an deinit followed by an init all
> former customizations are consistently gone. So I tend to think now
> that removing the whole section would be the better solution here.
I tend to agree; I suspect that a "deinit" would be mostly done
either to
(1) correct mistakes the user made during a recent "init" and
perhaps "sync"; or
(2) tell Git that the user has finished woing with this particular
submodule and does not intend to use it for quite a while.
For both (1) and (2), I think it would be easier to users if we gave
them a clean slate, the same state as the one the user who never had
ran "init" on it would be in. A user in situation (1) is asking for
a clean slate, and a user in situation (2) is better served if he
does not have to worry about leftover entries in $GIT_DIR/config he
has long forgotten from many months ago (during which time the way
the project uses the particular submodule may well have changed)
giving non-standard experience different from what other project
participants would get.
If there were a sane workflow where it makes sense to frequently run
"deinit" followed by some operation followed by "init", it may be
helpful to have an option to keep the other customization. And one
consideration when implementing that "deinit --keep-customization"
option might be to introduce the submodule.$name.activated boolean;
that way, the operation can keep the customized upstream URL.
In any case, it needs to be shown that such a workflow exists in the
first place to justify "deinit --keep-customization". I think the
default should be to remove the submodule.$name section.
^ permalink raw reply
* [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Jeff King @ 2012-12-03 6:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
If the user has unset advice.statusHints, we already
suppress the "use git reset to..." hints in each stanza. The
new "use git push to publish..." hint is the same type of
hint. Let's respect statusHints for it, rather than making
the user set yet another advice flag.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of mm/status-push-pull-advise.
I left "git checkout" alone, though I'd also like to turn it off there,
too. Should it get a separate advice option there? Should it simply
respect statusHints (it seems odd because I know that "status" there
means "git status", not "hints about the status of your repo")?
builtin/checkout.c | 2 +-
remote.c | 17 ++++++++++-------
remote.h | 2 +-
wt-status.c | 2 +-
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 781295b..28146d1 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -544,7 +544,7 @@ static void report_tracking(struct branch_info *new)
struct strbuf sb = STRBUF_INIT;
struct branch *branch = branch_get(new->name);
- if (!format_tracking_info(branch, &sb))
+ if (!format_tracking_info(branch, &sb, 1))
return;
fputs(sb.buf, stdout);
strbuf_release(&sb);
diff --git a/remote.c b/remote.c
index 9c19689..176a777 100644
--- a/remote.c
+++ b/remote.c
@@ -1617,7 +1617,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
/*
* Return true when there is anything to report, otherwise false.
*/
-int format_tracking_info(struct branch *branch, struct strbuf *sb)
+int format_tracking_info(struct branch *branch, struct strbuf *sb, int advice)
{
int num_ours, num_theirs;
const char *base;
@@ -1633,8 +1633,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"Your branch is ahead of '%s' by %d commits.\n",
num_ours),
base, num_ours);
- strbuf_addf(sb,
- _(" (use \"git push\" to publish your local commits)\n"));
+ if (advice)
+ strbuf_addf(sb,
+ _(" (use \"git push\" to publish your local commits)\n"));
} else if (!num_ours) {
strbuf_addf(sb,
Q_("Your branch is behind '%s' by %d commit, "
@@ -1643,8 +1644,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"and can be fast-forwarded.\n",
num_theirs),
base, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to update your local branch)\n"));
+ if (advice)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to update your local branch)\n"));
} else {
strbuf_addf(sb,
Q_("Your branch and '%s' have diverged,\n"
@@ -1655,8 +1657,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"respectively.\n",
num_theirs),
base, num_ours, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to merge the remote branch into yours)\n"));
+ if (advice)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to merge the remote branch into yours)\n"));
}
return 1;
}
diff --git a/remote.h b/remote.h
index 251d8fd..ac504a5 100644
--- a/remote.h
+++ b/remote.h
@@ -153,7 +153,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs);
/* Reporting of tracking info */
int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs);
-int format_tracking_info(struct branch *branch, struct strbuf *sb);
+int format_tracking_info(struct branch *branch, struct strbuf *sb, int advice);
struct ref *get_local_heads(void);
/*
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..b48c8cf 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -755,7 +755,7 @@ static void wt_status_print_tracking(struct wt_status *s)
if (prefixcmp(s->branch, "refs/heads/"))
return;
branch = branch_get(s->branch + 11);
- if (!format_tracking_info(branch, &sb))
+ if (!format_tracking_info(branch, &sb, advice_status_hints))
return;
for (cp = sb.buf; (ep = strchr(cp, '\n')) != NULL; cp = ep + 1)
--
1.7.12.4.42.ge2b5b43
^ permalink raw reply related
* [PATCH] l10n: de.po: translate 22 new messages
From: Ralf Thielow @ 2012-12-03 4:49 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
Translate 22 new messages came from git.pot
updates in 9306b5b (l10n: Update git.pot (3 new,
6 removed messages)), fe52cd6 (l10n: Update git.pot
(14 new, 3 removed messages)) and f9472e3
(l10n: Update git.pot (5 new, 1 removed messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 68 ++++++++++++++++++++++++++++++++++------------------------------
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/po/de.po b/po/de.po
index a0bf3da..7350818 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5,7 +5,7 @@
#
msgid ""
msgstr ""
-"Project-Id-Version: git 1.8.0\n"
+"Project-Id-Version: git 1.8.1\n"
"Report-Msgid-Bugs-To: Git Mailing List <git@vger.kernel.org>\n"
"POT-Creation-Date: 2012-11-30 12:40+0800\n"
"PO-Revision-Date: 2012-10-02 19:35+0200\n"
@@ -130,6 +130,8 @@ msgid ""
"Negative patterns are forbidden in git attributes\n"
"Use '\\!' for literal leading exclamation."
msgstr ""
+"Verneinende Muster sind in Git-Attributen verboten.\n"
+"Benutze '\\!' für führende Ausrufezeichen."
#: bundle.c:36
#, c-format
@@ -305,22 +307,21 @@ msgstr[0] "vor %lu Jahr"
msgstr[1] "vor %lu Jahren"
#: diff.c:111
-#, fuzzy, c-format
+#, c-format
msgid " Failed to parse dirstat cut-off percentage '%s'\n"
msgstr ""
-" Fehler beim Parsen des abgeschnittenen \"dirstat\" Prozentsatzes '%.*s'\n"
+" Fehler beim Parsen des abgeschnittenen \"dirstat\" Prozentsatzes '%s'\n"
#: diff.c:116
-#, fuzzy, c-format
+#, c-format
msgid " Unknown dirstat parameter '%s'\n"
-msgstr " Unbekannter \"dirstat\" Parameter '%.*s'\n"
+msgstr " Unbekannter \"dirstat\" Parameter '%s'\n"
#: diff.c:194
-#, fuzzy, c-format
+#, c-format
msgid "Unknown value for 'diff.submodule' config variable: '%s'"
msgstr ""
-"Fehler in 'diff.dirstat' Konfigurationsvariable gefunden:\n"
-"%s"
+"Unbekannter Wert in Konfigurationsvariable 'diff.dirstat': '%s'"
#: diff.c:237
#, c-format
@@ -341,11 +342,10 @@ msgstr ""
"%s"
#: diff.c:3508
-#, fuzzy, c-format
+#, c-format
msgid "Failed to parse --submodule option parameter: '%s'"
msgstr ""
-"Fehler beim Parsen des --dirstat/-X Optionsparameters:\n"
-"%s"
+"Fehler beim Parsen des --submodule Optionsparameters: '%s'"
#: gpg-interface.c:59
msgid "could not run gpg."
@@ -726,7 +726,7 @@ msgstr[1] "Dein Zweig ist vor '%s' um %d Versionen.\n"
#: remote.c:1637
msgid " (use \"git push\" to publish your local commits)\n"
-msgstr ""
+msgstr " (benutze \"git push\" um deine lokalen Versionen herauszubringen)\n"
#: remote.c:1640
#, c-format
@@ -740,10 +740,9 @@ msgstr[1] ""
"werden.\n"
#: remote.c:1647
-#, fuzzy
msgid " (use \"git pull\" to update your local branch)\n"
msgstr ""
-" (benutze \"git am --abort\" um den ursprünglichen Zweig wiederherzustellen)"
+" (benutze \"git pull\" um deinen lokalen Zweig zu aktualisieren)\n"
#: remote.c:1650
#, c-format
@@ -761,10 +760,9 @@ msgstr[1] ""
"und haben jeweils %d und %d unterschiedliche Versionen.\n"
#: remote.c:1659
-#, fuzzy
msgid " (use \"git pull\" to merge the remote branch into yours)\n"
msgstr ""
-" (benutze \"git am --abort\" um den ursprünglichen Zweig wiederherzustellen)"
+" (benutze \"git pull\" um den externen Zweig mit Deinem zusammenzuführen)\n"
#: sequencer.c:123 builtin/merge.c:761 builtin/merge.c:874 builtin/merge.c:984
#: builtin/merge.c:994
@@ -2614,9 +2612,8 @@ msgid "git check-attr [-a | --all | attr...] [--] pathname..."
msgstr "git check-attr [-a | --all | Attribut...] [--] Pfadname..."
#: builtin/check-attr.c:12
-#, fuzzy
msgid "git check-attr --stdin [-z] [-a | --all | attr...] < <list-of-paths>"
-msgstr "git check-attr --stdin [-a | --all | Attribut...] < <Liste-von-Pfaden>"
+msgstr "git check-attr --stdin [-z] [-a | --all | Attribut...] < <Liste-von-Pfaden>"
#: builtin/check-attr.c:19
msgid "report all attributes set on file"
@@ -3596,9 +3593,8 @@ msgid "Paths with -a does not make sense."
msgstr "Pfade mit -a machen keinen Sinn."
#: builtin/commit.c:1067 builtin/commit.c:1202
-#, fuzzy
msgid "--long and -z are incompatible"
-msgstr "--column und -n sind inkompatibel"
+msgstr "--long und -z sind inkompatibel"
#: builtin/commit.c:1162 builtin/commit.c:1398
msgid "show status concisely"
@@ -3613,9 +3609,8 @@ msgid "machine-readable output"
msgstr "maschinenlesbare Ausgabe"
#: builtin/commit.c:1169 builtin/commit.c:1404
-#, fuzzy
msgid "show status in long format (default)"
-msgstr "zeigt zwischengespeicherten Dateien in der Ausgabe an (Standard)"
+msgstr "zeigt Status im Langformat (Standard)"
#: builtin/commit.c:1172 builtin/commit.c:1407
msgid "terminate entries with NUL"
@@ -4789,7 +4784,7 @@ msgstr "zeigt nur Übereinstimmungen von Dateien, die allen Mustern entsprechen"
#: builtin/grep.c:736
msgid "show parse tree for grep expression"
-msgstr ""
+msgstr "zeigt geparsten Baum für \"grep\"-Ausdruck"
#: builtin/grep.c:740
msgid "pager"
@@ -8029,6 +8024,9 @@ msgid ""
"submodule '%s' (or one of its nested submodules) uses a .git directory\n"
"(use 'rm -rf' if you really want to remove it including all of its history)"
msgstr ""
+"Unterprojekt '%s' (oder ein geschachteltes Unterprojekt dessen) verwendet \n"
+"ein .git-Verzeichnis (benutze 'rm -rf' wenn du dieses wirklich mit seiner\n"
+"Historie löschen möchtest)"
#: builtin/rm.c:174
#, c-format
@@ -8254,9 +8252,8 @@ msgid "git symbolic-ref [options] name [ref]"
msgstr "git symbolic-ref [Optionen] name [ref]"
#: builtin/symbolic-ref.c:8
-#, fuzzy
msgid "git symbolic-ref -d [-q] name"
-msgstr "git symbolic-ref [Optionen] name [ref]"
+msgstr "git symbolic-ref -d [-q] name"
#: builtin/symbolic-ref.c:40
msgid "suppress error message for non-symbolic (detached) refs"
@@ -8264,9 +8261,8 @@ msgstr ""
"unterdrückt Fehlermeldungen für nicht-symbolische (losgelöste) Referenzen"
#: builtin/symbolic-ref.c:41
-#, fuzzy
msgid "delete symbolic ref"
-msgstr "löscht ersetzende Referenzen"
+msgstr "löscht symbolische Referenzen"
#: builtin/symbolic-ref.c:42
msgid "shorten ref output"
@@ -9207,7 +9203,8 @@ msgstr "Kein Neuaufbau im Gange?"
#: git-rebase.sh:312
msgid "The --edit-todo action can only be used during interactive rebase."
-msgstr ""
+msgstr "Die --edit-todo Aktion kann nur während eines interaktiven "
+"Neuaufbaus benutzt werden."
#: git-rebase.sh:319
msgid "Cannot read HEAD"
@@ -9492,19 +9489,24 @@ msgstr "'$sm_path' existiert bereits und ist kein gültiges Git-Projektarchiv"
#: git-submodule.sh:365
#, sh-format
msgid "A git directory for '$sm_name' is found locally with remote(s):"
-msgstr ""
+msgstr "Ein Git-Verzeichnis für '$sm_name' wurde lokal gefunden mit den "
+"Fernarchiv(en):"
#: git-submodule.sh:367
#, sh-format
msgid ""
"If you want to reuse this local git directory instead of cloning again from"
msgstr ""
+"Wenn du dieses lokale Git-Verzeichnis wiederverwenden möchtest, anstatt "
+"erneut zu klonen"
#: git-submodule.sh:369
#, sh-format
msgid ""
"use the '--force' option. If the local git directory is not the correct repo"
msgstr ""
+"benutze die Option '--force'. Wenn das lokale Git-Verzeichnis nicht das "
+"korrekte Projektarchiv ist"
#: git-submodule.sh:370
#, sh-format
@@ -9512,11 +9514,13 @@ msgid ""
"or you are unsure what this means choose another name with the '--name' "
"option."
msgstr ""
+"oder du dir unsicher bist, was das bedeutet, wähle einen anderen Namen mit "
+"der Option '--name'."
#: git-submodule.sh:372
#, sh-format
msgid "Reactivating local git directory for submodule '$sm_name'."
-msgstr ""
+msgstr "Reaktiviere lokales Git-Verzeichnis für Unterprojekt '$sm_name'."
#: git-submodule.sh:384
#, sh-format
@@ -9659,9 +9663,9 @@ msgid "# Submodule changes to be committed:"
msgstr "# Änderungen in Unterprojekt zum Eintragen:"
#: git-submodule.sh:1080
-#, fuzzy, sh-format
+#, sh-format
msgid "Synchronizing submodule url for '$prefix$sm_path'"
-msgstr "Synchronisiere Unterprojekt-URL für '$name'"
+msgstr "Synchronisiere Unterprojekt-URL für '$prefix$sm_path'"
#~ msgid " 0 files changed"
#~ msgstr " 0 Dateien geändert"
--
1.8.0.1
^ permalink raw reply related
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Ralf Thielow @ 2012-12-03 4:48 UTC (permalink / raw)
To: trast, git; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <87ehjcj9lq.fsf@pctrast.inf.ethz.ch>
Thanks Thomas and Michael!
2012/11/30 Thomas Rast <trast@inf.ethz.ch>:
>> #: builtin/update-index.c:756
>> msgid "mark files as \"index-only\""
>> -msgstr ""
>> +msgstr "markiert Dateien als \"index-only\""
>
> Likewise, but here I don't even understand what the manpage is trying to
> tell me, in particular I don't see how it would be different from
> assume-unchanged. Maybe "see manpage" would be the best documentation.
I'm not really sure what to do with it. In this version (see below) I kept
it. Did you mean we should add "(siehe Hilfeseite)" or something in the
translation, or does it belong to the original message and the translation
would just follow?
>> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
>
> ISTR we settled on something for 'stage', but it's not in the glossary.
> Either way I don't think this is it. "Ausführung der Phasen" would mean
> that it's some part of a process, whereas the stages are a state.
>
I've changed it to
"wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
What do you think?
---
po/de.po | 123 +++++++++++++++++++++++++++++++--------------------------------
1 file changed, 61 insertions(+), 62 deletions(-)
diff --git a/po/de.po b/po/de.po
index 1f49610..5e14d9c 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1978,7 +1978,7 @@ msgstr "Pfade sind getrennt durch NUL Zeichen"
#: builtin/apply.c:4336
msgid "ensure at least <n> lines of context match"
msgstr ""
-"stellt sicher, dass mindestens <Anzahl> Zeilen des Kontextes übereinstimmen"
+"stellt sicher, dass mindestens <n> Zeilen des Kontextes übereinstimmen"
#: builtin/apply.c:4337
msgid "action"
@@ -2167,7 +2167,7 @@ msgstr "Unterdrückt den Namen des Autors und den Zeitstempel (Standard: aus)"
#: builtin/blame.c:2329
msgid "Show author email instead of name (Default: off)"
-msgstr "Zeigt anstatt des Namens die eMail-Adresse des Autors (Standard: aus)"
+msgstr "Zeigt anstatt des Namens die Email-Adresse des Autors (Standard: aus)"
#: builtin/blame.c:2330
msgid "Ignore whitespace differences"
@@ -4072,7 +4072,7 @@ msgstr "gibt nur exakte Übereinstimmungen aus"
#: builtin/describe.c:412
msgid "consider <n> most recent tags (default: 10)"
-msgstr "betrachtet die jüngsten <Anzahl> Markierungen (Standard: 10)"
+msgstr "betrachtet die jüngsten <n> Markierungen (Standard: 10)"
#: builtin/describe.c:414
msgid "only consider tags matching <pattern>"
@@ -4143,7 +4143,7 @@ msgstr "git fast-export [rev-list-opts]"
#: builtin/fast-export.c:635
msgid "show progress after <n> objects"
-msgstr "zeigt Fortschritt nach <Anzahl> Objekten an"
+msgstr "zeigt Fortschritt nach <n> Objekten an"
#: builtin/fast-export.c:637
msgid "select handling of signed tags"
@@ -4422,7 +4422,7 @@ msgstr ""
#: builtin/fmt-merge-msg.c:13
msgid "git fmt-merge-msg [-m <message>] [--log[=<n>]|--no-log] [--file <file>]"
msgstr ""
-"git fmt-merge-msg [-m <Beschreibung>] [--log[=<Anzahl>]|--no-log] [--file "
+"git fmt-merge-msg [-m <Beschreibung>] [--log[=<n>]|--no-log] [--file "
"<Datei>]"
#: builtin/fmt-merge-msg.c:653 builtin/fmt-merge-msg.c:656 builtin/grep.c:786
@@ -4433,7 +4433,7 @@ msgstr "Anzahl"
#: builtin/fmt-merge-msg.c:654
msgid "populate log with at most <n> entries from shortlog"
-msgstr "fügt Historie mit höchstens <Nummer> Einträgen von \"shortlog\" hinzu"
+msgstr "fügt Historie mit höchstens <n> Einträgen von \"shortlog\" hinzu"
#: builtin/fmt-merge-msg.c:657
msgid "alias for --log (deprecated)"
@@ -4457,23 +4457,23 @@ msgstr "git for-each-ref [Optionen] [<Muster>]"
#: builtin/for-each-ref.c:994
msgid "quote placeholders suitably for shells"
-msgstr "quotiert Platzhalter geeignet für Shells"
+msgstr "formatiert Platzhalter als Shell-String"
#: builtin/for-each-ref.c:996
msgid "quote placeholders suitably for perl"
-msgstr "quotiert Platzhalter geeignet für Perl"
+msgstr "formatiert Platzhalter als Perl-String"
#: builtin/for-each-ref.c:998
msgid "quote placeholders suitably for python"
-msgstr "quotiert Platzhalter geeignet für Python"
+msgstr "formatiert Platzhalter als Python-String"
#: builtin/for-each-ref.c:1000
msgid "quote placeholders suitably for tcl"
-msgstr "quotiert Platzhalter geeignet für TCL"
+msgstr "formatiert Platzhalter als TCL-String"
#: builtin/for-each-ref.c:1003
msgid "show only <n> matched refs"
-msgstr "zeigt nur <Nummer> passende Referenzen"
+msgstr "zeigt nur <n> passende Referenzen"
#: builtin/for-each-ref.c:1004
msgid "format"
@@ -4489,7 +4489,7 @@ msgstr "Schüssel"
#: builtin/for-each-ref.c:1006
msgid "field name to sort on"
-msgstr "Name des Felder zum Sortieren"
+msgstr "sortiere nach diesem Feld"
#: builtin/fsck.c:608
msgid "git fsck [options] [<object>...]"
@@ -4521,7 +4521,7 @@ msgstr "erzeugt Kopfknoten des Referenzprotokolls (Standard)"
#: builtin/fsck.c:620
msgid "also consider packs and alternate objects"
-msgstr "betrachtet auch Pakete und wechselnde Objekte"
+msgstr ""
#: builtin/fsck.c:621
msgid "enable more strict checking"
@@ -4645,7 +4645,7 @@ msgstr "findet Übereinstimmungen unabhängig von Groß- und Kleinschreibung"
#: builtin/grep.c:741
msgid "match patterns only at word boundaries"
-msgstr "findet Muster nur innerhalb von Wörtern"
+msgstr "sucht nur ganze Wörter"
#: builtin/grep.c:743
msgid "process binary files as text"
@@ -4728,15 +4728,15 @@ msgstr ""
#: builtin/grep.c:787
msgid "show <n> context lines before and after matches"
-msgstr "zeigt <Anzahl> Zeilen vor und nach den Übereinstimmungen an"
+msgstr "zeigt <n> Zeilen vor und nach den Übereinstimmungen an"
#: builtin/grep.c:790
msgid "show <n> context lines before matches"
-msgstr "zeigt <Anzahl> Zeilen vor den Übereinstimmungen an"
+msgstr "zeigt <n> Zeilen vor den Übereinstimmungen an"
#: builtin/grep.c:792
msgid "show <n> context lines after matches"
-msgstr "zeigt <Anzahl> Zeilen nach den Übereinstimmungen an"
+msgstr "zeigt <n> Zeilen nach den Übereinstimmungen an"
#: builtin/grep.c:793
msgid "shortcut for -C NUM"
@@ -4764,7 +4764,7 @@ msgstr "kombiniert Muster, die mit -e angegeben wurden"
#: builtin/grep.c:817
msgid "indicate hit with exit status without output"
-msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
+msgstr "zeigt Übereinstimmungen nur durch Beendigungsstatus an"
#: builtin/grep.c:819
msgid "show only matches from files that match all patterns"
@@ -4850,7 +4850,7 @@ msgstr "speichert Datei wie sie ist, ohne Filter"
#: builtin/hash-object.c:77
msgid "process file as it were from this path"
-msgstr "verarbeitet Datei, wie es von diesem Pfad wäre"
+msgstr "verarbeitet Datei, als ob sie von diesem Pfad wäre"
#: builtin/help.c:43
msgid "print all available commands"
@@ -4866,7 +4866,7 @@ msgstr "zeigt Handbuch in einem Webbrowser"
#: builtin/help.c:47
msgid "show info page"
-msgstr "zeigt Informationsseite"
+msgstr "zeigt Info-Seite"
#: builtin/help.c:53
msgid "git help [--all] [--man|--web|--info] [command]"
@@ -5110,7 +5110,7 @@ msgstr "Fehler beim Auflösen der Unterschiede"
#: builtin/index-pack.c:1112
#, c-format
msgid "completed with %d local objects"
-msgstr "fertiggestellt mit %d lokalen Objekten"
+msgstr "vervollständigt mit %d lokalen Objekten"
#: builtin/index-pack.c:1121
#, c-format
@@ -5401,7 +5401,7 @@ msgstr "zeigt Quelle"
#: builtin/log.c:102
msgid "decorate options"
-msgstr "Ausgabeoptionen"
+msgstr "decorate-Optionen"
#: builtin/log.c:189
#, c-format
@@ -5486,7 +5486,7 @@ msgstr "verwendet <Dateiendung> anstatt '.patch'"
#: builtin/log.c:1078
msgid "start numbering patches at <n> instead of 1"
-msgstr "beginnt die Nummerierung der Patches bei <Nummer> anstatt bei 1"
+msgstr "beginnt die Nummerierung der Patches bei <n> anstatt bei 1"
#: builtin/log.c:1080
msgid "Use [<prefix>] instead of [PATCH]"
@@ -5507,8 +5507,7 @@ msgstr "gibt keine binären Unterschiede aus"
#: builtin/log.c:1091
msgid "don't include a patch matching a commit upstream"
msgstr ""
-"schließt keine Patches ein, die einer Version im externen Projektarchiv "
-"entsprechen"
+"schließt keine Patches ein, die einer Version im Übernahmezweig entsprechen"
#: builtin/log.c:1093
msgid "show patch format instead of default (patch + stat)"
@@ -5516,27 +5515,27 @@ msgstr "zeigt Patchformat anstatt des Standards (Patch + Zusammenfassung)"
#: builtin/log.c:1095
msgid "Messaging"
-msgstr "Datentransfer"
+msgstr "Email-Einstellungen"
#: builtin/log.c:1096
msgid "header"
-msgstr "Kopfteil"
+msgstr "Header"
#: builtin/log.c:1097
msgid "add email header"
-msgstr "fügt Kopfteil für eMail hinzu"
+msgstr "fügt Email-Header hinzu"
#: builtin/log.c:1098 builtin/log.c:1100
msgid "email"
-msgstr "eMail"
+msgstr "Email"
#: builtin/log.c:1098
msgid "add To: header"
-msgstr "fügt Kopfteil \"To:\" hinzu"
+msgstr "fügt \"To:\"-Header hinzu"
#: builtin/log.c:1100
msgid "add Cc: header"
-msgstr "fügt Kopteil \"Cc:\" hinzu"
+msgstr "fügt \"Cc:\"-Header hinzu"
#: builtin/log.c:1102
msgid "message-id"
@@ -5544,7 +5543,7 @@ msgstr "message-id"
#: builtin/log.c:1103
msgid "make first mail a reply to <message-id>"
-msgstr "macht aus erster eMail eine Antwort zu <message-id>"
+msgstr "macht aus erster Email eine Antwort zu <message-id>"
#: builtin/log.c:1104 builtin/log.c:1107
msgid "boundary"
@@ -5556,7 +5555,7 @@ msgstr "hängt einen Patch an"
#: builtin/log.c:1108
msgid "inline the patch"
-msgstr "fügt einen Patch ein"
+msgstr "fügt den Patch direkt in die Nachricht ein"
#: builtin/log.c:1112
msgid "enable message threading, styles: shallow, deep"
@@ -5635,7 +5634,7 @@ msgstr "git ls-files [Optionen] [<Datei>...]"
#: builtin/ls-files.c:463
msgid "identify the file status with tags"
-msgstr "bestimmt den Dateistatus mit Markierungen"
+msgstr "zeigt den Dateistatus mit Markierungen"
#: builtin/ls-files.c:465
msgid "use lowercase letters for 'assume unchanged' files"
@@ -5812,7 +5811,7 @@ msgstr "(Synonym für --stat)"
#: builtin/merge.c:189
msgid "add (at most <n>) entries from shortlog to merge commit message"
msgstr ""
-"fügt (höchstens <Nummber>) Einträge von \"short\" zur Beschreibung der "
+"fügt (höchstens <n>) Einträge von \"shortlog\" zur Beschreibung der "
"Zusammenführung hinzu"
#: builtin/merge.c:192
@@ -6502,7 +6501,7 @@ msgstr "Ungültiger notes.rewriteMode Wert: '%s'"
#, c-format
msgid "Refusing to rewrite notes in %s (outside of refs/notes/)"
msgstr ""
-"Neuschreiben der Notizen in %s zurückgewiesen (außerhalb von refs/notes/)"
+"Umschreiben der Notizen in %s zurückgewiesen (außerhalb von refs/notes/)"
#. TRANSLATORS: The first %s is the name of the
#. environment variable, the second %s is its value
@@ -6578,7 +6577,7 @@ msgstr "liest Objekte von der Standard-Eingabe"
#: builtin/notes.c:617
msgid "load rewriting config for <command> (implies --stdin)"
msgstr ""
-"lädt Konfiguration für <Kommando> beim Überschreiben von Versionen "
+"lädt Konfiguration für <Kommando> beim Umschreiben von Versionen "
"(impliziert --stdin)"
#: builtin/notes.c:635
@@ -6817,7 +6816,7 @@ msgstr "entpackt nicht erreichbare Objekte, die neuer als <Zeit> sind"
#: builtin/pack-objects.c:2502
msgid "create thin packs"
-msgstr "erzeugt kleinere Pakete"
+msgstr "erzeugt dünnere Pakete"
#: builtin/pack-objects.c:2504
msgid "ignore packs that have companion .keep file"
@@ -6845,7 +6844,7 @@ msgstr "entfernt lose Referenzen (Standard)"
#: builtin/prune-packed.c:7
msgid "git prune-packed [-n|--dry-run] [-q|--quiet]"
-msgstr "git prune-packed [-n|--dry-run] [-q|--quite]"
+msgstr "git prune-packed [-n|--dry-run] [-q|--quiet]"
#: builtin/prune.c:12
msgid "git prune [-n] [-v] [--expire <time>] [--] [<head>...]"
@@ -7123,7 +7122,7 @@ msgstr "erzwingt Aktualisierung"
#: builtin/push.c:391
msgid "check"
-msgstr "Überprüfung"
+msgstr ""
#: builtin/push.c:392
msgid "control recursive pushing of submodules"
@@ -7135,7 +7134,7 @@ msgstr "benutzt kleinere Pakete"
#: builtin/push.c:395 builtin/push.c:396
msgid "receive pack program"
-msgstr "Programm zum Empfangen von Paketen"
+msgstr "'receive pack' Programm"
#: builtin/push.c:397
msgid "set upstream for git pull/status"
@@ -7170,7 +7169,7 @@ msgstr "schreibt resultierende Bereitstellung nach <Datei>"
#: builtin/read-tree.c:111
msgid "only empty the index"
-msgstr "leert nur die Bereitstellung"
+msgstr "leert die Bereitstellung"
#: builtin/read-tree.c:113
msgid "Merging"
@@ -7233,7 +7232,7 @@ msgstr "protokolliert Entpacken der Bäume"
#: builtin/remote.c:11
msgid "git remote [-v | --verbose]"
-msgstr "git remove [-v | --verbose]"
+msgstr "git remote [-v | --verbose]"
#: builtin/remote.c:12
msgid ""
@@ -7359,7 +7358,7 @@ msgstr "push|fetch"
#: builtin/remote.c:173
msgid "set up remote as a mirror to push to or fetch from"
msgstr ""
-"Aufsetzen der Fernarchivs als Spiegelarchiv zum Versenden und Anfordern"
+"Aufsetzen des Fernarchivs als Spiegelarchiv zum Versenden und Anfordern"
#: builtin/remote.c:185
msgid "specifying a master branch makes no sense with --mirror"
@@ -7913,8 +7912,8 @@ msgid ""
"Run \"git rev-parse --parseopt -h\" for more information on the first usage."
msgstr ""
"git rev-parse --parseopt [Optionen] -- [<Argumente>...]\n"
-" or: git rev-parse --sq-quote [<Argumente>...]\n"
-" or: git rev-parse [Optionen] [<Argumente>...]\n"
+" oder: git rev-parse --sq-quote [<Argumente>...]\n"
+" oder: git rev-parse [Optionen] [<Argumente>...]\n"
"\n"
"Führe \"git rev-parse --parseopt -h\" für weitere Informationen bei erster "
"Verwendung aus."
@@ -8092,7 +8091,7 @@ msgstr "Unterdrückt Versionsbeschreibungen, liefert nur Anzahl der Versionen"
#: builtin/shortlog.c:257
msgid "Show the email address of each author"
-msgstr "Zeigt die eMail-Adresse von jedem Autor"
+msgstr "Zeigt die Email-Adresse von jedem Autor"
#: builtin/shortlog.c:258
msgid "w[,i1[,i2]]"
@@ -8110,22 +8109,22 @@ msgid ""
"<glob>)...]"
msgstr ""
"git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--"
-"current] [--color[=<Wann>] | --no-color] [--sparse] [--more=<Nummer> | --"
+"current] [--color[=<Wann>] | --no-color] [--sparse] [--more=<n> | --"
"list | --independent | --merge-base] [--no-name | --sha1-name] [--topics] "
"[(<Revision> | <glob>)...]"
#: builtin/show-branch.c:10
msgid "git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]"
msgstr ""
-"git show-branch (-g|--reflog)[=<Nummer>[,<Basis>]] [--list] [<Referenz>]"
+"git show-branch (-g|--reflog)[=<n>[,<Basis>]] [--list] [<Referenz>]"
#: builtin/show-branch.c:651
msgid "show remote-tracking and local branches"
-msgstr "zeigt externer Übernahmezweige und lokale Zweige an"
+msgstr "zeigt externe Übernahmezweige und lokale Zweige an"
#: builtin/show-branch.c:653
msgid "show remote-tracking branches"
-msgstr "zeigt externer Übernahmezweige an"
+msgstr "zeigt externe Übernahmezweige an"
#: builtin/show-branch.c:655
msgid "color '*!+-' corresponding to the branch"
@@ -8133,7 +8132,7 @@ msgstr "färbt '*!+-' entsprechend des Zweiges ein"
#: builtin/show-branch.c:657
msgid "show <n> more commits after the common ancestor"
-msgstr "zeigt <Nummer> weitere Versionen nach dem gemeinsamen Vorfahren"
+msgstr "zeigt <n> weitere Versionen nach dem gemeinsamen Vorfahren"
#: builtin/show-branch.c:659
msgid "synonym to more=-1"
@@ -8178,12 +8177,12 @@ msgstr "zeigt Versionen, wo kein Elternteil vor seinem Kind kommt"
#: builtin/show-branch.c:678
msgid "<n>[,<base>]"
-msgstr "<Nummer>[,<Basis>]"
+msgstr "<n>[,<Basis>]"
#: builtin/show-branch.c:679
msgid "show <n> most recent ref-log entries starting at base"
msgstr ""
-"zeigt die <Nummer> jüngsten Einträge im Referenzprotokoll beginnend an der "
+"zeigt die <n> jüngsten Einträge im Referenzprotokoll beginnend an der "
"Basis"
#: builtin/show-ref.c:10
@@ -8192,7 +8191,7 @@ msgid ""
"[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [pattern*] "
msgstr ""
"git show-ref [-q|--quiet] [--verify] [--head] [-d|--dereference] [-s|--hash"
-"[=<Nummer>]] [--abbrev[=<Nummer>]] [--tags] [--heads] [--] [pattern*] "
+"[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [pattern*] "
#: builtin/show-ref.c:11
msgid "git show-ref --exclude-existing[=pattern] < ref-list"
@@ -8220,7 +8219,7 @@ msgstr "dereferenziert Markierungen in Objekt-Identifikationen"
#: builtin/show-ref.c:193
msgid "only show SHA1 hash using <n> digits"
-msgstr "zeigt nur SHA1 Hash mit <Nummer> Ziffern"
+msgstr "zeigt nur SHA1 Hash mit <n> Ziffern"
#: builtin/show-ref.c:197
msgid "do not print results to stdout (useful with --verify)"
@@ -8372,7 +8371,7 @@ msgstr "listet Markierungsnamen auf"
#: builtin/tag.c:449
msgid "print <n> lines of each tag message"
-msgstr "zeigt <Anzahl> Zeilen jeder Markierungsbeschreibung"
+msgstr "zeigt <n> Zeilen jeder Markierungsbeschreibung"
#: builtin/tag.c:451
msgid "delete tags"
@@ -8400,7 +8399,7 @@ msgstr "annotierte und GPG-signierte Markierung"
#: builtin/tag.c:464
msgid "use another key to sign the tag"
-msgstr "benutzt einen Schlüssel um die Markierung zu signieren"
+msgstr "benutzt einen anderen Schlüssel um die Markierung zu signieren"
#: builtin/tag.c:465
msgid "replace the tag if exists"
@@ -8529,7 +8528,7 @@ msgstr "überschreibt das \"ausführbar\"-Bit der aufgelisteten Dateien"
#: builtin/update-index.c:750
msgid "mark files as \"not changing\""
-msgstr "markiert Dateien als \"not changing\""
+msgstr "betrachte diese Datei immer als unverändert"
#: builtin/update-index.c:753
msgid "clear assumed-unchanged bit"
@@ -8568,7 +8567,7 @@ msgstr "fügt Einträge von der Standard-Eingabe der Bereitstellung hinzu"
#: builtin/update-index.c:776
msgid "repopulate stages #2 and #3 for the listed paths"
msgstr ""
-"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
+"wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
#: builtin/update-index.c:780
msgid "only update entries that differ from HEAD"
@@ -8671,7 +8670,7 @@ msgstr "weniger Ausgaben"
#: parse-options.h:236
msgid "use <n> digits to display SHA-1s"
-msgstr "benutze <Anzahl> Ziffern zur Anzeige von SHA-1s"
+msgstr "benutze <n> Ziffern zur Anzeige von SHA-1s"
#: common-cmds.h:8
msgid "Add file contents to the index"
@@ -8883,7 +8882,7 @@ msgstr ""
#: git-am.sh:706
msgid "Patch does not have a valid e-mail address."
-msgstr "Patch enthält keine gültige eMail-Adresse."
+msgstr "Patch enthält keine gültige Email-Adresse."
#: git-am.sh:753
msgid "cannot be interactive without stdin connected to a terminal."
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] push: allow already-exists advice to be disabled
From: Chris Rorvick @ 2012-12-03 3:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Chris Rorvick, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Jeff King, Felipe Contreras
In-Reply-To: <1354505271-25657-1-git-send-email-chris@rorvick.com>
Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/config.txt | 8 ++++++--
advice.c | 2 ++
advice.h | 1 +
builtin/push.c | 2 ++
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 92903f2..90e7d10 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -142,8 +142,9 @@ advice.*::
--
pushUpdateRejected::
Set this variable to 'false' if you want to disable
- 'pushNonFFCurrent', 'pushNonFFDefault', and
- 'pushNonFFMatching' simultaneously.
+ 'pushNonFFCurrent', 'pushNonFFDefault',
+ 'pushNonFFMatching', and 'pushAlreadyExists'
+ simultaneously.
pushNonFFCurrent::
Advice shown when linkgit:git-push[1] fails due to a
non-fast-forward update to the current branch.
@@ -158,6 +159,9 @@ advice.*::
'matching refs' explicitly (i.e. you used ':', or
specified a refspec that isn't your current branch) and
it resulted in a non-fast-forward error.
+ pushAlreadyExists::
+ Shown when linkgit:git-push[1] rejects an update that
+ does not qualify for fast-forwarding (e.g., a tag.)
statusHints::
Show directions on how to proceed from the current
state in the output of linkgit:git-status[1] and in
diff --git a/advice.c b/advice.c
index 329e077..d287927 100644
--- a/advice.c
+++ b/advice.c
@@ -4,6 +4,7 @@ int advice_push_update_rejected = 1;
int advice_push_non_ff_current = 1;
int advice_push_non_ff_default = 1;
int advice_push_non_ff_matching = 1;
+int advice_push_already_exists = 1;
int advice_status_hints = 1;
int advice_commit_before_merge = 1;
int advice_resolve_conflict = 1;
@@ -18,6 +19,7 @@ static struct {
{ "pushnonffcurrent", &advice_push_non_ff_current },
{ "pushnonffdefault", &advice_push_non_ff_default },
{ "pushnonffmatching", &advice_push_non_ff_matching },
+ { "pushalreadyexists", &advice_push_already_exists },
{ "statushints", &advice_status_hints },
{ "commitbeforemerge", &advice_commit_before_merge },
{ "resolveconflict", &advice_resolve_conflict },
diff --git a/advice.h b/advice.h
index c28ef8a..8bf6356 100644
--- a/advice.h
+++ b/advice.h
@@ -7,6 +7,7 @@ extern int advice_push_update_rejected;
extern int advice_push_non_ff_current;
extern int advice_push_non_ff_default;
extern int advice_push_non_ff_matching;
+extern int advice_push_already_exists;
extern int advice_status_hints;
extern int advice_commit_before_merge;
extern int advice_resolve_conflict;
diff --git a/builtin/push.c b/builtin/push.c
index cf5ecfa..8491e43 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -247,6 +247,8 @@ static void advise_checkout_pull_push(void)
static void advise_ref_already_exists(void)
{
+ if (!advice_push_already_exists || !advice_push_update_rejected)
+ return;
advise(_(message_advice_ref_already_exists));
}
--
1.8.0.1.541.g73be2da
^ permalink raw reply related
* [PATCH 1/2] push: rename config variable for more general use
From: Chris Rorvick @ 2012-12-03 3:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Chris Rorvick, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Jeff King, Felipe Contreras
In-Reply-To: <1354505271-25657-1-git-send-email-chris@rorvick.com>
The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice. Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/config.txt | 2 +-
advice.c | 7 +++++--
advice.h | 2 +-
builtin/push.c | 6 +++---
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9a0544c..92903f2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -140,7 +140,7 @@ advice.*::
can tell Git that you do not need help by setting these to 'false':
+
--
- pushNonFastForward::
+ pushUpdateRejected::
Set this variable to 'false' if you want to disable
'pushNonFFCurrent', 'pushNonFFDefault', and
'pushNonFFMatching' simultaneously.
diff --git a/advice.c b/advice.c
index edfbd4a..329e077 100644
--- a/advice.c
+++ b/advice.c
@@ -1,6 +1,6 @@
#include "cache.h"
-int advice_push_nonfastforward = 1;
+int advice_push_update_rejected = 1;
int advice_push_non_ff_current = 1;
int advice_push_non_ff_default = 1;
int advice_push_non_ff_matching = 1;
@@ -14,7 +14,7 @@ static struct {
const char *name;
int *preference;
} advice_config[] = {
- { "pushnonfastforward", &advice_push_nonfastforward },
+ { "pushupdaterejected", &advice_push_update_rejected },
{ "pushnonffcurrent", &advice_push_non_ff_current },
{ "pushnonffdefault", &advice_push_non_ff_default },
{ "pushnonffmatching", &advice_push_non_ff_matching },
@@ -23,6 +23,9 @@ static struct {
{ "resolveconflict", &advice_resolve_conflict },
{ "implicitidentity", &advice_implicit_identity },
{ "detachedhead", &advice_detached_head },
+
+ /* make this an alias for backward compatibility */
+ { "pushnonfastforward", &advice_push_update_rejected }
};
void advise(const char *advice, ...)
diff --git a/advice.h b/advice.h
index f3cdbbf..c28ef8a 100644
--- a/advice.h
+++ b/advice.h
@@ -3,7 +3,7 @@
#include "git-compat-util.h"
-extern int advice_push_nonfastforward;
+extern int advice_push_update_rejected;
extern int advice_push_non_ff_current;
extern int advice_push_non_ff_default;
extern int advice_push_non_ff_matching;
diff --git a/builtin/push.c b/builtin/push.c
index 83a3cc8..cf5ecfa 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -226,21 +226,21 @@ static const char message_advice_ref_already_exists[] =
static void advise_pull_before_push(void)
{
- if (!advice_push_non_ff_current || !advice_push_nonfastforward)
+ if (!advice_push_non_ff_current || !advice_push_update_rejected)
return;
advise(_(message_advice_pull_before_push));
}
static void advise_use_upstream(void)
{
- if (!advice_push_non_ff_default || !advice_push_nonfastforward)
+ if (!advice_push_non_ff_default || !advice_push_update_rejected)
return;
advise(_(message_advice_use_upstream));
}
static void advise_checkout_pull_push(void)
{
- if (!advice_push_non_ff_matching || !advice_push_nonfastforward)
+ if (!advice_push_non_ff_matching || !advice_push_update_rejected)
return;
advise(_(message_advice_checkout_pull_push));
}
--
1.8.0.1.541.g73be2da
^ permalink raw reply related
* [PATCH 0/2] push: honor advice.* configuration
From: Chris Rorvick @ 2012-12-03 3:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Chris Rorvick, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Jeff King, Felipe Contreras
In-Reply-To: <7vmwxwka6f.fsf@alter.siamese.dyndns.org>
Added a new config option to turn off the already-exists advice. We
also want to observe the 'pushNonFastForward' setting, but the name of
this config is too narrow after this addition. Renamed to have broader
scope while retaining the old name as an alias for backward-
compatibility.
Chris Rorvick (2):
push: rename config variable for more general use
push: allow already-exists advice to be disabled
Documentation/config.txt | 10 +++++++---
advice.c | 9 +++++++--
advice.h | 3 ++-
builtin/push.c | 8 +++++---
4 files changed, 21 insertions(+), 9 deletions(-)
--
1.8.0.1.541.g73be2da
^ permalink raw reply
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Felipe Contreras @ 2012-12-02 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Łukasz Stelmach
In-Reply-To: <7vlidhmc5i.fsf@alter.siamese.dyndns.org>
On Sat, Dec 1, 2012 at 8:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> We _may_ want to unify these two "hidestuff" into a list of patterns
> that hides any ref that match one of the patterns in the list, e.g.
>
> set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
>
> may hide all tags, all remote-tracking branches and local branches
> that have a slash in their names.
And hide the rest. Currently gitk shows all other refs (e.g. refs/hg/*).
--
Felipe Contreras
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox