From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Git Mailing List <git@vger.kernel.org>,
Fredrik Kuivinen <freku045@student.liu.se>
Subject: Re: [PATCH] Use git-update-ref in scripts.
Date: Wed, 28 Sep 2005 12:47:12 -0700 [thread overview]
Message-ID: <7vek79q8jj.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vk6h1rr9l.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Wed, 28 Sep 2005 11:17:26 -0700")
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Wed, 28 Sep 2005, Junio C Hamano wrote:
>>>
>> I don't like doing the diff before-hand, but it looked like the default
>> was to try just one strategy, and avoid the diff in that case.
>
> By 'diff before-hand' I take it to mean the savestate for later
> rounds to keep the pre-merge state. You are correct that it is
> not done in a single strategy case, and 'git pull' by default
> would use only one of Daniel's git-merge-resolve or in the
> multi-remote case git-merge-octopus, depending on the number of
> heads being merged. BTW, I decided not to use diff, just in
> case somebody has binary blob we cannot reproduce with diff and
> patch.
I see two more diffs that turns out to be problematic in
git-merge.sh code.
(1) As a safety measure I have a check to make sure the index
is in sync with $head. This visibly hurts; on my slow disk
and CPU with a couple of locally modified paths in the
working tree, this check takes about a second in the kernel
tree with hot cache.
git-merge-resolve uses "git-read-tree -u -m O A B" form, so
this is totally unnecessary. I am not so sure about
Fredrik's git-merge-recursive (I haven't looked at it for a
while).
(2) savestate uses "git diff $head" to find out the list of
paths that have local modifications, but the current code
calls it after the check described above, so "git-ls-files
-m" is enough. On a kernel tree with hot cache and index
in sync with HEAD, "git-ls-files -m" is about 3-4 times as
fast with a couple of locally modified files.
Keeping (1) and using 'git-ls-files -m' in (2) is optimizing for
a wrong path. On the other hand, (1) is a safety measure, and
if it is kept (2) becomes a quite cheap operation.
I am inclined to just remove the check in (1), and make it the
responsibility of merge strategies to make sure it does not
commit unrelated changes.
Comments?
next prev parent reply other threads:[~2005-09-28 19:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-25 18:43 Add "git-update-ref" to update the HEAD (or other) ref Linus Torvalds
2005-09-25 19:05 ` Linus Torvalds
2005-09-25 22:37 ` Junio C Hamano
2005-09-28 2:45 ` [PATCH] Use git-update-ref in scripts Junio C Hamano
2005-09-28 15:21 ` Linus Torvalds
2005-09-28 16:56 ` Junio C Hamano
2005-09-28 17:13 ` Linus Torvalds
2005-09-28 17:29 ` Junio C Hamano
2005-09-28 18:14 ` Linus Torvalds
2005-09-28 18:28 ` Junio C Hamano
2005-09-29 16:07 ` Linus Torvalds
2005-09-28 18:17 ` Junio C Hamano
2005-09-28 19:47 ` Junio C Hamano [this message]
2005-09-28 21:19 ` Fredrik Kuivinen
2005-09-29 15:16 ` Linus Torvalds
2005-09-25 23:27 ` Add "git-update-ref" to update the HEAD (or other) ref Junio C Hamano
2005-09-26 0:50 ` Linus Torvalds
2005-09-26 4:25 ` Junio C Hamano
2005-09-26 1:07 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vek79q8jj.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=freku045@student.liu.se \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox