Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
On Sat, Dec 1, 2012 at 11:06 PM, Torsten Bögershausen tbo...@web.de wrote: On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- t/t4014-format-patch.sh | 145 1 file changed, 145 insertions(+) + echo -n subject | append_signoff actual echo -n is not portable, and we use printf everywhere. I found one echo -n in line 996. Can we squeeze that in, before going to next? I got it. I'll squash it into the next series. -Brandon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: does a successful 'git gc' imply 'git fsck'
On Sun, Dec 2, 2012 at 9:58 AM, Shawn Pearce spea...@spearce.org wrote: On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty sitar...@gmail.com wrote: Background: I have a situation where I have to fix up a few hundred repos in terms of 'git gc' (the auto gc seems to have failed in many cases; they have far more than 6700 loose objects). I also found some corrupted objects in some cases that prevent the gc from completing. I am running git gc followed by git fsck. The majority of the repos I have worked through so far appear to be fine, but in the larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times longer than the 'gc'. 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. Not really. For example fsck verifies that every blob when decompressed and fully inflated matches its SHA-1. gc only checks OK that makes sense. After I posted I happened to check using strace and kinda guessed this from what I saw, but it's nice to have confirmation. connectivity of the commit and tree graph by making sure every object was accounted for. But when creating the output pack it only verifies a CRC-32 was correct when copying the bits from the source to the destination, it does not verify that the data decompresses and matches the SHA-1 it should match. So it depends on what level of check you need to feel safe. Yup; thanks. All the repos my internal client manages are mirrored in multiple places, and they set (or were at least told to set, heh!) receive.fsckObjects so the lesser check is fine in most cases. -- Sitaram -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
Michael Haggerty mhag...@alum.mit.edu writes: Nevertheless, the old code was even *more* broken because it added a /pre regardless of whether the separator line had been seen,... OK. I'll rewrite the tail-end of the original log message to read: The old code would have created invalid output when there was no body, emitting a closing /pre without a blank line nor an opening pre after the header. The new code simply returns in this situation without doing harm (even though either would not make much sense in the context of imap-send that is meant to send out patches). and squash this in. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: does a successful 'git gc' imply 'git fsck'
Sitaram Chamarty sitar...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
Jeff King p...@peff.net writes: Since this can be thought of as act more like system(3), I wondered whether the signal-ignore logic should be moved into run-command, or even used by default for blocking calls to run_command (which are basically our version of system(3)). But it is detrimental in the common case that the child is not taking control of the terminal, and is just an implementation detail (e.g., we call git update-ref behind the scenes, but the user does not know or care). If they hit ^C during such a run and we are ignoring SIGINT, then either: 1. we will notice the child died by signal and report an error in the subprocess rather than just dying; the end result is similar, but the error is unnecessarily confusing 2. we do not bother to check the child's return code (because we do not care whether the child succeeded or not, like a gc --auto); we end up totally ignoring the user's request to abort the operation So I do not think we care about this behavior except for launching the editor. And the signal-propagation behavior of 5/5 is really so weirdly editor-specific (because it is about behaving well whether the child blocks signals or not). Nicely explained. Very much appreciated. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
On 12/02/2012 10:25 AM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Nevertheless, the old code was even *more* broken because it added a /pre regardless of whether the separator line had been seen,... OK. I'll rewrite the tail-end of the original log message to read: The old code would have created invalid output when there was no body, emitting a closing /pre without a blank line nor an opening pre after the header. The new code simply returns in this situation without doing harm (even though either would not make much sense in the context of imap-send that is meant to send out patches). and squash this in. ACK. Thanks. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
Erik Faye-Lund kusmab...@gmail.com writes:
@@ -1538,13 +1563,7 @@ static sig_handler_t timer_fn = SIG_DFL;
static unsigned __stdcall ticktack(void *dummy)
{
while (WaitForSingleObject(timer_event, timer_interval) ==
WAIT_TIMEOUT) {
- if (timer_fn == SIG_DFL) {
- if (isatty(STDERR_FILENO))
- fputs(Alarm clock\n, stderr);
- exit(128 + SIGALRM);
- }
- if (timer_fn != SIG_IGN)
- timer_fn(SIGALRM);
+ mingw_raise(SIGALRM);
if (one_shot)
break;
}
This hunk seems to have been based on a slightly newer codebase than
what I have, and I had to wiggle the patch a bit to make the series
apply. Please double check the result when I push out the 'pu'
branch.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/8] push: add advice for rejected tag reference
Chris Rorvick ch...@rorvick.com writes:
static void advise_pull_before_push(void)
{
if (!advice_push_non_ff_current || !advice_push_nonfastforward)
@@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
advise(_(message_advice_checkout_pull_push));
}
+static void advise_ref_already_exists(void)
+{
+ advise(_(message_advice_ref_already_exists));
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport,
int flags)
advise_use_upstream();
else
advise_checkout_pull_push();
+ } else if (reject_reasons REJECT_ALREADY_EXISTS) {
+ advise_ref_already_exists();
}
The existing advise_* functions that are called from this function
honor the advice.* configuration, and advise_ref_already_exists()
would want to follow suit here (it is OK to do so as a follow-up
patch without further rerolling the entire series).
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t9402: sed -i is not portable
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 tbo...@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
}
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 21
+ 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
21
}
#
@@ -70,17 +69,17 @@ check_diff() {
cvs /dev/null 21
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 21 || {
-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
[RFC] Add basic syntax check on shell scripts
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 tbo...@web.de --- We add 1 second test execution time Is this a useful idea at all? t/t9-syntax-check.sh | 28 1 file changed, 28 insertions(+) create mode 100755 t/t9-syntax-check.sh diff --git a/t/t9-syntax-check.sh b/t/t9-syntax-check.sh new file mode 100755 index 000..c4a9289 --- /dev/null +++ b/t/t9-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 21 || : ) + test_cmp expected actual + rm expected actual +' + +test_expect_success 'No sed -i' ' + expected + (grep -n ^[ ]*sed[ ][ ]*\-i ../*.sh ../../git-* actual 21 || : ) + test_cmp expected actual + rm expected actual +' + +test_expect_success 'No echo -n' ' + expected + (grep -n ^[ ]*echo[ ][ ]*\-n ../*.sh ../../git-* actual 21 || : ) + test_cmp expected actual + rm expected actual +' +test_done -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Add basic syntax check on shell scripts
On 12/02/2012 02:17 PM, Torsten Bögershausen wrote:
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 tbo...@web.de
---
We add 1 second test execution time
Is this a useful idea at all?
FWIW, I think such an idea is useful (and also easy to implement,
so another +1 from me).
t/t9-syntax-check.sh | 28
1 file changed, 28 insertions(+)
create mode 100755 t/t9-syntax-check.sh
diff --git a/t/t9-syntax-check.sh b/t/t9-syntax-check.sh
new file mode 100755
index 000..c4a9289
--- /dev/null
+++ b/t/t9-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 21 || : )
Here I'd simply use:
! grep -n ^declare[ ][ ]* ../*.sh ../../*.sh
And similarly for the tests below.
In addition, the globs above still miss some files ('perf/perf-lib.sh'
and 'valgrind/analyze.sh', for example); so we might want to improve
it, using, say, git ls-files (or find(1), in case the test is to be
run also from distribution tarballs).
HTH,
Stefano
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
Before I get into the details, I'd like to point out that I actually understand the purpose of `submodule init` now ;). To avoid further confusion, my current one-line command summaries would be: init: mark a submodule as active for future submodule operation deinit: mark a submodule as inactive for future submodule operation sync: update remote.name.origin in submodules to reflect changes in .gitmodules or the superproject's remote URL. I don't think we disagree on that, we just don't agree on how to implement it. Currently, Git uses submodule.name.url in the superproject's local configuration as a marker for submodule activation. This is not (as far as I know) discussed in the docs, which is why I initially missunderstood the purpose of `init` to be “setup the superproject's local configuration so we don't have to keep resolving the submodules URL relative to the superproject's upstream URL”. With the proposed `deinit` docs, this role for the submodule.name.url is mentioned, but not in a place where casual users will be able to easily connect it to the purpose of `init`. I floated using submodule.name.update (with 'none' for inactive and anything else for active) as an alternative marker: On Sat, Dec 01, 2012 at 01:16:43PM -0500, W. Trevor King wrote: On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote: Am 01.12.2012 18:49, schrieb W. Trevor King: I think removing `init` will cause some compatibility issues anyway, so I was re-imaging how you do it. I don't think update='none' and don't populate my submodule are distinct ideas, while a locally configured url=somwhere and please populate my submodule are (with the blank-url case defaulting to the superproject itself). Why would we want to remove init? It still has to copy the url setting (and it would be a compatibility nightmare if we would change that, imagine different git versions used on the same work tree). In my init-less rewrite, it doesn't have to copy the url setting. People using older versions of Git would need to run `init` using their old version. Having the url defined in .git/config won't break my init-less submodule commands, it just means that the value in .gitmodules will be masked. but that doesn't seem to be going over very well. Junio may have been weighing in obliquely with: On Sat, Dec 01, 2012 at 06:00:06PM -0800, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: [snip v1 deinit commit message] I fully agree with your analysis on the reason why the url element is special and has to be copied to $GIT_DIR/config, but when you deinit (or uninit) a submodule to say you are no longer interested in it and do not want it populated in the context of the superproject, I am not sure if removing only submodule.$name.url (so that when you later decide to init it again, you will keep the values for submodule.$name.update and other things from the previous life) is the sane thing to do, or it is better to remove submodule.$name.* altogether as if an earlier init has never happened. Would it be worth analyzing the pros-and-cons here? Let me take another stab at presenting my argument in favor of a different activity marker. Proposal: Add a new boolean option, submodule.name.active, to explicitly mark submodules as active (with “active” defined as “to be returned by module_list()”). Strip down `init` (and the --init part of `update --init`) to just setting this option to true. `deinit` only sets this option to false (but a `deinit --clean` could remove the whole submodule.name section). With this in place, extracting URLs for submodule operations be similar to the extraction of other variables (.gitmodules defaults with superproject-local .git/config overrides). This also makes it easier to track maintenance updates in .gitmodules-defined URLs, because you aren't forced to bake overrides into your local .git/config The upgrade path from earlier versions of Git is easy: if submodule.name.active is unset, use the presence of submodule.name.url to determine its initial value. In the case where you check out an earlier superproject commit which is missing a particular submodule (or remove a submodule without deinit-ing), the presense of an active setting in .git/config should not cause an error, which they currently seem to: On Sat, Dec 01, 2012 at 11:37:14AM -0500, W. Trevor King wrote: On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote: Am 01.12.2012 00:52, schrieb Phil Hord: If I never 'submodule init' a submodule, it does not get visited by 'git submodule foreach', among others. I think some people use this behavior explicitly. On the other hand, I've also notice that a submodule which I have removed does not get de-inited later one. It causes my 'git submodule foreach' to emit errors. :-( I'm currently hacking on git submodule deinit which removes the 'url' setting from git/config. This
Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
Am 30.11.2012 04:27, schrieb W. Trevor King: On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote: On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. I haven't dealt with any gitlink merges, but I think that supporting easy gitlink merges is orthogonal to this --remote option. For simple cases like autocommitted submodule floats, one of the conflicting gitlinks will be an ancestor of the other, so it should be easy to automate that merge. Submodule merges where one submodule commit is the ancestor of the other are already resolved automatically in recent git. So Phil's example will just work as long as only fast-forward merges are needed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: add 'deinit' command
Am 02.12.2012 03:00, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: With git submodule init the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to git submodule update. But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the submodule.$name.url setting from .git/config himself). Help those users by providing a 'deinit' command. This removes the url setting from .git/config either for the given submodule(s) or for all those which have been initialized if none were given. Complain only when for a submodule given on the command line the url setting can't be found in .git/config. Add tests and link the man pages of git submodule deinit and git rm to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Signed-off-by: Jens Lehmann jens.lehm...@web.de --- I fully agree with your analysis on the reason why the url element is special and has to be copied to $GIT_DIR/config, but when you deinit (or uninit) a submodule to say you are no longer interested in it and do not want it populated in the context of the superproject, I am not sure if removing only submodule.$name.url (so that when you later decide to init it again, you will keep the values for submodule.$name.update and other things from the previous life) is the sane thing to do, or it is better to remove submodule.$name.* altogether as if an earlier init has never happened. Would it be worth analyzing the pros-and-cons here? Sure. I was worried about throwing away other settings the user might have set in the submodule.$name section and the first reflex was to protect them. But thinking about that again I noticed we are already throwing away a possibly user customized url setting, so we already remove a possibly customized setting. 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. Opinions by other submodule users? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
Am 02.12.2012 20:09, schrieb W. Trevor King: Before I get into the details, I'd like to point out that I actually understand the purpose of `submodule init` now ;). To avoid further confusion, my current one-line command summaries would be: init: mark a submodule as active for future submodule operation deinit: mark a submodule as inactive for future submodule operation sync: update remote.name.origin in submodules to reflect changes in .gitmodules or the superproject's remote URL. I don't think we disagree on that, we just don't agree on how to implement it. Nope, it is already implemented and you are arguing to change the current implementation. To quote from another mail: 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote.c: fix grammatical error in comment
The sentence originally began Note that ... and was changed to NOTE: ... This change should have been made at the same time. Signed-off-by: Chris Rorvick ch...@rorvick.com --- This applies to the current cr/push-force-tag-update branch. It can probably just be folded into the last commit. Thanks, Chris remote.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/remote.c b/remote.c index 6309a87..aa6b719 100644 --- a/remote.c +++ b/remote.c @@ -1337,8 +1337,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, * * NOTE: We must actually have the old object in * order to overwrite it in the remote reference, -* and that the new object must be commit-ish. -* These are implied by (b) and (c) respectively. +* and the new object must be commit-ish. These are +* implied by (b) and (c) respectively. * * (4) it is forced using the +A:B notation, or by * passing the --force argument -- 1.8.0.1.541.g73be2da -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King wk...@tremily.us To: Jens Lehmann jens.lehm...@web.de, Junio C Hamano gits...@pobox.com Cc: Phil Hord phil.h...@gmail.com, Git git@vger.kernel.org, Heiko Voigt hvo...@hvoigt.net, Jeff King p...@peff.net, Shawn Pearce spea...@spearce.org, Nahor nahor.j+gm...@gmail.com Bcc: Subject: Re: [RFC] remove/deprecate 'submodule init' and 'sync' Reply-To: In-Reply-To: 50bbba29.2000...@web.de 50bbb22a.7050...@web.de 20121202190929.gg9...@odin.tremily.us OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8; url=http://tremily.us/pubkey.txt On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote: Am 02.12.2012 20:09, schrieb W. Trevor King: Before I get into the details, I'd like to point out that I actually understand the purpose of `submodule init` now ;). To avoid further confusion, my current one-line command summaries would be: init: mark a submodule as active for future submodule operation deinit: mark a submodule as inactive for future submodule operation sync: update remote.name.origin in submodules to reflect changes in .gitmodules or the superproject's remote URL. I don't think we disagree on that, we just don't agree on how to implement it. Nope, it is already implemented and you are arguing to change the current implementation. Agreed. To quote from another mail: 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 example: On Sun, Dec 02, 2012 at 08:55:22PM +0100, Jens Lehmann wrote: Sure. I was worried about throwing away other settings the user might have set in the submodule.$name section and the first reflex was to protect them. But thinking about that again I noticed we are already throwing away a possibly user customized url setting, so we already remove a possibly customized setting. With submodule.name.active, there's nothing customized that you'd have to nuke on deinit (except 'active' iteself, which the user is explicitly asking for). 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add a checkbox to control the visibility of tags
W dniu 02.12.2012 03:16, Junio C Hamano pisze:
Łukasz Stelmach stl...@poczta.fm writes:
Enable hiding of tags displayed in the tree as yellow labels.
If a repository is used together with a system like Gerrit
there may be quite a lot of tags used to control building
and there may be hardly any place left for commit subjects.
Signed-off-by: Łukasz Stelmach stl...@poczta.fm
---
Paul, this patch is not done against your tree (does not have gitk
at the top-level),
I did it on the master from github. Should I rebase it onto something else?
but other than that, the change mimics the way
existing hideremoes is implemented and looks reasonable to me.
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.
But that is an independent change that can come later.
This would make much more sense with gitk being abel to read a
per-repository configuration file, say from [file join $gitdir k] and
then save it there (but only if the file exists). I will send a separate
patch in a moment.
gitk-git/gitk | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..274b46b 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1754,7 +1754,7 @@ proc readrefs {} {
global tagids idtags headids idheads tagobjid
global otherrefids idotherrefs mainhead mainheadid
global selecthead selectheadid
-global hideremotes
+global hideremotes hidetags
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
@@ -1776,6 +1776,7 @@ proc readrefs {} {
set headids($name) $id
lappend idheads($id) $name
} elseif {[string match tags/* $name]} {
+if {$hidetags} continue
# this lets refs/tags/foo^{} overwrite refs/tags/foo,
# which is what we want since the former is the commit ID
set name [string range $name 5 end]
@@ -2702,7 +2703,7 @@ proc savestuff {w} {
global cmitmode wrapcomment datetimeformat limitdiffs
global colors uicolor bgcolor fgcolor diffcolors diffcontext
selectbgcolor
global autoselect autosellen extdifftool perfile_attrs markbgcolor
use_ttk
-global hideremotes want_ttk
+global hideremotes hidetags want_ttk
if {$stuffsaved} return
if {![winfo viewable .]} return
@@ -2725,6 +2726,7 @@ proc savestuff {w} {
puts $f [list set autosellen $autosellen]
puts $f [list set showneartags $showneartags]
puts $f [list set hideremotes $hideremotes]
+puts $f [list set hidetags $hidetags]
puts $f [list set showlocalchanges $showlocalchanges]
puts $f [list set datetimeformat $datetimeformat]
puts $f [list set limitdiffs $limitdiffs]
@@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
proc prefspage_general {notebook} {
global NS maxwidth maxgraphpct showneartags showlocalchanges
global tabstop limitdiffs autoselect autosellen extdifftool
perfile_attrs
-global hideremotes want_ttk have_ttk
+global hideremotes hidetags want_ttk have_ttk
set page [create_prefs_page $notebook.general]
@@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
${NS}::checkbutton $page.hideremotes -text [mc Hide remote refs] \
-variable hideremotes
grid x $page.hideremotes -sticky w
+${NS}::checkbutton $page.hidetags -text [mc Hide tag labels] \
+-variable hidetags
+grid x $page.hidetags -sticky w
${NS}::label $page.ddisp -text [mc Diff display options]
grid $page.ddisp - -sticky w -pady 10
@@ -10988,7 +10993,7 @@ proc doprefs {} {
global oldprefs prefstop showneartags showlocalchanges
global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor
markbgcolor
global tabstop limitdiffs autoselect autosellen extdifftool
perfile_attrs
-global hideremotes want_ttk have_ttk
+global hideremotes hidetags want_ttk have_ttk
set top .gitkprefs
set prefstop $top
@@ -10997,7 +11002,7 @@ proc doprefs {} {
return
}
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
- limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
+ limitdiffs tabstop perfile_attrs hideremotes hidetags
want_ttk} {
set oldprefs($v) [set $v]
}
ttk_toplevel $top
@@ -7,7 +11122,7 @@ proc prefscan {} {
global oldprefs prefstop
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
- limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
+ limitdiffs tabstop perfile_attrs hideremotes hidetags
want_ttk} {
global $v
set $v $oldprefs($v)
}
@@
[PATCH] gitk: read and write a repository specific configuration file
Enable gitk read and write repository specific configuration
file: .git/k if the file exists. To make gitk use the local
file simply create one, e.g. with the touch(1) command.
This is very useful if one uses different views for different
repositories. Now there is no need to store all of them in
~/.gitk and make the views list needlesly long.
Signed-off-by: Łukasz Stelmach stl...@poczta.fm
---
gitk-git/gitk | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..60cf4cd 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2696,7 +2696,7 @@ proc doprogupdate {} {
proc savestuff {w} {
global canv canv2 canv3 mainfont textfont uifont tabstop
-global stuffsaved findmergefiles maxgraphpct
+global stuffsaved findmergefiles maxgraphpct gitdir
global maxwidth showneartags showlocalchanges
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
@@ -2707,10 +2707,12 @@ proc savestuff {w} {
if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
- if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
- set f [open ~/.gitk-new w]
+ set fn [expr [file exists [file join $gitdir k]] ? \
+ {[file join $gitdir k-new]} : {~/.gitk-new}]
+ if {[file exists $fn]} {file delete -force $fn}
+ set f [open $fn w]
if {$::tcl_platform(platform) eq {windows}} {
- file attributes ~/.gitk-new -hidden true
+ catch {file attributes ~/.gitk-new -hidden true}
}
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
@@ -2762,7 +2764,7 @@ proc savestuff {w} {
}
puts $f }
close $f
- file rename -force ~/.gitk-new ~/.gitk
+ file rename -force $fn [regsub {\-new$} $fn {}]
}
set stuffsaved 1
}
@@ -11663,7 +11665,14 @@ namespace import ::msgcat::mc
## And eventually load the actual message catalog
::msgcat::mcload $gitk_msgsdir
+# check that we can find a .git directory somewhere...
+if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
+show_error {} . [mc Cannot find a git repository here.]
+exit 1
+}
+
catch {source ~/.gitk}
+catch {source [file join $gitdir k]}
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
@@ -11680,12 +11689,6 @@ setui $uicolor
setoptions
-# check that we can find a .git directory somewhere...
-if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
-show_error {} . [mc Cannot find a git repository here.]
-exit 1
-}
-
set selecthead {}
set selectheadid {}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add a checkbox to control the visibility of tags
On Sat, Dec 1, 2012 at 8:16 PM, Junio C Hamano gits...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] push: honor advice.* configuration
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] push: rename config variable for more general use
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 ch...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] push: allow already-exists advice to be disabled
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 ch...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
Thanks Thomas and Michael! 2012/11/30 Thomas Rast tr...@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
[PATCH] l10n: de.po: translate 22 new messages
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.thie...@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
[PATCH] status: respect advice.statusHints for ahead/behind advice
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 p...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
thomas sabo bracelet is absolutely some sort of acclaimed type
What on earth is so extraordinary and unconventional on the subject of Thomas Sabo appeal bracelet asshole is usually that you have got the choice to select and opt for its possess appeal for being hooked up to your bracelet of your decision. towards your lovers, you may also opt for the best gift with the Thomas Sabo Charm Club for nearly all people, which include your loved ones and good friends. Undoubtedly you might appreciate the array made available by Sabo and so will your loved ones and good friends. Sabo is very well regarded for its assortment of attraction, or [url=http://www.thomassabobraceletsshop.co.uk/]thomas sabo sale[/url]. Allow me to share with you about that exclusive matter about Thomas Sabo Bracelets Australia. What on earth is so extraordinary and unconventional on the subject of Thomas Sabo appeal bracelet asshole is usually that you have got the choice to select and opt for its possess appeal for being hooked up to your bracelet of your decision.. http://www.thomassabobraceletsshop.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/thomas-sabo-bracelet-is-absolutely-some-sort-of-acclaimed-type-tp7572551.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
you snapshot which the magnificent pandora bracelet charms
You’ll be able to pick from any variety of this sort of patterns at different [url=http://www.pandoracanadacharm.org/]pandora charms on sale[/url] retailers within your location. Below, you’ll be surprised to discover a big selection of allure beads to pick from. Regardless of whether you want gold or silver, you’re going to get lots of beads created from these treasured metals. You’ll be able to even pick from beads created of blend of gold and silver. Apart from these, enamel can be being used to produce this sort of beads. Should you not able to locate a Pandora retailer within your location, you’ll be able to decide for checking out a web-based retailer to examine out different alternatives.. http://www.pandoracanadacharm.org/ -- View this message in context: http://git.661346.n2.nabble.com/you-snapshot-which-the-magnificent-pandora-bracelet-charms-tp7572552.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anyone can go with a perles swarovski alternatively
Around, forty brand new shops ought to be in position through 2001. Swarovski offers regarding 9200 workers, and contains continued to be the for yourself possessed loved ones company because it's beginning. I've noticed a few rumors that they're thinking about heading public, however that's just about all they're, simply rumors.[url=http://www.bijouxswarovskiboutique.com/]swarovski[/url] was founded in 1895 by Daniel Swarovski I. It has since developed into an international entity with numerous subsidiaries and is currently in the process of reorganizing its North American activities, as well as preparing to increase its presence on the Internet. In addition, Swarovski is also adding their own retail stores throughout the United States and Canada. http://www.bijouxswarovskiboutique.com/ -- View this message in context: http://git.661346.n2.nabble.com/Anyone-can-go-with-a-perles-swarovski-alternatively-tp7572553.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: add 'deinit' command
Jens Lehmann jens.lehm...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
