bbing arguments in the same range.
That's not simpler to explain than your current proposal.
So I like the relative simplicity of this approach. Here is a bit of
documentation.
--- 8< ---
Subject: [PATCH] document --exclude option
Signed-off-by: Johannes Sixt
---
Documentation/rev-list-o
Am 9/2/2013 11:30, schrieb Duy Nguyen:
> On Mon, Sep 02, 2013 at 08:42:18AM +0200, Johannes Sixt wrote:
>> Am 9/1/2013 4:08, schrieb Nguyễn Thái Ngọc Duy:
>>> git-add--interactive.perl rejects arguments with colons in 21e9757
>>> (Hack git-add--interactive to make it
Am 9/1/2013 4:08, schrieb Nguyễn Thái Ngọc Duy:
> git-add--interactive.perl rejects arguments with colons in 21e9757
> (Hack git-add--interactive to make it work with ActiveState Perl -
> 2007-08-01). Pathspec magic starts with a colon, so it won't work if
> these pathspecs are passed to git-add--i
Am 8/31/2013 23:26, schrieb Felipe Contreras:
> +--except::
> + Skip the following object names. For example:
> + '--branches --except master' will show all the branches, except master.
> + This differs from --not in that --except will still show the object, if
> + they are referenc
Am 8/31/2013 21:27, schrieb Felipe Contreras:
> On Fri, Aug 30, 2013 at 2:56 AM, Johannes Sixt wrote:
>> Am 8/30/2013 8:32, schrieb Junio C Hamano:
>>> If you have a history where
>>>
>>> - branches "master" and "maint" point at com
Am 8/30/2013 9:32, schrieb Felipe Contreras:
> On Fri, Aug 30, 2013 at 2:26 AM, Junio C Hamano wrote:
>> On Aug 30, 2013 12:19 AM, "Felipe Contreras"
>> Would the same argument apply to
>>
>> next ^maint --except maint
>>
>> where next gets in the queue, maint in tainted, and skipped?
>
> main
Am 8/30/2013 8:32, schrieb Junio C Hamano:
> If you have a history where
>
> - branches "master" and "maint" point at commit A;
> - branch "next" points at commit B that is a descendant of A; and
> - there are tags X and Y pointing at commits that are ahead of B
>or behind A
>
> i.e.
>
>
Am 8/30/2013 7:00, schrieb Felipe Contreras:
> So that it's possible to remove certain refs from the list without
> removing the objects that are referenced by other refs.
>
> For example this repository:
>
> * 374e8dd (crap) crap
> * 4cbbf7b (test) two
> * d025ae0 (HEAD, master) one
>
> W
Am 8/30/2013 0:46, schrieb Dave Williams:
> +-i, --ignore-index::
> + Don't look in the index when undertaking the checks. This means
> + the results deviate from those seen by git add and git status
> + but is useful when understanding why a path became tracked by
> + e.g. git add
With nd/magic-pathspec I get the following failure on Windows in
t2016-checkout-patch.sh:
expecting success:
set_state dir/foo work head &&
# the third n is to get out in case it mistakenly does not apply
(echo y; echo n; echo n) | (cd dir && git checkout -p foo) &&
Am 8/28/2013 10:32, schrieb Matthieu Moy:
> Historically, "git status" needed to prefix each output line with '#' so
> that the output could be added as comment to the commit message. This
> prefix comment has no real purpose when "git status" is ran from the
> command-line, and this may distract u
Am 8/27/2013 23:48, schrieb Jeff King:
> The counterarguments I can see are:
>
> 1. Who cares? If you want to know whether pack-objects will choke on
> your huge config value, then run pack-objects.
>
> 2. Such a check would involve knowing which type we use internally to
> look at
Am 26.08.2013 21:56, schrieb Jeff King:
> Also, prevent the delimiter being added twice, as happens now in these
> examples:
>
> git grep -l foo HEAD:
> HEAD::some/path/to/foo.txt
>^
Which one of these two does it print then?
HEAD:/some/path/to/foo.txt
HEAD:some/path/to/foo.t
Am 25.08.2013 21:44, schrieb Christian Couder:
> What about:
>
> die("Objects must be of the same type.\n"
> "'%s' points to a replaced object of type '%s'\n"
> "while '%s' points to a replacement object of type '%s'.",
Much better!
-- Hannes
--
Am 25.08.2013 15:06, schrieb Christian Couder:
> +test_expect_success 'replaced and replacement objects must be of the same
> type' '
> + test_must_fail git replace mytag $HASH1 2>err &&
> + grep "Object ref '\''mytag'\'' is of type '\''tag'\''" err &&
Uh, this hurts in the eye! Please wr
Am 25.08.2013 15:06, schrieb Christian Couder:
> @@ -100,6 +101,15 @@ static int replace_object(const char *object_ref, const
> char *replace_ref,
> if (check_refname_format(ref, 0))
> die("'%s' is not a valid ref name.", ref);
>
> + obj_type = sha1_object_info(object, NU
Am 23.08.2013 01:14, schrieb Jeff King:
+++ b/t/t5308-pack-detect-duplicates.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='handling of duplicate objects in incoming packfiles'
+. ./test-lib.sh
+. ../lib-pack.sh
This should be
. "$TEST_DIRECTORY"/lib-pack.sh
to support running tests with
Am 21.08.2013 15:07, schrieb Matthieu Moy:
Stefan Beller writes:
But as these follow up changes heavily rely on the very first patch
I will first try to get that right, meaning accepted into pu.
Then I can send patches with these proposals such as making more
functions.
I think it's better t
Am 22.08.2013 00:15, schrieb Stefan Beller:
On 08/21/2013 10:56 PM, Junio C Hamano wrote:
Stefan Beller writes:
+static int delta_base_offset = 1;
+char *packdir;
Does this have to be global?
As the path is pretty obvious (get_object_directory() + "/pack"),
we could however also construct
Am 21.08.2013 10:49, schrieb Matthieu Moy:
Stefan Beller writes:
+ for_each_string_list_item(item, &names) {
+ for (ext = 0; ext < 2; ext++) {
+ char *fname, *fname_old;
+ fname = mkpathdup("%s/%s%s", packdir, item->string,
exts[e
Am 21.08.2013 00:36, schrieb Stefan Beller:
I think I got all the suggestions except the
use of git_path/mkpathdup.
I replaced mkpathdup by mkpath where possible,
but it's still not perfect.
I'll wait for the dokumentation patch of Jonathan,
before changing all these occurences forth and back
aga
Am 20.08.2013 20:52, schrieb Junio C Hamano:
Junio C Hamano writes:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Here is a result of a quick audit (of 1.8.0.x codebase).
As xwrite() will not be splitting a single-byte request, the patch
to cat-file is more or l
Am 20.08.2013 17:08, schrieb Stefan Beller:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
You cannot run_command() and then later read its output! You must split
it into start_command(), read stdout, finish_command().
Thanks for this hint. Could that explain rare non-deterministic failures in
Am 20.08.2013 17:16, schrieb Antoine Pelisse:
I was actually wondering when it's better to use xread() over
read_in_full() ? Considering that we don't know if xread() will read
the whole buffer or not, would it not be better to always use
read_in_full() ?
Of course, you know whether the whole b
Am 20.08.2013 17:00, schrieb Junio C Hamano:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Looking at the grep -C1 output, there are no others.
The only one that looked suspicious was xread in remote-curl.c, but it is
fine (it just eats all data from the input).
I didn't look at functions above cmd_repack.
Am 20.08.2013 01:23, schrieb Stefan Beller:
+int cmd_repack(int argc, const char **argv, const char *prefix) {
+
+ int pack_everything = 0;
+ int pack_everything_but_loose = 0;
+ int delete_redundant = 0;
+ char *unpack_unreach
The deflate loop in bulk-checkin::stream_to_pack expects to get all bytes
from a file that it requests to read in a single function call. But it
used xread(), which does not give that guarantee. Replace it by
read_in_full().
Signed-off-by: Johannes Sixt
---
The size is limited to sizeof(ibuf
Am 19.08.2013 10:25, schrieb Stefan Beller:
On 08/19/2013 10:20 AM, Johannes Sixt wrote:
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+git config filter.largefile.smudge cat &&
+git config filter.largefile.
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
Note that 'git add' exits with 0 even if it prints filtering errors to
stderr. The test, therefore, checks stderr. 'git add' should probably
be changed (sometime in another commit) to exit with nonzero if
filtering fails. The test could then be ch
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+ git config filter.largefile.smudge cat &&
+ git config filter.largefile.clean cat &&
+ for i in $(test_seq 1 2048); do printf "%1048576d" 1; done >2GB &&
Shouldn't you count t
Am 16.08.2013 00:36, schrieb Junio C Hamano:
Due to unfortunate regressions, two topics had to be reverted:
* An attempted fix to "git stash save", to detect that going back
to the state of the HEAD needs to lose killed files, and/or
untracked files in a killed directory, to prevent th
Am 17.08.2013 14:40, schrieb Steffen Prohaska:
Previously, filtering more than 2GB through an external filter (see
test) failed on Mac OS X 10.8.4 (12E55) with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signa
Am 16.08.2013 12:36, schrieb SZEDER Gábor:
+repo_with_newline='repo
+with
+newline'
+
+test_expect_success 'prompt - with newline in path' '
This test must be skipped when the filesystem does not support LF in file
names. Cf. the FUNNYNAMES prerequisite in t3600-rm.sh.
+ printf " (mas
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Stefano Lattarini writes:
My problems is that some new automagical interpretation of the bare
@' character (introduced after 1.8.3) has destroyed my use case:
...
I don't want to ask you to revert this new behaviour, but I'd like to
at least have an
Am 8/9/2013 12:03, schrieb shawn wilson:
> The question still stands though - why is that unassociated commit left there?
Because your command did not remove it. filter-branch does not know that
it is "unassociated" when you ask it to follow all commits beginning at
HEAD. But when you say 'HEAD --
Am 8/9/2013 8:33, schrieb shawn wilson:
> On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt wrote:
>> Am 8/8/2013 23:11, schrieb Phil Hord:
>>> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
>>>> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
>>>&g
Am 8/8/2013 23:11, schrieb Phil Hord:
> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
>> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
>>> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
>>>> these scripts and I'd like to
Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
> these scripts and I'd like to keep the commit history.
>
> Ok, so:
> % find -type f ! -iname "webban.pl" | while read f; do git
> filter-branch -f --index-filter "git rm --cached --ignore-unmatch $f"
> HEAD ; done
>
> Which bas
Am 8/5/2013 16:23, schrieb Duy Nguyen:
> close() is added in commit_lock_file(), before rename(), by 4723ee9
> (Close files opened by lock_file() before unlinking. - 2007-11-13),
> which is needed by Windows. But doesn't that create a gap between
> close() and rename() on other platforms where anot
Am 03.08.2013 12:01, schrieb Duy Nguyen:
> On Sat, Aug 03, 2013 at 11:49:02AM +0200, Johannes Sixt wrote:
>> Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
>>> I changed mingw.h to add a stub uname() because I don't think MinGW
>>> port has that funct
Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
> I changed mingw.h to add a stub uname() because I don't think MinGW
> port has that function, but that's totally untested.
Thanks, but we don't have kill(pid, 0), either :-(
-- Hannes
--
To unsubscribe from this list: send the line "unsubscr
Am 7/25/2013 10:03, schrieb Eric Sunshine:
> The tests in this series identify real bugs in dealing with empty
> ranges, which the subsequent patches fix. The test are possible
> because one can specify an empty range via blame/log -L, however, I
> now realize that the ability for -L to create empt
Am 7/19/2013 11:21, schrieb Allan Acheampong:
> Something like 'git clone -createLocalBranchesForAllBranches'
Perhaps:
$ git clone theRepo
$ git fetch origin refs/heads/*:refs/heads/*
(untested). There may be ways to write the same shorter, but I've lost
track of what is and what is not possibl
I question the value of this warning. Initialization with '=
{0}' is a well-established idiom, and sparse should know about
it.
Thanks everyone for your feedback. But I really wanted to call only the
warning in the case of the '= {0}' idiom into question, not about 0 vs.
NULL in gen
Am 7/15/2013 19:48, schrieb Greg Troxel:
> Clearly there is the possibility of creating a corrupt repository when
> receiving objects and updating refs, if a crash or power failure causes
> data not to get written to disk but that data is pointed to. Journaling
> mitigates this, but I'd argue that
Am 7/15/2013 19:31, schrieb Ramsay Jones:
> Sparse issues three "Using plain integer as NULL pointer" warnings.
> Each warning relates to the use of an '{0}' initialiser expression
> in the declaration of an 'struct object_info'.
I question the value of this warning. Initialization with '= {0}' is
Am 14.07.2013 22:59, schrieb Johannes Sixt:
> ... I wonder how Junio's last
> example with push.default=simple can work today:
>
>$ git pull --rebase # not a merge
>$ git push
>
> because it is not a fast-forward.
*blush* I was mostly asleep and and totally
Am 15.07.2013 05:50, schrieb Junio C Hamano:
> ... or also with your "--lockref is default"
> $ git push origin +master
>
> ... rejected due to stale expectation
> $ git fetch
>
> You just have updated the lockref base, so if you did, without doing
> anything else,
>
Am 14.07.2013 22:34, schrieb Jonathan Nieder:
> Johannes Sixt wrote:
>
>> Sorry, IMO, this goes into a totally wrong direction, in particular, I
>> think that this is going to close to door to make --lockref the default
>> some day in a way that helps everyone.
>
&
Am 14.07.2013 21:17, schrieb Junio C Hamano:
> Johannes Sixt writes:
>> I actually think that by implying allow-no-ff in --lockref, you are
>> hurting users who have configured a push refspec without a + prefix:
>> They suddenly do not get the push denied when it is not a fa
Am 13.07.2013 22:08, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> If "--lockref" automatically implies "--allow-no-ff" (the design in
>> the reposted patch), you cannot express that combination. But once
>> you use "--lockref" in such a situation , for the push to succeed,
>> you know t
Am 13.07.2013 20:14, schrieb Junio C Hamano:
> Johannes Sixt writes:
>>> Your table above makes this fail:
>>>
>>> git push --lockref topic
>>>
>>> and the user has to force it,
>>
>> Of course.
>>
>>>
Am 12.07.2013 23:19, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> We have three independent options that the user can choose in any
>> combination:
>>
>> o --force given or not;
>>
>> o --lockref semantics enabled or not;
>>
>
Am 12.07.2013 19:40, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 12.07.2013 00:14, schrieb Junio C Hamano:
>>> Johannes Sixt writes:
>>>
>>>> Again: Why not just define +refspec as the way to achieve this check?
>>>
>>&
Am 12.07.2013 00:14, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Again: Why not just define +refspec as the way to achieve this check?
>
> What justification do we have to break existing people's
> configuration that says something like:
>
> [
Am 10.07.2013 01:08, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> I _think_ I am OK if we introduced "--allow-no-ff" that means the
>> current "--force" (i.e. "rewinding is OK"), that does not defeat the
>> "--lockref" safety. That is the intended application (you know that
>> push does
Am 09.07.2013 22:37, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 09.07.2013 21:53, schrieb Junio C Hamano:
>>> +--lockref::
>>> +--lockref=::
>>> +--lockref=:::
>>> ...
>>> +This is meant to make `--force` safer to use.
>&g
Am 09.07.2013 21:53, schrieb Junio C Hamano:
> +--lockref::
> +--lockref=::
> +--lockref=:::
> ...
> +This is meant to make `--force` safer to use.
This is a contradiction. "--force" means "I mean it, dude", and not "I
mean it sometimes". It would make sense if this sentence were "This is
meant to
Am 7/3/2013 21:53, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> I don't think that is necessary. We already have *two* options to
>> force-push a ref: the + in front of refspec, and --force.
>
> They mean exactly the same thing; the only difference being th
Am 7/3/2013 12:50, schrieb Michael Haggerty:
> On 07/03/2013 12:11 PM, Johan Herland wrote:
>> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
>> wrote:
>>> I'm struggling to think of instances where I wouldn't want this
>>> CAS-like behaviour. Wouldn't it be better to make it the default
Am 5/24/2013 1:23, schrieb Alois Mahdal:
> ...query for when the file was really added,
> which I was trying to achieve with
>
> $ git -1 --reverse --follow several_times_renamed_file
Assuming you meant 'git log -1 ...' or similar. It won't do what you think
it would do because:
* -1 is a re
Am 7/2/2013 0:50, schrieb Alexey Shumkin:
> On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
>> Am 6/26/2013 12:19, schrieb Alexey Shumkin:
>>> test_expect_success 'setup complex body' '
>>> git config i18n.commitencoding iso8859-1 &am
US.UTF-8 sed -e
> "s/^\(.\{$2\}\)$3/\1../")
> + fi
> + echo $msg
> +}
Ignoring failure reports is not very helpful. Anyway, here is how I would
adjust this patch. (There are trivial conflicts when 5/5 is applied on
top.) Notice the comment I added in test case 'le
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
> One can set an alias
> $ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
> -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
> --abbrev-commit --date=local"
>
> to see the log as a pretty tree (like *git
Am 27.06.2013 14:47, schrieb Sebastian Schuberth:
> diff --git a/git-archimport.perl b/git-archimport.perl
> index 9cb123a..ed2c741 100755
> --- a/git-archimport.perl
> +++ b/git-archimport.perl
...
> @@ -477,8 +477,8 @@ sub process_patchset_fast {
> unlink @$del;
> while (@$del)
Am 25.06.2013 00:10, schrieb Junio C Hamano:
> Mark Levedahl writes:
>
>> On 06/22/2013 03:38 PM, Ramsay Jones wrote:
>>> Also, apart from running the git test-suite, I have the Win32
>>> l/stat functions disabled on all of my repos. In particular, I have
>>> core.filemode set to true. (At one po
Am 24.06.2013 17:21, schrieb Jiang Xin:
> Add new subcommand "mingw_path" in test-path-utils, so that we can get
> the expected absolute paths on Windows. For example:
>
> COMMAND LINELinux Windows
> == = ===
>
Am 22.06.2013 00:32, schrieb Junio C Hamano:
> Ramkumar Ramachandra writes:
>
>> Replace the 'git config' calls in tests with test_config for greater
>> robustness.
>
> That may be a good thing in principle, but I _think_
>
> mk_empty testrepo &&
> (
> cd testrepo &&
Am 6/20/2013 20:11, schrieb Junio C Hamano:
> Johannes Sixt writes:
>> But you can't have this string:
>>
>> "Splitting a commit while rebasing branch '%2$s' on '%3$s'."
>>
>> neither in the template nor in the translation, b
Am 6/20/2013 9:56, schrieb Peter Krefting:
> Junio C Hamano:
>
>> But my understanding is that the reordering using printf() is the
>> mechanism we suggest l10n folks to use when the order of parameters
>> given to printf does not match the preferred word order in the message
>> in their language.
Am 6/19/2013 10:04, schrieb Ramkumar Ramachandra:
> +test_expect_failure '"checkout -" works after a rebase -i A B' '
> + git branch foodle master~1 &&
> + git checkout master &&
> + git checkout other &&
> + git rebase master foodle &&
git rebase -i master foodle &&
> +
Am 6/19/2013 8:09, schrieb Ramkumar Ramachandra:
> Johannes Sixt wrote:
>> I haven't followed the topic closely, but I wonder why there are so many
>> explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
>> (defined in git-sh-setup) the wrong thing to
Am 6/18/2013 17:53, schrieb Martin von Zweigbergk:
> On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt wrote:
>> Knowing that the tests would take their time to complete on Windows,
>
> I'm curious just how slow it is. Are we talking minutes?
D:\Src\mingw-git\t>bas
Am 6/18/2013 20:55, schrieb Ramkumar Ramachandra:
> Now that the "checkout" invoked internally from "rebase" knows to honor
> GIT_REFLOG_ACTION, we can start to use it to write a better reflog
> message when "rebase anotherbranch", "rebase --onto branch",
> etc. internally checks out the new fork p
From: Johannes Sixt
The recently introduced tests used uppercase letters to denote
cherry-picks of commits having the corresponding lowercase letter names.
The helper functions also set up tags with the names of the commits.
But this constellation fails on case-insensitive file systems because
Am 6/17/2013 11:18, schrieb Thomas Rast:
> +match_pattern_list () {
> + arg="$1"
> + shift
> + test -z "$*" && return 1
> + for pat
> + do
> + case "$arg" in
> + $pat)
> + return 0
> + esac
> + done
> + return 1
> +
Am 6/17/2013 15:57, schrieb Mathieu Liénard--Mayor:
> Le 2013-06-17 15:54, Peter Krefting a écrit :
>> Mathieu Liénard--Mayor:
>>
>>> Actually, at first I dealt with it this way:
>>>
>>> status_printf_ln(s, color,
>>> _("Splitting %s while rebasing branch '%s' on '%s'."),
>>>
From: Johannes Sixt
The bash on Windows rewrites paths that look like absolute POSIX paths
when they are a command-line argument of a regular Windows program, such
as git and the test helpers. As a consequence, the actual tests performed
are not what the tests scripts expect.
The tests that
Am 11.06.2013 19:06, schrieb Yann Droneaud:
> Hi,
>
> I'm trying to setup a workflow to track vendor releases (upstream).
> Each new release are provided as an archive of source code, data,
> documentation, etc.
>
> For each vendor releases, fixes need to be applied before making them
> available
Am 10.06.2013 19:27, schrieb SZEDER Gábor:
> My main motivation is that, like in your example, in the bash prompt
> tests I only have to check a single line of output, but because of
> debuggability I always did:
>
> echo "(master)" >expected
> __git_ps1 >actual
> test_cmp expected actual
C
From: Erik Faye-Lund
Returning the SIGALRM handler for SIGINT is not very useful.
Signed-off-by: Erik Faye-Lund
Signed-off-by: Johannes Sixt
---
Am 6/7/2013 16:20, schrieb Erik Faye-Lund:
> On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote:
>> BTW, isn't mingw_signal() bo
Am 6/9/2013 22:31, schrieb Junio C Hamano:
> Jeff King writes:
>
>> I'm a little negative on handling just SIGTERM. That would make the test
>> pass, but does it really address the overall issue? To me, the
>> usefulness is having exit values with consistent meanings.
>
> Yes. Unless the goal i
Am 08.06.2013 08:51, schrieb Torsten Bögershausen:
> Filesystems like VFAT or NTFS allow to create files regardless of
> the write permissions of the directory.
>
> Therefore "mktemp to unwritable directory" in t0700 will always fail on
> Windows using NTFS.
> This TC has been disabled for MINGW,
, where "trivial" means:
- merely a replacement of 'ln -s a b && git add b' by test_ln_s_add
is needed;
- a test for symbolic link on the file system can be split off (and
remains protected by SYMLINKS);
- existing code is equivalent to test_ln_s_add.
Signed-off-by:
the worktree, which we can update as if it were a
symbolic link. diff-index picks up the symbolic link property from the
index.
Signed-off-by: Johannes Sixt
---
t/t4011-diff-symlink.sh | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/t
Add a new function that creates a symbolic link and adds it to the index
to be used in cases where a symbolic link is not required on the file
system. We will use it to remove many SYMLINKS prerequisites from test
cases.
Signed-off-by: Johannes Sixt
---
t/README| 14
system.
Move these tests into separate test cases that remain protected by
SYMLINKS.
There is one instance of expect_failure. There is a possibility that this
test case fails differently depending on whether SYMLINKS is present or
not; but this is not the case.
Signed-off-by: Johannes Sixt
---
t
This undoes the special casing introduced in this test by 704a3143
(Use prerequisite tags to skip tests that depend on symbolic links,
2009-03-04).
Signed-off-by: Johannes Sixt
---
t/t3100-ls-tree-restrict.sh | 42 +++---
1 file changed, 15 insertions(+), 27
get rid of explicit SYMLINKS checks.
This undoes the special casing introduced in this test by 704a3143
(Use prerequisite tags to skip tests that depend on symbolic links,
2009-03-04).
Signed-off-by: Johannes Sixt
---
t/t-basic.sh | 39 ++-
1 file changed
In t4023 and t4114, we have to remove the entries using 'git rm' because
otherwise the entries that must turn from symbolic links to regular files
would stay symbolic links in the index. For the same reason, we have to
use 'git mv' instead of plain 'mv' in t3509.
; the corresponding modernization
patch is gone.
- Moved the t4011 change from the "trivial cases" to its own patch.
It still contains the effects of the former test_ln_s, but open-coded
and with a comment.
Johannes Sixt (10):
test-chmtime: Fix exit code on Windows
t3010: moder
In particular:
- move test preparations inside test_expect_success
- place test description on the test_expect_success line
- indent with a tab
Signed-off-by: Johannes Sixt
---
t/t3010-ls-files-killed-modified.sh | 123 ++--
1 file changed, 61 insertions
nding on whether SYMLINKS is present or not; but this is not the case
presently.
Signed-off-by: Johannes Sixt
---
t/t3030-merge-recursive.sh | 62 +++---
1 file changed, 26 insertions(+), 36 deletions(-)
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-
MinGW's bash does not recognize an exit code -1 as failure. See also
47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt
---
test-chmtime.c | 8
1 file
Am 07.06.2013 08:11, schrieb Martin von Zweigbergk:
> Changes since v5:
>
> * Improved test_linear_range
> * Changed TODOs to be about consistency, not --topo-order
>
> Martin von Zweigbergk (7):
> add simple tests of consistency across rebase types
> add tests for rebasing with patch-equiv
Am 6/7/2013 14:46, schrieb Erik Faye-Lund:
> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:
>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
>>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
>>>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
>>>
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
>>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
>>>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wro
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>>
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this c
Am 6/6/2013 19:40, schrieb Jeff King:
> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>
>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL
>>> action will cause process death (SIGTERM in this case), the
>>> implementation of raise() just calls exit(3).
From: Johannes Sixt
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the
1001 - 1100 of 1357 matches
Mail list logo