Johan Herland writes:
>> Actually, the name "linked worktree" is probably a misnomer.
>> ...
> Makes sense, although currently, IINM, those multiple $GIT_DIRs must
> be associated with strictly different branches, which is completely
> unrelated to the desired notes-merge restriction (which appli
On Wed, Jul 29, 2015 at 6:37 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote:
>>> Johan Herland writes:
>>>
I believe it is a bad compromise. It complicates the code, and it
provides a concurrent notes merges that is unnecessa
Junio C Hamano writes:
> If we do not change anything (not even applying the [v3 2/6] patch
> we are discussing),...
This one and...
> If there are reasons/limitations that make simultaneous "notes
> merge" of different notes in different $GIT_DIRs impossible, then I
> agree we shouldn't bother
Johan Herland writes:
> On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote:
>> Johan Herland writes:
>>
>>> I believe it is a bad compromise. It complicates the code, and it
>>> provides a concurrent notes merges that is unnecessarily tied to (and
>>> dependent on) worktrees. For example, if
On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> I believe it is a bad compromise. It complicates the code, and it
>> provides a concurrent notes merges that is unnecessarily tied to (and
>> dependent on) worktrees. For example, if I wanted to perform N
>> concu
Johan Herland writes:
> I believe it is a bad compromise. It complicates the code, and it
> provides a concurrent notes merges that is unnecessarily tied to (and
> dependent on) worktrees. For example, if I wanted to perform N
> concurrent notes merges in a project that happens to have a huge
> w
Johan Herland writes:
> On Wed, Jul 29, 2015 at 4:00 AM, Junio C Hamano wrote:
>
>> So doing the absolute minimum, leaving the "now what can we do to
>> improve notes-merge process?" outside the scope of the topic.
>
> That's exactly what I was also trying to do: David's topic should not
> have
On Wed, Jul 29, 2015 at 4:00 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> It sounds like what a notes merge really wants is a new linked worktree
>> that has branch refs/notes/foo checked out:
>>
>> * This would allow multiple notes merges to take place at the same time
>> provided the
On Wed, Jul 29, 2015 at 4:17 AM, Junio C Hamano wrote:
> Perhaps you meant by "per repo" to mean "per $GIT_DIR" in this
> message, and if that is the case, then I think we are in agreement.
No, by per repo I mean per $GIT_COMMON_DIR (I haven't followed the
linked worktree effort, so this language
On Wed, Jul 29, 2015 at 2:33 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>> ...
>> This is not the case for notes merges. If I start a notes merge from
Johan Herland writes:
> Yes, almost. There are some complications with the concept of
> "checking out" a notes tree:
>
> - The notes tree fanout must be flattened (so that when merging two
> note trees with different fanout, conflicting notes (e.g. deadbeef...
> and de/adbeef) are turned int
Johan Herland writes:
> In fact, you can easily do a notes merge in a _bare_ repo...
You keep repeating that but I do not think it is relevant at all.
If you have a bare repository, you either
(1) do not have any worktree associated with it; or
(2) have worktrees associated with it elsewher
Michael Haggerty writes:
> It sounds like what a notes merge really wants is a new linked worktree
> that has branch refs/notes/foo checked out:
>
> * This would allow multiple notes merges to take place at the same time
> provided they target different merge references.
>
> * This would prevent
On Wed, Jul 29, 2015 at 2:56 AM, Michael Haggerty wrote:
> Johan Herland writes:
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>
> It sounds like what a notes merge really wants is a new linked worktree
> t
On Tue, Jul 28, 2015 at 5:56 PM, Michael Haggerty wrote:
> Johan Herland writes:
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>
> It sounds like what a notes merge really wants is a new linked worktree
> t
Johan Herland writes:
> Here is where we start to differ. I would say that starting a notes
> merge is completely unrelated to your worktree. Consider this:
It sounds like what a notes merge really wants is a new linked worktree
that has branch refs/notes/foo checked out:
* This would allow mult
Johan Herland writes:
> Here is where we start to differ. I would say that starting a notes
> merge is completely unrelated to your worktree. Consider this:
> ...
> This is not the case for notes merges. If I start a notes merge from
> worktree A, there is no "occupation" of that worktree. Before
On Wed, Jul 29, 2015 at 12:52 AM, Junio C Hamano wrote:
> Johan Herland writes:
>> However, in any case, notes merges are always per _repo_ and never per
>> _worktree_, so this is all unrelated to the current patch/discussion
>> AFAICS.
>
> Thanks for chiming in, but I actually think you are conf
Johan Herland writes:
Johan Herland writes:
> However, in any case, notes merges are always per _repo_ and never per
> _worktree_, so this is all unrelated to the current patch/discussion
> AFAICS.
Thanks for chiming in, but I actually think you are confused.
"git merge" is always per _repo_
On Tue, Jul 28, 2015 at 9:44 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>> David Turner writes:
>>> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
>>> per-worktree. We don't want multiple notes merges happening at once
>>> (in different worktrees), so we want to make t
Junio C Hamano writes:
> David Turner writes:
>
>> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
>> per-worktree. We don't want multiple notes merges happening at once
>> (in different worktrees), so we want to make these refs true refs.
>> ...
> The two "rev-parse --verify"
On Tue, 2015-07-28 at 12:00 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
> > per-worktree. We don't want multiple notes merges happening at once
> > (in different worktrees), so we want to make these refs true refs.
>
David Turner writes:
> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
> per-worktree. We don't want multiple notes merges happening at once
> (in different worktrees), so we want to make these refs true refs.
>
> So, we lowercase NOTES_MERGE_REF and friends. That way, backends
All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
per-worktree. We don't want multiple notes merges happening at once
(in different worktrees), so we want to make these refs true refs.
So, we lowercase NOTES_MERGE_REF and friends. That way, backends
that distinguish between pseudo
24 matches
Mail list logo
