Derrick Stolee writes:
> The author_date_slab is used to store the author date of a commit
> when walking with the --author-date flag in rev-list or log. This
> was added as an 'unsigned long' in
>
> 81c6b38b "log: --author-date-order"
>
> Since 'unsigned long' is ambiguous in its bit-ness
Jeff King writes:
> Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> the "---" line is the end of the commit message. That makes sense when
> parsing trailers out of "format-patch" output, but not when we know we
> have just the commit message.
Yes, but that does not
Jeff King writes:
> Another is to tighten the check. Something like this seems more
> sensible:
Great minds think alike; is it a space was exactly what I was toying
with before I went to lunch. FWIW I saw the full test suite passes
when I came back and then saw you had an identical patch ;-)
Junio C Hamano writes:
> Jeff King writes:
>
>> When we serve a fetch, we pass the "wants" and "haves" from
>> ...
>> This lets us limit the change primarily to the oe_delta()
>> and oe_set_delta_ext() functions. And as a bonus, most of
>
Jeff King writes:
> When we serve a fetch, we pass the "wants" and "haves" from
> ...
> This lets us limit the change primarily to the oe_delta()
> and oe_set_delta_ext() functions. And as a bonus, most of
> the rest of the code does not consider these dummy entries
> at all, saving both runtime
Jeff King writes:
> On Fri, Aug 17, 2018 at 04:54:27PM -0400, Jeff King wrote:
>
>> This series more aggressively reuses on-disk deltas to serve fetches
>> when reachability bitmaps tell us a more complete picture of what the
>> client has. That saves server CPU and results in smaller packs. See
Jeff King writes:
> The test-tool programs include "test-tool.h" as their first
> include, which breaks our CodingGuideline of "the first
> include must be git-compat-util.h or an equivalent".
>
> Rather than change them all, let's instead make test-tool.h
> one of those equivalents, just like
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Ensure that the commit-graph.txt and commit-graph-format.txt files
> are compiled to HTML using ASCIIDOC.
>
> Signed-off-by: Derrick Stolee
> ---
> Documentation/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
Stefan Beller writes:
> On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
>> Because of the change of base, it is hard to provide a side-by-side diff
>> from v1.
>
> I thought that was the whole point of range-diff. ;-)
I thought so, too. Was there any change that confused range-diff
Derrick Stolee writes:
> Create new method commit_graph_compatible(r) to check if a given
> repository r is compatible with the commit-graph feature. Fill the
> method with a check to see if replace-objects exist. Test this
> interaction succeeds, including ignoring an existing commit-graph and
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
An early preview of the upcoming
Brandon Williams writes:
> Introduce the config "submodule..gitdirpath" which is used to
> indicate where a submodule's gitdir is located inside of a repository's
> "modules" directory.
>
> Signed-off-by: Brandon Williams
> ---
>
> Maybe something like this on top? Do you think we should
Stefan Beller writes:
>> I find the design a bit iffy in that our usual "missing in the
>> working tree? let's use the latest blob" fallback is to take it
>> from the index, not from the HEAD.
>
> I am not sure; why does it feel iffy?
Why doesn't it? There is no justification why it has to
Jeff King writes:
> And that's exactly what this patch does: when we're
> considering whether to reuse an on-disk delta, if bitmaps
> tell us the other side has the object (and we're making a
> thin-pack), then we reuse it.
That's really the natural extension and logical consequence of the
Elijah Newren writes:
> == The patch ==
> - Ben's patch only affects the "checkout -b $NEWBRANCH" case. He
> checks for it by looking for any other flag that would be a different
> case, and using the old codepath if he finds any.
> - This means there is a "giant list of checks" for this
Jonathan Nieder writes:
>> Usually, I refrain from merging larger topics in 'next' down to
>> 'master' when we get close to -rc0, but I am wondering if it is
>> better to merge all of them to 'master', even the ones on the larger
>> and possibly undercooked side, expecting that we collectively
Nguyễn Thái Ngọc Duy writes:
> +commit.preciousDirtyIndex::
> + If some changes are partially staged in the index (i.e.
> + "git commit -a" and "git commit" commit different changes), reject
> + "git commit -a".
Or perhaps better yet, go into yes/no interaction to confirm if you
Han-Wen Nienhuys writes:
>> @@ -84,6 +86,9 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>> for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> struct keyword_entry *p = keywords + i;
>> int len = strlen(p->keyword);
Jeff King writes:
>> In the longer term we may want to accept size_t as parameter for
>> clarity (even though we know that a sideband message we are painting
>> typically would fit on a line on a terminal and int is sufficient).
>> Write it down as a NEEDSWORK comment.
>
> This "typically" made
Michael Muré writes:
> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interact with other
Junio C Hamano writes:
> Junio C Hamano writes:
>
>>>> - strbuf_add(dest, src, n);
>>>> + if (0 < n)
>>>> + strbuf_add(dest, src, n);
>>>
>>> This check seems unnecessary. strbuf_add can cope fine with !n.
>>
&
Jonathan Nieder writes:
> And here are some tests to squash in.
Thanks, will do.
Junio C Hamano writes:
>>> - strbuf_add(dest, src, n);
>>> + if (0 < n)
>>> + strbuf_add(dest, src, n);
>>
>> This check seems unnecessary. strbuf_add can cope fine with !n.
>
> I was primarily interested in catching negatives, and !
Jonathan Nieder writes:
>> --- a/sideband.c
>> +++ b/sideband.c
>> @@ -75,7 +75,7 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>
> Not about this patch: should the 'n' parameter be a size_t instead of
> an int? It doesn't matter in practice (since the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Quite a many topics have
Stefan Beller writes:
> This improves colors of the range-diff, see last patch for details.
How does this relate to your other "color with range-diff" topic
that is still in flight? This supersedes it? Builds on it?
Something else?
Thanks.
Andrei Rybak writes:
> I think it would be a good trade-off to allow these helper functions to skip
> checking emptiness of arguments for test_cmp. Such patch will require only
> s/test_cmp/&_allow_empty/ for these helper functions and it will help catch
> cases as bogus test in t5310.
>
> I'll
Junio C Hamano writes:
> This loop can run out of bytes in src in search of non-space before
> n gets to zero or negative, and when that happens ...
>
>> +for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> +struct keyword_entry *p = keywords + i;
>> +
Han-Wen Nienhuys writes:
> +/*
> + * Optionally highlight one keyword in remote output if it appears at the
> start
> + * of the line. This should be called for a single line only, which is
> + * passed as the first N characters of the SRC array.
> + */
> +static void
Nguyễn Thái Ngọc Duy writes:
> I still don't trust magic st_ino zero, or core.checkStat being zero
> on Windows, so the #if condition still remains but it covers smallest
> area possible and I tested it by manually make it "#if 1"
>
> The fallback with fspathcmp() is only done when inode
Junio C Hamano writes:
> It is a bit sad that
>
> - if (E)
> FREE_AND_NULL(E);
>
> is not sufficient to catch it. Shouldn't we be doing the same for
> regular free(E) as well? IOW, like the attached patch.
> ...
And revised even more to also spell &qu
Duy Nguyen writes:
> Just fyi this seems to do the trick. Although I'm nowhere good at
> coccinelle to say if we should include this (or something like it)
>
> -- 8< --
> diff --git a/contrib/coccinelle/free.cocci b/contrib/coccinelle/free.cocci
> index 4490069df9..f8e018d104 100644
> ---
Jonathan Nieder writes:
> Michał Górny wrote:
>
>> GnuPG supports creating signatures consisting of multiple signature
>> packets. If such a signature is verified, it outputs all the status
>> messages for each signature separately. However, git currently does not
>> account for such scenario
Jeff King writes:
> So all of this really implies to me that you want to be able to say
> "take this symref on the other side and update this one on the local
> side". I.e., some way to tell a refspec "don't update the value, update
> the symref destination". ...
> ...
> git fetch origin
Duy Nguyen writes:
> The alternative is -A or -M which may be easier associated with
> --amend.
I would be confused to mistake that "git commit -A $args" would do
something similar to "git add -A && git commit $args".
I do my fair share of amends during the day, and I've never felt the
need
who want to decide if
they want to use the 'minimal' mode, also taking information about
this mode from the commit message of c08e4d5b5c (Enable minimal stat
checking - 2013-01-22).
Helped-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 18 ++
Jeff King writes:
> Here are _my_ opinions on how we should fill the role
> ...
> So here are the nominations I came up with. If you'd like to nominate
> somebody else (or yourself!), please do. If you have opinions, let me
> know (public or private, as you prefer).
>
> - Christian Couder
>
Andrei Rybak writes:
> On 14/08/18 13:47, SZEDER Gábor wrote:
>> ... both
>> invocations produce empty 'pack{a,b}.objects' files, and the
>> subsequent 'test_cmp' happily finds those two empty files identical.
>
> Is test_cmp ever used for empty files? Would it make sense for
> test_cmp to issue
Duy Nguyen writes:
> On Thu, Aug 16, 2018 at 7:01 PM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > The description of this key does not really tell what 'minimal' mode
>> > checks exactly. More information about this mode
Jeff King writes:
> On Thu, Aug 16, 2018 at 11:57:14AM -0400, Jeff King wrote:
>
>> The only way to solve that is to count bytes. We don't have a total byte
>> count in most cases, and it wouldn't always make sense (e.g., the
>> "Compressing objects" meter can show the same issue, but it's not
Now, there is a parallel "rebase-i-in-c" effort going on, and of
course, setting various shell various and formulating a command line
that essentially does
. git-rebase--$backend
of course stops working.
> +static int run_specific_rebase(struct rebase_options *opts)
> +{
> + const
Junio C Hamano writes:
> Elia Pinto writes:
>
>> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
>> index be6e09314..658647d83 100755
>> --- a/t/t2025-worktree-add.sh
>> +++ b/t/t2025-worktree-add.sh
>> @@ -252,6 +252,11 @@ test_expect_suc
Elia Pinto writes:
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index be6e09314..658647d83 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -252,6 +252,11 @@ test_expect_success 'add -B' '
> test_cmp_rev master^ poodle
> '
>
>
Jeff King writes:
> I think that makes sense. We already see duplicates from
> for_each_packed_object() when they're in multiple packs, and callers
> just need to be ready to deal with it (and depending on what you're
> doing, you may actually _want_ the duplicates).
You of course would also
Ævar Arnfjörð Bjarmason writes:
> On Thu, Aug 16, 2018 at 12:54 PM, Shani Fridman
> wrote:
>>
>> Hi everybody,
>>
>> I've got a question regarding submodules -
>>
>> I'm working on a git project with submodules connected to it, and pulling
>> changes from them every month (more or less).
>>
samuel.maft...@gmail.com writes:
> From: Samuel Maftoul
>
> Add support for configuring default sort ordering for git branches. Command
> line option will override this configured value, using the exact same
> syntax.
Using the exact same syntax as ...?
> Signed-off-by: Samuel Maftoul
> ---
>
Christian Couder writes:
> From: Jeff King
>
> Signed-off-by: Jeff King
> Signed-off-by: Christian Couder
> ---
> t/t5319-delta-islands.sh | 143 +++
> 1 file changed, 143 insertions(+)
> create mode 100755 t/t5319-delta-islands.sh
I should have told you
Stefan Beller writes:
> The change a086f921a72 (submodule: decouple url and submodule interest,
> 2017-03-17) enables us to do more than originally thought.
> As the url setting was used both to actually set the url where to
> obtain the submodule from, as well as used as a boolean flag later
>
Stefan Beller writes:
> While at it fix a typo (s/independed/independent) and
> make sure git is not in a chain of pipes.
>
> Signed-off-by: Stefan Beller
> ---
> t/t7410-submodule-checkout-to.sh | 99 +++-
> 1 file changed, 58 insertions(+), 41 deletions(-)
Makes
Nguyễn Thái Ngọc Duy writes:
> The description of this key does not really tell what 'minimal' mode
> checks exactly. More information about this mode can be found in the
> commit message of c08e4d5b5c (Enable minimal stat checking -
> 2013-01-22).
>
While I agree that we need to do
Nguyễn Thái Ngọc Duy writes:
> --quit is supposed to be --abort but without restoring HEAD. Leaving
> CHERRY_PICK_HEAD behind could make other commands mistake that
> cherry-pick is still ongoing (e.g. "git commit --amend" will refuse to
> work). Clean it too.
>
> For --abort, this job of
Torsten Bögershausen writes:
> check_stat is 0 on Windows, and inum is allways 0 in lstat().
> I was thinking about systems which don't have inodes and inum,
> and then generate an inum in memory, sometimes random.
> After a reboot or a re-mount of the file systems those ino values
> change.
>
Ramsay Jones writes:
> BTW, I happen to be on the 'pu' branch.
>
> I think some of the errors are due to missing compiler flags
> (-I, -D, etc); which flags did you pass to the compiler?
>
> Well, it killed 15min. before bed! ;-)
>
> ATB,
> Ramsay Jones
It certainly does look fun. I anticipate
Phillip Wood writes:
> This commit implements a minimal fix which fixes the crash and allows
> the user to successfully commit a conflict resolution with 'git rebase
> --continue'. It does not write .git/rebase-merge/patch,
> .git/rebase-merge/stopped-sha or update REBASE_HEAD.
I think that
Ævar Arnfjörð Bjarmason writes:
> However, manually going over:
>
> git grep -e OPT_HIDDEN_BOOL -e PARSE_OPT_HIDDEN
>
> Shows many options we don't want to show in completion either,
> e.g. "git am --binary" or "git branch -l". Many of these are internal,
> deprecated, or no-ops. There's
Stefan Beller writes:
> Originally we have had the url in the config, (a) that we can change
> the URLs after the "git submodule init" and "git submodule update"
> step that actually clones the submodule if not present and much more
> importantly (b) to know which submodule "was
Jonathan Nieder writes:
> So it would be nice, for future-proofing, if we can change the naming
> scheme later.
> ...
> All at the cost of recording a little configuration somewhere. If we
> want to decrease the configuration, we can avoid recording it there in
> the easy cases (e.g. when name
Stefan Beller writes:
>>
>> * sb/config-write-fix (2018-08-08) 3 commits
>> - git-config: document accidental multi-line setting in deprecated syntax
>> - config: fix case sensitive subsection names on writing
>> - t1300: document current behavior of setting options
>>
>> Recent update to
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes
Torsten Bögershausen writes:
>> +
>> +#if !defined(GIT_WINDOWS_NATIVE) /* inode is always zero on Windows */
>> +for (i = 0; i < state->istate->cache_nr; i++) {
>> +struct cache_entry *dup = state->istate->cache[i];
>> +
>> +if (dup == ce)
>> +
Phillip Wood writes:
>> I wonder if it makes it easier to read, understand and maintain if
>> there were a local variable that gets opts->current_fixup_count+2 at
>> the beginning of the function, make these three places refer to that
>> variable, and move the increment of
Duy Nguyen writes:
> On Tue, Aug 14, 2018 at 10:52 PM Junio C Hamano wrote:
>> > It's not just sampling points. There's things like index id being
>> > shown in the message for example. I prefer to keep free style format
>> > to help me read. There's also thi
Ævar Arnfjörð Bjarmason writes:
+ifndef NO_TCLTK
+MAN1_TXT_WIP += gitk.txt
+MAN1_TXT = $(MAN1_TXT_WIP)
+else
+TCLTK_FILES += git-gui.txt
+TCLTK_FILES += gitk.txt
+TCLTK_FILES += git-citool.txt
+MAN1_TXT = $(filter-out \
+ $(TCLTK_FILES), \
Phillip Wood writes:
> From: Phillip Wood
>
> Commit e12a7ef597 ("rebase -i: Handle "combination of commits" with
> GETTEXT_POISON", 2018-04-27) changed the way that individual commit
> messages are labelled when squashing commits together. In doing so a
> regression was introduced where the
Duy Nguyen writes:
>> 4) eventually (in the very long run), we'd change the signature of
>> all commands from cmd_foo(int argc, char argv, char *prefix)
>> to cmd_foo(int argc, char argv, struct repository *repo)
>>
>> you seem to be interested in removing the_repository from branch.c,
>>
Duy Nguyen writes:
> On Wed, Aug 15, 2018 at 7:26 PM Junio C Hamano wrote:
>>
>> Please do not hide this bugfix behind 1/2 that is likely to require
>> longer to cook than the fix itself. And more importantly, it makes
>> it impossible to merge down the fix to
Nguyễn Thái Ngọc Duy writes:
> --quit is supposed to be --abort but without restoring HEAD. Leaving
> CHERRY_PICK_HEAD behind could make other commands mistake that
> cherry-pick is still ongoing (e.g. "git commit --amend" will refuse to
> work). Clean it too.
>
> For abort, this job of
Duy Nguyen writes:
> On Wed, Aug 15, 2018 at 6:48 PM Elijah Newren wrote:
>>
>> On Wed, Aug 15, 2018 at 9:24 AM Nguyễn Thái Ngọc Duy
>> wrote:
>>
>> The patch looks good, but since this touches multiple .c files, I
>> think I'd s/branch.c/branch/ in the subject line.
>
> It is about removing
Junio C Hamano writes:
>> # Guard against environment variables
>> MAN1_TXT =
>> +MAN1_TXT_WIP =
>> +TCLTK_FILES =
>
> The latter name loses the fact that it is to hold candidates to be
> on MAN1_TXT that happen to be conditionally included; calling it
>
Ævar Arnfjörð Bjarmason writes:
> Extend the NO_TCLTK=NoThanks flag to be understood by the
> Documentation Makefile.
>
> Before this change compiling and installing with NO_TCLTK would result
> in no git-gui, gitk or git-citool being installed, but their
> respective manual pages would still
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The `chainlint` target compares actual output to expected output, where
> the actual output is generated from files that are specifically checked
> out with LF-only line endings. So the expected output needs to be
>
Jeff King writes:
> Right, I'd agree they probably want the minimum for that traversal. And
> for `rev-list --filter`, that's probably OK. But keep in mind the main
> goal for --filter is using it for fetches, and many servers do not
> perform the traversal at all. Instead they use reachability
Matthew DeVore writes:
> Thank you. I changed it to this:
> awk -e "/tree|blob/{print \$1}" objs >trees_and_blobs
The "-e" option does not appear in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
and I think you can safely drop it from your command line.
If no -f
Elijah Newren writes:
>>
>> But please remind me not to merge this round down to 'next', for the
>> "enum" forward decl gotcha.
>
> I'll send out a new round shortly. Would you like me to squash the
> last patch (the one that had two hunks with minor conflicts with other
> topics in next and
Elijah Newren writes:
> On Tue, Aug 14, 2018 at 10:45 PM Junio C Hamano wrote:
>> Elijah Newren writes:
>>
>> > On Mon, Aug 13, 2018 at 11:24 AM Junio C Hamano wrote:
>> >> Jeff King writes:
>> >
>> >> As things are slowly moving
Elijah Newren writes:
> On Mon, Aug 13, 2018 at 11:24 AM Junio C Hamano wrote:
>> Jeff King writes:
>
>> As things are slowly moving out of the so-far kitchen-sink "cache.h"
>> into more specific subsystem headers (like object-store.h), we may
>&
Junio C Hamano writes:
> My understanding of what Joakim wants to do is to have a top-level
> project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4
> and kernel/v2.6, each of which is a submodule that houses these
> versions of Linux kernel source, but only c
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> path.c | 1 +
> 1 file changed, 1 insertion(+)
>
> On Tue, Aug 14, 2018 at 3:27 PM Joakim Tjernlund
> wrote:
>>
>> I am trying to create 3 submodules from the same git repo, each pointing to
>> a different branch.
>> Since the
Stefan Beller writes:
> Thanks Brandon for pointing out to use repo_git_path instead of
> manually constructing the path.
>
> That is the only change in this resend.
Rcpt. Hopefully this is now ready for 'next'?
Jeff King writes:
> One problem there is that the prefixes are ambiguous (e.g., Jacob Keller
> shares with me, and I think at least one other over the years). You
> could look at the author of the tip commit, but that's not always right
> (and in fact, counting just merged topics misses
Jonathan Tan writes:
>> - grep -E "tree|blob" objs >trees_and_blobs &&
>> - test_line_count = 1 trees_and_blobs
>> + grep -E "tree|blob" objs \
>> + | awk -f print_1.awk >trees_and_blobs &&
>> + git -C r1 rev-parse HEAD: >expected &&
>> + test_cmp trees_and_blobs expected
>
> Indent "| awk" (and
Duy Nguyen writes:
> These trace messages are made for human consumption. Granted
> occasionally we need some processing but I find one liners mostly
> suffice. Now we turn these into something made for machines, turning
> people to second citizens. I've read these messages reformatted for
>
Jeff King writes:
> On Tue, Aug 14, 2018 at 01:43:38PM -0400, Derrick Stolee wrote:
>
>> On 8/13/2018 5:54 PM, Jeff King wrote:
>> > So I try not to think too hard on metrics, and just use them to get a
>> > rough view on who is active.
>>
>> I've been very interested in measuring community
Antonio Ospite writes:
> /* Equivalent to ACTION_SET in builtin/config.c */
> - if (argc == 3)
> + if (argc == 3) {
> + struct object_id oid;
> +
> + /*
> + * If the .gitmodules file is not in the working tree but it
> + * is in the
Antonio Ospite writes:
> test_expect_success 'error message contains blob reference' '
> + # Remove the error introduced in the previous test.
> + # It is not needed in the following tests.
> + test_when_finished "git -C super reset --hard HEAD^" &&
> (cd super &&
>
Stefan Beller writes:
> Thanks for this patch!
> Stefan
Thanks, I'd take it as your Acked-by: (please holler if it isn't
before the patch hits 'next').
Eric Wong writes:
>> Some popular E-Mail clients completely ignore the "Date" header, which
>> format-patch is careful to set such that the patches will be displayed
>> in order, and instead sort by the time the E-mail was received.
It is send-email that carefully shows monotonically increasing
William Pursell writes:
> commit cc4bd5268b2dbe90279198acb400a528ee23f5d5
> Author: William Pursell
> Date: Tue Aug 14 06:41:00 2018 -0600
>
> doc: Reference for --dirty/--broken
>
Thanks for trying to help. Overall the resulting text does look
much better than the original, but
-
Johannes Schindelin writes:
> Hmm. I hoped that my commit message was enough to indicate that while he
> is the author, I assembled this. Maybe I should move him to the footer, as
> an Original-Authored-By:?
>
> Junio?
I think the log message gives a clear enough statement to credit the
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The way the guard was put, the code was declaring an unused variable on
> Windows. No need to do that, so let's fix it.
>
> Signed-off-by: Johannes Schindelin
> ---
> entry.c | 6 +++---
> 1 file changed, 3
Jeff Hostetler writes:
> On 8/13/2018 3:02 PM, Johannes Sixt wrote:
>>
>> Fortunately, Windows does support atomic O_APPEND semantics using the
>> file access mode FILE_APPEND_DATA. Provide an implementation that does.
>> ...
>>
>> Diagnosed-by: Johannes Schindelin
>> Helped-by: Jeff Hostetler
Jeff King writes:
> I can buy the argument that it's nice to have some form of profiling
> that works everywhere, even if it's lowest-common-denominator. I just
> wonder if we could be investing effort into tooling around existing
> solutions that will end up more powerful and flexible in the
Ævar Arnfjörð Bjarmason writes:
> O_APPEND in POSIX is race-free only up to PIPE_MAX bytes written at a
> time, which is e.g. 2^12 by default on linux, after that all bets are
> off and the kernel is free to interleave different write calls.
We are only interested in the use of race-safe append
Yaroslav Halchenko writes:
> command. ATM there is no non-interactive (via --patch/--interactive I
> think it is possible) way to commit selected subset of staged files not
> from the worktree (as it is done with "git commit file(s)") but from the
> index.
Hmph, so
edit A B C
Brandon Williams writes:
> On 08/13, Nguyễn Thái Ngọc Duy wrote:
>> This is the third part of killing the_index (at least outside
>> builtin/). Part 1 [1] is dropped. Part 2 is nd/no-extern on 'pu'. This
>> part is built on top of nd/no-extern.
>>
>> This series would actually break 'pu'
Nguyễn Thái Ngọc Duy writes:
> Make the convert API take an index_state instead of assuming the_index
> in convert.c. All external call sites are converted blindly to keep
> the patch simple and retain current behavior. Individual call sites
> may receive further updates to use the right index
Nguyễn Thái Ngọc Duy writes:
> This puts update_main_cache_tree() and write_cache_as_tree() in the
> same group of "index compat" functions that assume the_index
> implicitly, which should only be used within builtin/ or t/helper.
>
> sequencer.c is also updated to not use these functions. As
René Scharfe writes:
> the mailing list [1], nor on the web interface [2]. The latter shows
> extra spaces on the context lines of the first hunk, though, which I
> can't see anywhere else. All the lines look fine in the citation of
> Ramsay's reply [3]. So I don't know where these extra
Ævar Arnfjörð Bjarmason writes:
>Or would those companies be OK with trusting that some 20-ish of us
>can hold our tongues for one day and not ruin the surprise?
>
>There's also overlap with the remote A/V concerns there. I.e. an
>acceptable compromise for those companies might
Ævar Arnfjörð Bjarmason writes:
> This is unchanged from what's been cooking in pu for months now, so
> hopefully it can be merged down faster than most, and then I can later
> submit the actual meat of this series once I fix the (mostly doc)
> issues with it.
They have been held in 'pu' only
1201 - 1300 of 27729 matches
Mail list logo