On Fri, Jul 27, 2018 at 07:52:33PM +0200, Duy Nguyen wrote:
> Just FYI I'm still trying to reduce execution time further and this
> change happens to half traverse_trees() time (which is a huge deal)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index f0be9f298d..a2e63ad5bf 100644
> --- a/unp
On Sat, Jul 28, 2018 at 11:57 AM Jeff King wrote:
> > +static int has_duplicate_icase_entries(struct index_state *istate)
> > +{
> > + struct string_list list = STRING_LIST_INIT_NODUP;
> > + int i;
> > + int found = 0;
> > +
> > + for (i = 0; i < istate->cache_nr; i++)
> > +
On Sat, Jul 28, 2018 at 6:51 PM Ramsay Jones
wrote:
> Commit 6c213e863a ("http-backend: respect CONTENT_LENGTH for
> receive-pack", 2018-07-27) adds a test which uses the non-portable
> export construct. Replace it with "FOO=bar && export FOO" instead.
>
> Signed-off-by: Ramsay Jones
> ---
> Coul
The behavior of git commit, when doing a dry run, changes if there are
unresolved/resolved merge conflicts, but the test suite currently only
asserts that `git commit --dry-run` succeeds when all merge conflicts
are resolved.
Add tests to document the behavior of all flags (i.e. `--dry-run`,
`--sh
Following up on Junio's review from last time.
Samuel Lijin (4):
t7501: add coverage for flags which imply dry runs
wt-status: rename commitable to committable
wt-status: teach wt_status_collect about merges in progress
commit: fix exit code when doing a dry run
builtin/commit.c | 32 +
Fix a typo in the name of the committable bit in wt_status_state.
Signed-off-by: Samuel Lijin
---
builtin/commit.c | 18 +-
wt-status.c | 10 +-
wt-status.h | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/builtin/commit.c b/builtin/comm
In wt-status.c, the s->committable bit is set only in the call tree of
wt_longstatus_print(), and it is not always set correctly. This means
that in normal cases, if there are changes to be committed, or if there
is a merge in progress and all conflicts have been resolved, `--dry-run`
and `--long`
To fix the breakages documented by t7501, the next patch in this series
will teach wt_status_collect() how to set the committable bit, instead
of having wt_longstatus_print_updated() and show_merge_in_progress() set
it (which is what currently happens). To set the committable bit
correctly, however
Commit 6c213e863a ("http-backend: respect CONTENT_LENGTH for
receive-pack", 2018-07-27) adds a test which uses the non-portable
export construct. Replace it with "FOO=bar && export FOO" instead.
Signed-off-by: Ramsay Jones
---
Hi Junio,
Could you please put this on top of the 'mk/http-backend
Unlike ref advertisement, client capabilities and the first want are
separated by SP, not NUL, in the implementation. Fix the documentation
to align with the implementation. pack-protocol.txt is already fixed.
Signed-off-by: Masaya Suzuki
---
Documentation/technical/http-protocol.txt | 4 ++--
1
On Fri, Jul 27, 2018 at 02:47:00PM -0700, Josh Steadmon wrote:
> ## Use git-upload-archive
>
> This approach requires adding support for the git-upload-archive
> endpoint to the HTTP backend. Clients will connect to the remote
> server's git-upload-archive service and the server will generate the
On Sat, Jul 28, 2018 at 05:56:59AM -0400, Jeff King wrote:
> strcasecmp() will only catch a subset of the cases. We really need to
> follow the same folding rules that the filesystem would.
>
> For the case of clone, I actually wonder if we could detect during the
> checkout step that a file alrea
On Fri, Jul 27 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> +For now, the paranoid need to find some way to emulate the quarantine
>> +environment if they'd like the same protection as "push". E.g. in the
>
> We probably should mention that you can immediately prune, as t
On Fri, Jul 27 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> When fsck. is set to an unknown value it'll cause "fsck" to
>> die, but the same is not rue of the "fetch" and "receive"
>> variants. Document this and test for it.
>
> Interesting. Before documenting and adding
On Thu, Jul 26 2018, Phillip Wood wrote:
> Unfortuantely v4 had test failures due to a suprious brace from a last
> minute edit to a comment that I forgot to test. This version fixes
> that, my applogies for the patch churn.
>
> I've updated this series based on Ævar's feedback on v3 (to paraphr
On Sat, Jul 28, 2018 at 11:00 AM, Jeff King wrote:
>
> On Fri, Jul 27, 2018 at 10:22:09AM -0700, Stefan Beller wrote:
>
> > > That would solve the problem that fetching torvalds/linux from GitHub
> > > yields a bigger pack than fetching it from kernel.org. But again, it's
> > > making that root fo
On Fri, Jul 27, 2018 at 08:52:59PM -0700, Stefan Beller wrote:
> > > + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
> > > + do
> > > + cp testConfig testConfig_actual &&
> > > + git config -f testConfig_actual v.a.r value2 &&
> > > + test_cmp testConfig_ex
On 27/07/18 19:27, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Jul 26 2018, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> Unfortuantely v4 had test failures due to a suprious brace from a last
>> minute edit to a comment that I forgot to test. This version fixes
>> that, my applogies for the
On Sat, Jul 28, 2018 at 07:11:05AM +0200, Duy Nguyen wrote:
> > It might be enough to just issue a warning and give an advise() hint
> > that tells the user what's going on. Then they can decide what to do
> > (hide both paths, or just work in the index, or move to a different fs,
> > or complain
On Sat, Jul 28, 2018 at 07:11:05AM +0200, Duy Nguyen wrote:
> static int checkout(int submodule_progress)
> {
> struct object_id oid;
> @@ -761,6 +785,11 @@ static int checkout(int submodule_progress)
> if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
> die(_
On Fri, Jul 27, 2018 at 10:34:20AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> $ git rebase --onto HEAD @{-1}~3 @{-1}^0
> >
> > Interesting. I'd have probably done it with an interactive rebase:
> >
> > $ git rebase -i HEAD~4
> > [change first "pick" to "edit"; after stopping...
On Fri, Jul 27, 2018 at 10:22:09AM -0700, Stefan Beller wrote:
> > That would solve the problem that fetching torvalds/linux from GitHub
> > yields a bigger pack than fetching it from kernel.org. But again, it's
> > making that root fork weirdly magical. People who fetch solely from
> > other fork
On 07/21, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> The problem solved by the code introduced in this commit goes like this:
> given two sets of items, and a cost matrix which says how much it
> "costs" to assign any given item of the first set to any given item
23 matches
Mail list logo
