Stefan Beller writes:
> run-command.c | 264
> +
> run-command.h | 36 +++
> t/t0061-run-command.sh | 20
> test-run-command.c | 24 +
> 4 files changed, 344 insertions(+)
I think we are almost there, but the
Stefan Beller writes:
> +static void pp_buffer_stderr(struct parallel_processes *pp)
> +{
> + int i;
> +
> + while ((i = poll(pp->pfd, pp->max_processes, 100)) < 0) {
> + if (errno == EINTR)
> + continue;
> + pp_cleanup(pp);
> + die_
Junio C Hamano writes:
> Stefan Beller writes:
>
>> +static void pp_buffer_stderr(struct parallel_processes *pp)
>> +{
>> +int i;
>> +
>> +while ((i = poll(pp->pfd, pp->max_processes, 100)) < 0) {
>> +i
Ramsay Jones writes:
> Commits 9c0b9f6 ("worktree: add 'list' command", 18-09-2015) and
> 40ca3d3 ("worktree: add functions to get worktree details", 18-08-2015)
> both introduce the use of a C99 feature (declare the loop control
> variable in the loop header initializer section).
>
> Signed-off-
Johannes Schindelin writes:
>> A .git/tmp/ would make housekeeping easier, you would know that every
>> file under .git
>> should be there and if you find something you don't recognize you would
>> react.
>
> No, it would actually make it harder. I seem to recall that there was
> some problem wi
Junio C Hamano writes:
> Just to make sure there is no misunderstanding, just like I prefer
> "start one" over "start as many as possible" in order to give
> scheduling decision to the calling loop, I would expect that...
To sum up, what I anticipate would happen
Stefan Beller writes:
> I modified the test-run-command test function to start up to 400 processes.
> (Most people will use less than 400 processes in the next 5 years), and run
> just as in t0061:
>
> ./test-run-command run-command-parallel-400 sh -c "printf
> \"%s\n%s\n\" Hello World"
>
> T
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs.
>
> This also removes the error from being displayed. As branch.c will use
> ref-filter APIs in the following patches, the error checking becomes
> redundant with the error
Matthieu Moy writes:
> The series looks good to me. I did a minor remark on PATCH 5/8 but this
> should not block inclusion.
Thanks. As long as the log message is telling the truth, I do not
mind the actual lossage of the error message shown to the user.
--
To unsubscribe from this list: send
Junio C Hamano writes:
> You are running "git fetch" that are is a lot more heavy-weight.
> Because once each of them started fully they will be network bound,
> it is likely that you would want to run more processes than you have
> core.
I thought the conclusion would b
Stefan Beller writes:
> I can confirm this now.
>
> git fetch --recurse-submodules=yes -j 400
>
> in an submodule-ified Android tree takes very long to start putting out useful
> information, but if I hardcode the SPAWN_CAP to 4 it looks pretty amazing
> fast.
Nice to hear that parallel fetc
Stefan Beller writes:
> Split the cloning part out to its own function,
> this allow us in a later patch to convert cmd_update in C.
>
> Signed-off-by: Stefan Beller
> ---
It appears that this is not just a refactor and loses the logic
around $cloned_modules variable that seems to avoid doing t
Matthieu Moy writes:
> More precisely: if we find such a branch ref and we're used with an
> option that requires us to lookup the commit, then we report it as an
> error.
> ...
> So I agree with Junio that the commit message is not sufficient: there
> is a behavioral change. I'm OK with it, but
Junio C Hamano writes:
>> BTW, this looks like an fsck bug:
>>
>> $ git fsck --strict
>> Checking object directories: 100% (256/256), done.
>> error: refs/heads/broken: not a commit
>> $ echo $?
>> 0
>
> Interesting. Perhaps leave it as a
Junio C Hamano writes:
> Perhaps something like this (not even compile tested as both of my
> worktrees are doing something else)
This time with a few additional tests.
-- >8 --
Subject: [PATCH] fsck: exit with non-zero when problems are found
After finding some problems (e.g. a
Matthieu Moy writes:
> To be sure, I tried:
>
> echo ee0f5eeeae36cd1b5a346a1e2ae5c8cb841cd5da > .git/refs/heads/broken
>
> where the sha1 is the one of a blob.
> ...
After doing (something like) the above, running "git push --mirror"
to various Git repositories shows their slightly different
b
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Not much has happened on the 'master' or 'next' fronts, but we have
seen quite a lot of activities above them to prepare for the next
cycle, whi
Stefan Beller writes:
> I agree the commit 7087c5f3 (SQUASH??? on top of run-command: add an
> asynchronous parallel child processor) makes sense; I arrived at the same
> patch after adding in the feedback.
I dunno. As I said, while a small part of that commit is necessary
to be squashed into [
Mike Rappazzo writes:
> ... Does the porcelain
> format restrict additive changes? That is, is it OK for a future
> patch to add another field in the format, as long as it doesn't alter
> the other values? Is the format that I have used here acceptable
> (assuming the changes proposed below ar
Jeff King writes:
> For the same reasons as in my earlier responses, I think it's dangerous
> to remove broken refs (it makes a small corruption much worse). It seems
> reasonably sane to remove a dangling symref, though if we teach
> for_each_ref to gracefully skip them, then leaving them in pla
Remi Pommarel writes:
> For static linking especially library order while linking is important. For
> example libssl contains symbol from libcrypto so the former should be linked
> before the latter.
That example is not a very good one to use for two reasons:
(1) NEEDS_SSL_WITH_CRYPTO is a con
Remi Pommarel writes:
> There are situations, ie during cross compilation, where curl-config program
> is not present in the PATH.
>
> Make configure check that a custom curl-config program is passed by the user
> through ac_cv_prog_CURL_CONFIG then set CURL_CONFIG variable accordingly in
> confi
larsxschnei...@gmail.com writes:
> In order to avoid that in the future I configured Travis CI for Git. With this
> patch Travis can run all Git tests including the "git-p4" and "Git-LFS" tests.
Interesting. I was wondering about the "p4" part myself.
> My idea is that the owner of "https://git
e we are on the same wavelength.
Thanks.
>
> Signed-off-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
> run-command.c | 43 ++-
> run-command.h | 1 +
> 2 files changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/run-co
Stefan Beller writes:
> * If you do not die() in start_failure_fn or return_value_fn, you
>don't want to write to stderr directly as you would destroy the fine
>ordering of the processes output. So make the err strbuf available in
>both these functions, and make sure the strbuf is ap
Junio C Hamano writes:
> I think that is a sensible change. Don't we want the same for the
> other failure handler, though. Capture any message from it and
> append it to the output of the process that just finished, or
> something?
Ah, that is already done. Scratch that &qu
Stephan Beyer writes:
> The definition of log_div() appended information to the web server's
> logfile to make the test more readable. However, log_div() was called
> right after a request is served (which is done by git-http-backend);
> the web server waits for the git-http-backend process to ex
ps in a smooth port of branch.c to use ref-filter APIs
over the following patches. On the other hand, ref-filter ignores refs
which do not point at commits silently.
Based-on-patch-by: Jeff King
Helped-by: Junio C Hamano
Mentored-by: Christian Couder
Mentored-by: M
Jeff King writes:
> I count 4 callers in the current code, and none of them currently looks
> at the return value. Your patch updates setup_tracking() to propagate
> the error, which is good. But that is called from exactly one place,
> create_branch(), which also ignores the outcome. :-/
>
> I d
Luke Diamand writes:
> From past experience, if it's configured to email people when things
> break, sooner or later it will email the wrong people, probably once
> every few seconds over a weekend.
>
> Automated testing is a Good Thing, but it's still software, so needs
> maintenance or it will
Stephan Beyer writes:
> SubmittingPatches says that when there is consensus the patch has to
> be resent to Junio and cc'ed to the list. Here it is (although I
> don't know if there is consensus, but, hey, it's a rather trivial patch,
> so it should be okay).
Yup.
The patch text matches exa
Stefan Beller writes:
> Sure. I just wanted to point out the details instead of resending the series.
> I'll do a resend later today, hoping to get all issues addressed.
Thanks. For something this small, unless there are many small
pieces that need to be picked apart, I do not terribly mind to
Jeff King writes:
> If the point is for clients not to trust GitHub, though, it doesn't
> really matter what GitHub does with the cert, as long as it is put
> somewhere that clients know to get it.
Correct. A spiffy Web interface that says "Click this button and we
show you the output of GPG si
Stefan Beller writes:
>> I think two sensible choices that start-failure and return-value can
>> make are
>>
>> (1) This one task failed, but that is OK. Please let the other
>> tasks run [*1*].
>>
>> (2) There is something seriously wrong with the whole world and I
>> declare an eme
Stefan Beller writes:
> We could also offer more access to the pp machinery and an implementation for
> (2) might look like this:
>
> static void fictious_start_failure(void *data,
> void *pp,
> struct child_process *cp,
>
Nguyễn Thái Ngọc Duy writes:
> Strict mode is about not guessing where .git is. If the user points to a
> .git file, we know exactly where the target .git dir will be.
>
> This is needed even in local clone case because transport.c code uses
> upload-pack for fetching remote refs.
>
> Signed-off
Up to high-teens in this 43 patch series, the changes all looked
"separate filesystem backend specific part from refs.c to
refs-be-files.c" without other questionable changes, but I have to
give up at this step for now, as conflicts between the patch and the
current codebase is getting a bit too mu
David Turner writes:
>> * Pick 'next', 'jch' and 'pu' as the starting point, attempted to
>
> Do you mean that you merged these branches together, or that you tried
> each of the three?
I tried at least these three (and some other intermediate states)
before giving up.
--
To unsubscribe from thi
Karsten Blees writes:
> Problem 1: Failure to detect racy files (without USE_NSEC)
> ==
>
> Git may not detect racy changes when 'update-index' runs in parallel
> to work tree updates.
>
> Consider this (where timestamps are t.):
>
> t0.0$
Duy Nguyen writes:
> This is already answered. I just want to add that C Git has stopped
> using system fnmatch for some time (part of the reason is system
> fnmatch behaves differently in corner cases). If you don't mind C,
> have a look at dowild() in wildmatch.c, or t/t3070-wildmatch.sh for
>
Nguyễn Thái Ngọc Duy writes:
> -u has never been supported, but it was mentioned since
> 0a2bb55 (git ls-remote: make usage string match manpage -
> 2008-11-11). Nobody has complained about it for seven years, it's
> probably safe to say nobody cares. So let's remove "-u" in documents
> instead
Andrey Loskutov writes:
> On Monday 28 September 2015 10:40 Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > This is already answered. I just want to add that C Git has stopped
>> > using system fnmatch for some time (part of the reason is system
>>
Karsten Blees writes:
> Ideas for potential solutions:
> ==
>
> Performance issues:
> ---
>
> 1. Compare file times in minimum supported precision
>When comparing file times, use the minimum precision supported by
>both the writing and reading g
Johannes Schindelin writes:
> When encountering broken symrefs, such as a stale remote HEAD (which can
> happen if the active branch was renamed in the remote), it is more
> helpful to remove those symrefs than to exit with an error.
I think this depends on the perspective. One side of me says
Matthieu Moy writes:
> It probably makes sense to do the later in the case of Git, so that
> Junio doesn't get spammed when pushing topic branches to
> https://github.com/gitster/git.
I won't enable it on github.com:gitster/git anyway, so I do not
think that is a concern. I thought what people
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> When encountering broken symrefs, such as a stale remote HEAD (which can
>> happen if the active branch was renamed in the remote), it is more
>> helpful to remove those symrefs than to exit with an error.
>
&g
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> diff to v7:
> * fix commit message line length (thanks Junio)
> * fix sync command for large file system support (thanks Luke!)
> * add test case for sync command
> * rename git-p4.pushLargeFiles to git-p4.largeFilePush for consistency w
"George Spelvin" writes:
> I was applying an old forgotten stash to see if there were any edits in
> it I wanted to preserve, and my old changes to one file made no sense
> any more. I wanted to drop then all and keep the version in HEAD.
>
> I'd been using git reset after resolving conflicts,
Jacob Keller writes:
> On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano wrote:
>> "George Spelvin" writes:
>>> I understand that "git reset --soft" makes no sense with a path, but
>>> why not --hard?
>>
>> I do not think there is an
"George Spelvin" writes:
> Junio C Hamano wrote:
>> "git checkout HEAD " is a 99% acceptable substitute for it
>> (the only case where it makes a difference is when you added a path to
>> the index that did not exist in HEAD).
>
> Er, wait a mi
hindelin,
Johannes Sixt, Junio C Hamano, Karsten Blees, Karthik Nayak,
Kevin Daudt, Marc Branchaud, Matthieu Moy, Michael Haggerty,
Michael J Gruber, Mike Hommey, Nguyễn Thái Ngọc Duy, Patrick
Steinhardt, Paul Mackerras, Paul Tan, Peter Krefting, Philip
Oakley, Phillip Sz, Ralf Thielow, Ram
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
Matthieu Moy writes:
>> Confirmed: Git 2.1.4 accepts this, 2.6 doesn't:
>>
>> Warning: the command isn't recognized in the following line:
>> - # pick dbafac11052a0075233bdcf0b71f54d1503aa82d test
>>
>> You can fix this with 'git rebase --edit-todo'.
>> Or you can abort the rebase with 'git reba
Junio C Hamano writes:
> I know you alluded to preprocess what is fed to stripspace, but I
> wonder if we can remove the misguided call to stripspace in the
> first place and do something like the attached instead.
>
> git-rebase--interactive.sh | 3 +--
> 1 file changed,
Stefan Beller writes:
> + while (1) {
> + int i;
> + int output_timeout = 100;
> + int spawn_cap = 4;
> +
> + if (!no_more_task) {
> + for (i = 0; i < spawn_cap; i++) {
> + int code;
> +
Stefan Beller writes:
> The new method removes all common signal handlers that were installed
> by sigchain_push.
>
> CC: Jeff King
> Signed-off-by: Stefan Beller
> ---
> sigchain.c | 9 +
> sigchain.h | 1 +
> 2 files changed, 10 insertions(+)
Sounds like a good idea, as you need to
Lars Wendler writes:
> It seems to me that there is a size limit, after cutting down the patch
> to ~16K, sending started to work. I cut it twice, once by removing lines
> from the head and once from the bottom, in both cases at the size of
> around 16K I could send the patch.
>
> See also origin
Matthieu Moy writes:
> With Git <2.0.6, 'git rebase' used to accept lines starting with
> whitespaces followed with '#' as a comment. This was broken by
> 804098b (git rebase -i: add static check for commands and SHA-1,
> 2015-06-29), which introduced additional checks on the TODO-list using
> "g
Johannes Schindelin writes:
> I stumbled over the compile warning when upgrading Git for Windows
> to 2.6.0. There was a left-over NO_LIBGEN_H=YesPlease (which we
> no longer need in Git for Windows 2.x), but it did point to the
> fact that we use `dirname()` in builtin/am
Junio C Hamano writes:
> I may have comments on other parts of this patch, but I noticed this
> a bit hard to read while reading the end result.
> ...
I finished reading the remainder. Other than the above all look
sensible.
Will replace what had been queued.
Thanks.
--
To unsubsc
Junio C Hamano writes:
> I am actually tempted to say that we should revert 804098b, which is
> the simplest fix.
>
> If we want "check everything before doing a single thing" mode, the
> right way to do it would be to base the check on the same loop as
> transfor
Renee Margaret McConahy writes:
> The new builtin am ignores the user.signingkey variable: gpg is being
> called with the committer details as the key ID, which may not be
> correct. git_gpg_config is responsible for handling that variable and is
> expected to be called on initialization by any m
Matthieu Moy writes:
> Sounds good, yes. I'll send a patch with this and my updated tests.
Thanks. I think our mails crossed, so I'd discard my copy that
lacks the new test you wrote.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
Max Kirillov writes:
>> +if (option_dissociate) {
>> +struct packed_git *p;
>> +
>> +for (p = packed_git; p; p = p->next) {
>> +close_pack_windows(p);
>> +close_pack_index(p);
>> +}
>> dissociate_from_ref
Jeff King writes:
> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>
>> I see compile errors on my mac:
>>
>> First a whole bunch of
>>
>> ./compat/precompose_utf8.h:30:45: warning: declaration of 'struct
>> strbuf' will not be visible outside of this function [-Wvisibility]
>>
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> +pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
>> +if ! check_commit_sha "${rest%% *}" "$lineno" "$1"
>
> This does not pass my "tabs" test, as i
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 2.6.0 was released a few days ago. I'll do 2.6.1 early next
week, together with updates to a few older maintenance tracks, and
we'll start
It probably is this one:
http://thread.gmane.org/gmane.comp.version-control.git/270370/focus=270501
Older Git was loose and did not notice it, but the second hunk of
your patch is judged to be broken, with no added or deleted line
whatsoever, by the latest version.
--
To unsubscribe from this
Chris Packham writes:
> As of git 2.6 this has stopped working and stdin always fails the tty
> check.
We now run that hook thru run_hook_ve(), which closes the standard
input (as the hook is not reading anything). Perhaps you can check
if your output is connected to the tty instead?
--
To uns
Junio C Hamano writes:
> Chris Packham writes:
>
>> As of git 2.6 this has stopped working and stdin always fails the tty
>> check.
>
> We now run that hook thru run_hook_ve(), which closes the standard
> input (as the hook is not reading anything). Perhaps you ca
Ramsay Jones writes:
>> I thought I had this in yesterdays reroll (v6). Oh you're referring to
>> the version
>> from the 28th (I forgot to label them v5 I suppose).
>
> Ah! I thought I'd seen it on the list. (I thought I was going crazy) ;-)
> Sorry, my fault. I just assumed that today's pu bran
Stefan Beller writes:
> * renamed return_value_fn to task_finished_fn
It made interdiff noisier but I think it gives us a good end result.
> * the main loop of the parallel processing was first adapted to Junios
> suggestion,
> but Jonathan pointed out more improvements. We can get rid of
for-each-ref & ls-remote?
On Fri, Oct 2, 2015 at 11:54 AM, Golarits, Zsigmond (Nokia -
HU/Budapest) wrote:
> Hello,
>
> How can I get the current commit-hashes of the remote and local branches
> without check them out?
>
> Br,
> Zsigmond Golarits
> --
> To unsubscribe from this list: send the li
Michael Rappazzo writes:
> + if (!porcelain) {
> + for (i = 0; worktrees[i]; i++) {
> + int path_len = strlen(worktrees[i]->path);
> + if (path_len > path_maxlen)
> + path_m
Karthik Nayak writes:
> +static int is_empty(const char * s){
> + while (*s != '\0') {
> + if (!isspace(*s))
> + return 0;
> + s++;
> + }
> + return 1;
> +}
My knee-jerk reaction was "why is space so special?", but if a
caller really cared,
Karthik Nayak writes:
> Implement %(if:equals=) wherein the if condition is only
> satisfied if the value obtained between the %(if:...) and %(then) atom
> is the same as the given ''.
>
> Similarly, implement (if:notequals=) wherein the if condition
> is only satisfied if the value obtained betw
Up to this step everything looked sensible.
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
Karthik Nayak writes:
> Add support for %(objectname:short,) which would print the
> abbreviated unique objectname of given length. When no length is
> specified 7 is used. The minimum length is 4.
It would have to be "short=", not "short,", if I
recall the previous discussion on width=, etc., o
Michael Rappazzo writes:
> +static int parse_ref(char *path_to_ref, struct strbuf *ref, int *is_detached)
> +{
> + if (is_detached)
> + *is_detached = 0;
> + if (!strbuf_readlink(ref, path_to_ref, 0))
> + if (!starts_with(ref->buf, "refs/") ||
> +
David Turner writes:
> diff --git a/refs-be-lmdb.c b/refs-be-lmdb.c
> new file mode 100644
> index 000..99cbd29
> --- /dev/null
> +++ b/refs-be-lmdb.c
> @@ -0,0 +1,2003 @@
> +/*
> + ...
> + */
> +#include
> +#include
> +#include "cache.h"
"git-compat-util.h" (or "cache.h", because it is we
Torsten Bögershausen writes:
> On 30.09.15 02:23, Jeff King wrote:
>> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>>
>>> I see compile errors on my mac:
>>>
>
> This is my attempt, passing the test, but not fully polished.
Thanks.
> diff --git a/builtin/init-db.c b/builtin/i
Matthieu Moy writes:
> My take on it:
>
> Implement %(if), %(then) and %(else) atoms. Used as
> %(if)...%(then)...%(end) or %(if)...%(then)...%(else)...%(end). If the
> format string between %(if) and %(then) expands to an empty string, or
> to only whitespaces, then the string following %(then)
Ray Donnelly writes:
> In normalize_ceiling_entry(), we test that normalized paths end with
> slash, *unless* the path to be normalized was already the root
> directory.
>
> However, normalize_path_copy() does not even enforce this condition.
Perhaps the real issue to be addressed is the above,
Luke Diamand writes:
> On 26 September 2015 at 08:54, wrote:
>> From: Lars Schneider
>>
>> diff to v7:
>> * fix commit message line length (thanks Junio)
>> * fix sync command for large file system support (thanks Luke!)
>> * add test case for sync command
>> * rename git-p4.pushLargeFiles to
Junio C Hamano writes:
> Luke Diamand writes:
>
>> All looks good to me, Ack.
>>
>> One tiny thing perhaps Junio could comment on: the git commit message
>> for 75abe9fa5b39980de27dfc33dd5b4f4b5926f34c, "git-p4: add optional
>> type specifier to git
On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:
>
> Given this, enabling Travis CI for git/git seems pretty low risk,
> are there any strong objections to it happening?
I still don't see a reason why git/git needs to be the one that is
used, when somebody
so interested (and I seem to see ver
Junio C Hamano writes:
> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:
>>
>> Given this, enabling Travis CI for git/git seems pretty low risk,
>> are there any strong objections to it happening?
>
> I still don't see a reason why git/git needs to be the o
Ray Donnelly writes:
>> Some callers of this function in real code (i.e. not the one you are
>> removing the check) do seem to depend on that condition, e.g. the
>> codepath in clone that leads to add_to_alternates_file() wants to
>> make sure it does not add an duplicate, so it may end up not no
Matthieu Moy writes:
>> I found all the suggestions very good, except that the distinction
>> between "expands to" and "is printed" bothers me a bit, as they want
>> to mean exactly the same thing (imagine this whole thing were inside
>> another %(if)...%(then)).
>
> True. Then let me try again:
Matthieu Moy writes:
> Junio C Hamano writes:
>>
>> I still don't see a reason why git/git needs to be the one that is
>> used,
>
> The very nice thing with Travis-CI is that it does not only test the
> repository's branches, but also all pull-requests
Matthieu Moy writes:
> Currenty, to mimick this flow, we would need something like
>
> 1) User activates Travis-CI on his repo (each user would have to do
>this, not just once)
>
> 2) User commits .travis.yml on top of the code to submit
>
> 3) User pushes to his repo
>
> 4) Travis-CI trigger
larsxschnei...@gmail.com writes:
> + if test_have_prereq CYGWIN; then
> + : # NOOP
> + elif test_have_prereq DARWIN; then
> + stat -f %Sp text | egrep ^-r-- &&
> + stat -f %Sp text+x | egrep ^-r-x
> + e
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> The OS X file system is case insensitive by default. Consequently this
> test does not apply.
>
> Signed-off-by: Lars Schneider
> ---
> t/t9819-git-p4-case-folding.sh | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/t/t981
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Some Unix tools differ between Linux and Mac OS X. Add this prereq to
> detect OS X and handle it appropriately.
If my comment on 4/4 turns out to be to the point, then we do not
need this, I presume? In general, we really should think
Matthieu Moy writes:
This adds %(path) and %(path:short) atoms. The %(path) atom will print
the path of the given ref, while %(path:short) will only print the
subdirectory of the given ref.
>>>
>>> What does "path" mean in this context? How is it different from
>>> %(refname)?
>>>
Lars Schneider writes:
> By the way... what formatting should I use?
>
> if foo
> then
> bar
>
> or
>
> if foo; then
> bar
>
> I think the latter is more used in the code base.
I've allowed the latter in fringe scripts (i.e. the ones that I do
not care too deeply) over time, but Documentatio
Dennis Kaarsemaker writes:
> On zo, 2015-10-04 at 10:46 -0700, Junio C Hamano wrote:
>> One final question. Which configuration file does the CI use when
>> running a PR-initiated test? The one already in the repository
>> i.e. the target of the proposed pull, or the
Dennis Kaarsemaker writes:
> On Mon, Sep 28, 2015 at 06:02:18PM -0400, David Turner wrote:
>> Add tests for the database backend.
>>
>> Signed-off-by: David Turner
>> ---
>> t/t1460-refs-be-db.sh| 1103
>> ++
>> t/t1470-refs-be-db-reflog.sh | 3
Michael Haggerty writes:
> For this particular application, where we only have 19 strings to store,
> I suppose we could tolerate the use of approximately 64k of RAM to store
> 174 characters worth of strings *if* it would bring us big time savings.
> But I think we need some evidence of the time
Michael Haggerty writes:
>> +/* refs backends */
>> +typedef struct ref_transaction *(*ref_transaction_begin_fn)(struct strbuf
>> *err);
>
> Hmmm, I thought our convention was to define typedefs for functions
> themselves, not for the pointer-to-function; e.g.,
>
> typedef struct ref_transac
701 - 800 of 31372 matches
Mail list logo
