On Thu, Jul 2, 2015 at 8:50 AM, Duy Nguyen <[email protected]> wrote:
> On Thu, Jul 2, 2015 at 7:41 PM, Duy Nguyen <[email protected]> wrote:
>>> merge_working_tree:
>>> tree = parse_tree_indirect(old->commit &&
>>> !opts->new_worktree_mode ?
>>> old->commit->object.sha1 :
>>> EMPTY_TREE_SHA1_BIN);
>>
>> I think it's to make sure empty sha-1 is used with --to. If
>> old->commit->object.sha1 is used and it's something, a real two way
>> merge may happen probably with not-so-fun consequences. If it's empty
>> sha1, the effect is like "reset --hard", silent and reliable..
>>
>>> switch_branches:
>>> if (!opts->quiet && !old.path && old.commit &&
>>> new->commit != old.commit && !opts->new_worktree_mode)
>>> orphaned_commit_warning(old.commit, new->commit);
>>
>> to suppress misleading warning if old.commit happens to be something.
>
> Actually you may be right about not reverting these. We prepare the
> new worktree with a valid HEAD, that would make "old" valid and may
> trigger things if "git checkout" is used to populate the worktree. To
> suppress those "things", we need new_worktree_mode or something
> similar.
Indeed. Since this is merely a private implementation detail, we don't
necessarily have to resolve the issue fully for the "checkout --to" to
"worktree add" conversion. It can be dealt with in a follow-on patch.
> Unless we want to borrow fancy checkout options for "git worktree
> add", we probably should just export checkout() function from clone.c
> and use it instead of "git checkout". Much more lightweight and
> simpler (it's one-way merge). Then we can revert checkout.c to the
> version before "--to".
Interesting idea, but doesn't this lose the ability to create a new
branch ("worktree add foo -b bar") and other useful options like
--track?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
