Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:26

Junio C Hamano [off-list ref] writes:
Duy Nguyen [off-list ref] writes:
quoted
On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano [off-list ref] wrote:
quoted
* nd/multiple-work-trees (2014-07-29) 39 commits

 Reroll posted, but haven't picked up yet.  How would this interact
 with rr/transaction series which is pretty much all about the refs?
Haven't checked out that topic yet. But ref changes in
multiple-work-trees are to make sure ref path construction goess
through git_path(), and some cleaning up after strbuf_git_path() is
introduced. So basically textual conflicts only.
Up to the point that is queued on 'pu', the other topic(s) still
keep the assumption that all refs are files in $GIT_DIR/refs/, and I
think I managed the textual conflicts correctly in 'pu' before.
One point that caused unnecessary conflict resolution was that the
transaction series lacked "let's use strbuf to hold paths".  This
had two immediate side effects, i.e. "instead of returning upon
errors, jump to the end with 'goto done/fail' for necessary
clean-up" and "get rid of git_snpath and use strbuf_git_path", both
of which are good general clean-ups, even if they weren't related to
the multiple worktrees feature, that conflicted with the transaction
series when getting merged.

You can see the interactions by checking

    $ git show 'pu^{/^Merge branch .nd/multi}' refs.c

Perhaps these three changes, without the addition of the multiple
worktree feature, should come first as a general clean-up on top of
which both topics can be built?
But starting from $gmane/255476 the assumption gradually gets lifted
and eventually we may have refs and reflogs expressed in a different
backend, without these files that represent the refs at all.

I am not yet sure how this "I have $GIR_DIR/ but that is not a real
one but borrows most of the stuff from elsewhere" meshes with that
new world.

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

From: Duy Nguyen <hidden>
Date: 2016-06-15 23:02:26

On Fri, Sep 5, 2014 at 12:14 AM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Duy Nguyen [off-list ref] writes:
quoted
On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano [off-list ref] wrote:
quoted
* nd/multiple-work-trees (2014-07-29) 39 commits

 Reroll posted, but haven't picked up yet.  How would this interact
 with rr/transaction series which is pretty much all about the refs?
Haven't checked out that topic yet. But ref changes in
multiple-work-trees are to make sure ref path construction goess
through git_path(), and some cleaning up after strbuf_git_path() is
introduced. So basically textual conflicts only.
Up to the point that is queued on 'pu', the other topic(s) still
keep the assumption that all refs are files in $GIT_DIR/refs/, and I
think I managed the textual conflicts correctly in 'pu' before.
One point that caused unnecessary conflict resolution was that the
transaction series lacked "let's use strbuf to hold paths".  This
had two immediate side effects, i.e. "instead of returning upon
errors, jump to the end with 'goto done/fail' for necessary
clean-up" and "get rid of git_snpath and use strbuf_git_path", both
of which are good general clean-ups, even if they weren't related to
the multiple worktrees feature, that conflicted with the transaction
series when getting merged.

You can see the interactions by checking

    $ git show 'pu^{/^Merge branch .nd/multi}' refs.c

Perhaps these three changes, without the addition of the multiple
worktree feature, should come first as a general clean-up on top of
which both topics can be built?
If that makes your life easier, sure. Changes up until (and including)
c88c438 (setup.c: convert is_git_directory() to use strbuf -
2014-08-30) could be considered cleanups. After that commit, refs.c is
not touched. Will look at your conflict resultion later..
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help