Torsten Bögershausen writes:
>> There's less redundant work going on than at first seems, because
>> .gitattribute files are only read once and cached. Verified by strace.
>>
> OK, I think I missed that work (not enough time for Git at the moment)
> Junio, please help me out, do we have a cache h
On 07/13/2016 12:20 AM, Joey Hess wrote:
Torsten Bögershausen wrote re jh/clean-smudge-annex:
The thing is that we need to check the file system to find .gitatttibutes,
even if we just did it 1 nanosecond ago.
So the .gitattributes is done 3 times:
-1 would_convert_to_git_filter_fd(
-2 assert
Torsten Bögershausen wrote re jh/clean-smudge-annex:
> The thing is that we need to check the file system to find .gitatttibutes,
> even if we just did it 1 nanosecond ago.
>
> So the .gitattributes is done 3 times:
> -1 would_convert_to_git_filter_fd(
> -2 assert(would_convert_to_git_filter_fd(pa
Michael Haggerty writes:
> (I suppose that `REFNAME_ALLOW_ONELEVEL` was
> meant for checking partial reference names, for example to vet "foo"
> that the caller wants to pass to `git branch`, which automatically turns
> it into `refs/heads/foo`.)
Correct.
> In summary, `check_refname_format()`
On 06/23/2016 09:32 AM, Michael Haggerty wrote:
> [...]
> I have to say, I'm still confused about how the old code could have
> worked at all. For quite some time, Git hasn't allowed references with
> weird names like `git-p4-tmp/6` to be created, so how could there be any
> references there that n
Michael Haggerty writes:
> I'd like to request that the change for the p4 temprefs be made in two
> steps:
>
> 1. Write references to `refs/git-p4-tmp` or whatever, without
>worrying about making them per-worktree.
>
> 2. Carve out a per-worktree namespace, bikeshed about its name and
>se
> On 23 Jun 2016, at 09:32, Michael Haggerty wrote:
>
> On 06/20/2016 09:57 AM, Lars Schneider wrote:
>>
>>> On 20 Jun 2016, at 01:51, Junio C Hamano wrote:
>>>
>>> Junio C Hamano writes:
>>>
Michael Haggerty writes:
> According to [1], something in that test seems to have b
On 22/06/16 23:09, Joey Hess wrote:
Torsten Bögershausen wrote:
There is a conflict in pu:
"jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
(And currently pu didn't compile)
I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of
tb/convert-peek-in-i
On 06/20/2016 09:57 AM, Lars Schneider wrote:
>
>> On 20 Jun 2016, at 01:51, Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>>
>>> Michael Haggerty writes:
>>>
According to [1], something in that test seems to have been trying to run
git update-ref -d git-p4-tmp/6
>>>
Torsten Bögershausen wrote:
> There is a conflict in pu:
> "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
>
> (And currently pu didn't compile)
I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of
tb/convert-peek-in-index to fix this.
> (I will hope
Torsten Bögershausen writes:
> There is a conflict in pu:
> "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
>
> (And currently pu didn't compile)
Thanks for a report, but didn't I mention this breakage in the
What's cooking report already?
--
To unsubscribe from th
> On 20 Jun 2016, at 01:51, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> Michael Haggerty writes:
>>
>>> According to [1], something in that test seems to have been trying to run
>>>
>>>git update-ref -d git-p4-tmp/6
>>>
>>> Similarly in the other failed test.
>>
>> Ah, OK, t
There is a conflict in pu:
"jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
(And currently pu didn't compile)
(I will hopefully be able to do a separate review of the smudge/clean patch)
(And jo...@joeyh.name is not reachable from web.de)
--
To unsubscribe from t
Junio C Hamano writes:
> Michael Haggerty writes:
>
>> According to [1], something in that test seems to have been trying to run
>>
>> git update-ref -d git-p4-tmp/6
>>
>> Similarly in the other failed test.
>
> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is
> not a place
> On 19 Jun 2016, at 20:49, Lars Schneider wrote:
>
>
>> On 19 Jun 2016, at 20:13, Junio C Hamano wrote:
>>
>> Lars Schneider writes:
>>
>>> This seems to fix the issue:
>>>
>>> --- a/git-p4.py
>>> +++ b/git-p4.py
>>> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):
>>>self.
> On 19 Jun 2016, at 20:13, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> This seems to fix the issue:
>>
>> --- a/git-p4.py
>> +++ b/git-p4.py
>> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):
>> self.useClientSpec_from_options = False
>> self.clientSpecDirs
Lars Schneider writes:
> This seems to fix the issue:
>
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):
> self.useClientSpec_from_options = False
> self.clientSpecDirs = None
> self.tempBranches = []
> -self.tempBran
Michael Haggerty writes:
> According to [1], something in that test seems to have been trying to run
>
> git update-ref -d git-p4-tmp/6
>
> Similarly in the other failed test.
Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is
not a place to have a ref. It will not participat
Michael Haggerty writes:
>> Good timing. I was planning to kick split-under-lock and any of its
>> dependents temporarily out of 'next', so that fixes can choose not
>> to be incremental, and dependent topics can be rebased on top of the
>> fixed fondation. Even if we do incremental, [4] is not
> On 19 Jun 2016, at 17:04, Lars Schneider wrote:
>
>
>> On 19 Jun 2016, at 09:59, Michael Haggerty wrote:
>>
>> On 06/18/2016 12:05 AM, Lars Schneider wrote:
>>>
On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
...
* mh/split-under-lock (2016-05-13) 33 commits
>>>
> On 19 Jun 2016, at 09:59, Michael Haggerty wrote:
>
> On 06/18/2016 12:05 AM, Lars Schneider wrote:
>>
>>> On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
>>>
>>> ...
>>>
>>> * mh/split-under-lock (2016-05-13) 33 commits
>>> ...
>>>
>>> Further preparatory work on the refs API before the
On 06/18/2016 08:20 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 06/17/2016 05:20 AM, Junio C Hamano wrote:
>>> [...]
>>> * mh/ref-iterators (2016-06-03) 13 commits
>>> (merged to 'next' on 2016-06-06 at c8e79dc)
>>> + ...
>>> (this branch is used by mh/ref-store; uses mh/spli
On 06/18/2016 12:05 AM, Lars Schneider wrote:
>
>> On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
>>
>> ...
>>
>> * mh/split-under-lock (2016-05-13) 33 commits
>> (merged to 'next' on 2016-06-03 at 2e71330)
>> + lock_ref_sha1_basic(): only handle REF_NODEREF mode
>> + commit_ref_update(): remov
Michael Haggerty writes:
> On 06/17/2016 05:20 AM, Junio C Hamano wrote:
>> [...]
>> * mh/ref-iterators (2016-06-03) 13 commits
>> (merged to 'next' on 2016-06-06 at c8e79dc)
>> + ...
>> (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled
>> with mh/update-ref-errors.)
On 06/18/2016 12:05 AM, Lars Schneider wrote:
>
>> On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
>>
>> ...
>>
>> * mh/split-under-lock (2016-05-13) 33 commits
>> (merged to 'next' on 2016-06-03 at 2e71330)
>> [...]
>
> This topic seems break two git-p4 tests (t9801 and t9803) on next:
> https
On 06/17/2016 05:20 AM, Junio C Hamano wrote:
> [...]
> * mh/ref-iterators (2016-06-03) 13 commits
> (merged to 'next' on 2016-06-06 at c8e79dc)
> + for_each_reflog(): reimplement using iterators
> + dir_iterator: new API for iterating over a directory tree
> + for_each_reflog(): don't abort f
Lars Schneider writes:
>> On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
>>
>> ...
>>
>> * mh/split-under-lock (2016-05-13) 33 commits
>> (merged to 'next' on 2016-06-03 at 2e71330)
>> + lock_ref_sha1_basic(): only handle REF_NODEREF mode
>> + ...
>> + t1404: demonstrate a bug resolving refe
> On 17 Jun 2016, at 05:20, Junio C Hamano wrote:
>
> ...
>
> * mh/split-under-lock (2016-05-13) 33 commits
> (merged to 'next' on 2016-06-03 at 2e71330)
> + lock_ref_sha1_basic(): only handle REF_NODEREF mode
> + commit_ref_update(): remove the flags parameter
> + lock_ref_for_update(): don't
Junio C Hamano pobox.com> writes:
> * va/i18n-even-more (2016-06-07) 38 commits
> - i18n: branch: mark comment when editing branch description for translation
> - i18n: unmark die messages for translation
> - i18n: submodule: escape shell variables inside eval_gettext
> - i18n: submodule: join
Hey Junio,
On Fri, Jun 17, 2016 at 8:50 AM, Junio C Hamano wrote:
> * pb/bisect (2016-05-24) 3 commits
> - bisect--helper: `write_terms` shell function in C
> - bisect: rewrite `check_term_format` shell function in C
> - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
>
> Beginning of GS
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.
Let's start a new cycle by rewindi
31 matches
Mail list logo
