> so it's a sever side hook that it's forced down to all developers.
How does that work?
/me is just curious
--
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
There appears to be a bug in the bash completion for git-branch when
attempting to complete the remote ref argument for --set-upstream-to=
When:
$ git branch --set-upstream-to=origin/mast
I would expect it to complete to:
$ git branch --set-upstream-to=origin/master
However, the completion for
The different index versions have different sha-1 checksums. Those
checksums are checked in t1700, which makes it fail when run with index
v4. Fix it.
Signed-off-by: Thomas Gummerer
---
t/t1700-split-index.sh | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/
This test is special for several reasons:
It ends with a "true" statement, which should be a no-op.
It is not because the &&-chain is broken right before it.
Also, looking at what the test intended to test according to
7f578c5 (git-svn: --follow-parent now works on sub-directories of larger
branch
All of these cases are moderate since they would most probably not
lead to missed failing tests: Either they would fail otherwise,
or fail a rm in test_when_finished only.
Signed-off-by: Michael J Gruber
---
t/t2026-prune-linked-checkouts.sh | 4 ++--
t/t9158-git-svn-mergeinfo.sh | 4 ++--
Jeff King venit, vidit, dixit 20.03.2015 11:04:
> This is a cleanup of the &&-chain lint I posted earlier:
>
> http://thread.gmane.org/gmane.comp.version-control.git/265613/focus=265859
>
> I don't know who came up with the idea for it originally, but the
> concept certainly was floating in the
Hi
I'm doing some splitting of a large patch and I noticed that when I do
$ git apply --reject large_patch.diff
and it generates a lot of .rej files, it seems to be touching the files that produced the .rej output, even if nothing
in that particular file was actually updated.
Not a major i
On Mon, Mar 16, 2015 at 11:53:08AM -0700, Junio C Hamano wrote:
> Because the history is not linear in Git, bisection works by
> shrinking a subgraph of the history DAG that contains "yet to be
> tested, suspected to have introduced a badness" commits. The
> subgraph is defined as anything reachab
Signed-off-by: Thomas Schneider
---
dblatex does print some warnings, but they seem to be irrelevant.
Besides, first patch I submit to git or even to any project using a
mailing list … let’s hope I did everything right :)
Documentation/Makefile | 9 -
1 file changed, 8 insertions(+), 1 d
Hello,
I am trying to setup my git ignore (resp. .git/info/exclude) so that I exclude
all directories and files except the content of directories that I
specifically include (incl. anything within them recursively).
I set the .git/info/exclude with the following content:
# Exclude ever
On Fri, Mar 20, 2015 at 06:04:30AM -0400, Jeff King wrote:
> It's a lot of patches, and a few of them are long. I tried to group
> them by functionality rather than file (though as you can see, some of
> the tests were unique enough snowflakes that it made sense to discuss
> their issues separatel
This shortens the code and fixes some &&-chaining.
Signed-off-by: Jeff King
---
t/t1301-shared-repo.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index 7eecfb8..ac10875 100755
--- a/t/t1301-shared-repo
One of these breakages is in setup, but one is more severe
and may miss a real test failure. These are pulled out from
the rest, though, because we also clean up a few other
anachronisms. The most interesting is the use of this
here-doc construct:
(cat >... <
---
t/t7201-co.sh | 19 ++--
The ":" noop command always returns true, so it is fine to
include these lines in an &&-chain (and it appeases
--chain-lint).
Signed-off-by: Jeff King
---
t/t0005-signals.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 5c57
This test uses single quotes inside the single-quoted test
snippet, which effectively makes the contents unquoted.
Since they don't need quoted anyway, this isn't a problem,
but let's switch them to double-quotes to make it more
obviously correct.
Signed-off-by: Jeff King
---
t/t7004-tag.sh | 2
The confirmation tests in t9001 all save the value of
sendemail.confirm, do something to it, then restore it at
the end, in a way that breaks the &&-chain (they are not
wrong, because they save the $? value, but it fools
--chain-lint).
Instead, they can all use test_when_finished, and we can
even
Some of the symlink tests check an either-or case using the
"||". This is not wrong, but fools --chain-lint into
thinking the &&-chain is broken (in fact, there is no &&
chain here).
We can solve this by wrapping the "||" inside a {} block.
This is a bit more verbose, but this construct is rare, a
This script misses a trivial &&-chain in one of its tests,
but it also has a weird reverse: it includes an &&-chain
outside of any test_expect block! This "cat" should never
fail, but if it did, we would not notice, as it would cause
us to skip the follow-on test entirely (which does not
appear int
These say roughly the same thing as the hand-rolled
messages. We do lose the "merge did not complete" debug
message, but merge and write-tree are prefectly capable of
writing useful error messages when they fail.
Signed-off-by: Jeff King
---
t/t6034-merge-rename-nocruft.sh | 66 -
This use of "||" fools --chain-lint into thinking the
&&-chain is broken (and indeed, it is somewhat broken; a
failure of update-index in these tests would show the patch
file, even if we never got to the part of the test where we
fed the patch to git-apply).
The extra blocks were there to include
We can get rid of a lot of hand-rolled error messages by
using test_must_fail and test_expect_code. The existing code
was careful to use "|| return 1" when breaking the
&&-chain, but it did fool --chain-lint; the new code is more
idiomatic.
We also add some uses of test_when_finished, which is les
We can use test_must_fail and test_path_* to avoid some
hand-rolled if statements. This makes the code shorter, and
makes it more obvious when we are breaking the &&-chain.
Signed-off-by: Jeff King
---
t/t4117-apply-reject.sh | 66 -
1 file changed
This test contains a lot of hand-rolled messages to show
when the test fails. We can omit most of these by using
"verbose" and "test_must_fail". A few of them are for
update-index, but we can assume it produces reasonable error
messages when it fails.
Signed-off-by: Jeff King
---
t/t0020-crlf.sh
If we are expecting a command to produce a particular exit
code, we can use test_expect_code. However, some cases are
more complicated, and want to accept one of a range of exit
codes. For these, we end up with something like:
cmd;
case "$?" in
...
That unfortunately breaks the &&-chain and
The ":" is not a comment marker, but rather a noop command.
Using it as a comment like:
: do something
cmd1 &&
: something else
cmd2
breaks the &&-chain, and we would fail to notice if "cmd1"
failed in this instance. We can just use regular "#"
comments instead.
Signed-off-by: Jeff King
As with the earlier patch to fix "trivial" &&-chain
breakage, these missing "&&" operators are not a serious
problem (e.g., we do not expect "echo" to fail).
Ironically, however, inserting them shows that some of the
commands _do_ fail. Specifically, some of the tests start by
making sure we are a
This makes our output in the event of a failure slightly
nicer, and it means that we do not break the &&-chain.
Signed-off-by: Jeff King
---
t/t0040-parse-options.sh | 12 +++--
t/t4035-diff-quiet.sh| 66 +++-
t/t4053-diff-no-index.sh | 4 +--
Some tests run diff or grep to produce an output, and then
compare the output to an expected value. We know the exit
code we expect these processes to have (e.g., grep yields 0
if it produced output and 1 otherwise), so it would not make
the test wrong to look for it. But the difference between
the
Many tests have an initial setup step that might fail based
on whether earlier tests in the script have succeeded or
not. Using a trick like "|| true" breaks the &&-chain,
missing earlier failures (and fooling --chain-lint).
We can use test_might_fail in some cases, which is correct
and makes the
These test scripts likely predate test_must_fail, and can be
made simpler by using it (in addition to making them pass
--chain-lint).
The case in t6036 loses some verbosity in the failure case,
but it is so tied to a specific failure mode that it is not
worth keeping around (and the outcome of the
Many tests that predate the "verbose" helper function use a
pattern like:
test ... || {
echo ...
false
}
to give more verbose output. Using the helper, we can do
this with a single line, and avoid a || which interacts
badly with &&-chaining (besides fooling --chain-lint, w
Some tests call test_cmp, and if it fails show the actual
output generated. This is mostly pointless, as test_cmp will
already show a diff between the expected and actual output.
It also fools --chain-lint by putting an "||" in the middle
of the chain, so we'd rather not use this construct.
Note t
These are tests which are missing a link in their &&-chain,
but during a setup phase. We may fail to notice failure in
commands that build the test environment, but these are
typically not expected to fail at all (but it's still good
to double-check that our test environment is what we
expect).
Si
These are tests which are missing a link in their &&-chain,
in a location which causes a significant portion of the test
to be missed (e.g., the test effectively does nothing, or
consists of a long string of actions and output comparisons,
and we throw away the exit code of at least one part of the
These are tests which are missing a link in their &&-chain,
but in a way that probably does not effect the outcome of
the test. Most of these are of the form:
some_cmd >actual
test_cmp expect actual
The main point of the test is to verify the output, and a
failure in some_cmd would probably b
It's easy to miss an "&&"-chain in a test script, like:
test_expect_success 'check something important' '
cmd1 &&
cmd2
cmd3
'
The test harness will notice if cmd3 fails, but a failure of
cmd1 or cmd2 will go unnoticed, as their exit status is lost
after cmd3 runs.
The
This is a cleanup of the &&-chain lint I posted earlier:
http://thread.gmane.org/gmane.comp.version-control.git/265613/focus=265859
I don't know who came up with the idea for it originally, but the
concept certainly was floating in the back of my mind from Jonathan's
earlier version that is ref
That all seems quite reasonable, and is what I would expect to happen.
However at the moment, if I create a branch from master and edit one
line in one file,
with no other changes on the remote, it takes me over an hour to push
the new branch.
On 19 March 2015 at 18:36, Junio C Hamano wrote:
> G
David,
Thanks for the suggestions, I left out the most unfortunate part of the problem
I am facing, the one that add this hook is the git admin, aka our release
engineer, so it's a sever side hook that it's forced down to all developers. I
sure will try to persuade them from a different perspec
Dear Authors,
We would like to invite you to organize a Special Session or a Workshop
in CSCC 2015: Circuits, Systems, Communications and Computers
www.cscc.co in conjuction with several parallel conferences of INASE.org
So far we have 39 Special Sessions/ Workshops. You can propose your own Spe
On Wed, Mar 18, 2015 at 6:47 PM, Michael Haggerty wrote:
> On 03/18/2015 07:27 PM, Eric Sunshine wrote:
>> On Tuesday, March 17, 2015, Michael Haggerty wrote:
>>> Implement wrappers for strtol() and strtoul() that are safer and more
>>> convenient to use.
>>> + * The lowest 6 bits of flags hold t
On Freitag, 20. März 2015 02:15:31 CEST, Mike Hommey wrote:
On Fri, Mar 20, 2015 at 12:03:43AM +0100, Thomas Braun wrote:
Hi,
the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.
is it expected that there is no corresponding
On 19/03/15 21:58, brian m. carlson wrote:
On Thu, Mar 19, 2015 at 12:28:09PM +, Sam Bishop wrote:
When using the git-p4.py script, I found that if I used a client spec when
cloning out a perforce repository, and then using a git-p4.py rebase, that
the rebase command would be using the curre
On Fri, Mar 20, 2015 at 1:10 AM, Jeff King wrote:
> On Thu, Mar 19, 2015 at 10:25:32PM -0400, Jeff King wrote:
>> > diff --git a/t/test-lib.sh b/t/test-lib.sh
>> > index c096778..02a03d5 100644
>> > --- a/t/test-lib.sh
>> > +++ b/t/test-lib.sh
>> > @@ -524,6 +524,21 @@ test_eval_ () {
>> > test_r
On Thu, Mar 19, 2015 at 09:07:28PM -0700, Ray Xie wrote:
> So today I had a shocking moment while I was doing my cherry-pick,
> after I performed all the pre-checkin duties (the usual build the
> code, run the test to make sure the cherry-pick infact works), I found
> out that my original commit wa
Michael Haggerty writes:
> The lock conflict scenario is the only one that really worries me.
Actually, I'd feel worried if this were on the receive-pack side, as
it is entirely valid that two or more people make uncoordinated push
into a single meeting point, but much less for something like
"f
101 - 146 of 146 matches
Mail list logo
