git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/5] Add 'df_name_compare()' helper function
Date: Thu, 06 Mar 2008 14:03:56 +0100	[thread overview]
Message-ID: <8563w03sxv.fsf@lola.goethe.zz> (raw)
In-Reply-To: <b1cd18fa986c63bea6d0a20ac580b993e5fffaa2.1204777699.git.torvalds@linux-foundation.org> (Linus Torvalds's message of "Wed, 5 Mar 2008 18:25:10 -0800")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> This new helper is identical to base_name_compare(), except it compares
> conflicting directory/file entries as equal in order to help handling DF
> conflicts (thus the name).
>
> Note that while a directory name compares as equal to a regular file
> with the new helper, they then individually compare _differently_ to a
> filename that has a dot after the basename (because '\0' < '.' < '/').

Uh, that screams just bloody murder at me with regard to working on
sorted material.  You'll never even get into the situation where the
conflicting "equal" entries will be compared if you presorted them with
something in between.  Consider the case of a merge of

A:
blubb
blubb.hi

B:
blubb.hi
blubb/

Any traversal that is done reasonably efficiently will never compare
blubb to blubb/ and I don't see how to get around this.

Basically, I think you need a special traversal routine.  This routine
will push all non-directory entries during a parallel traverse into a
might-conflict-queue, appending a slash in the course.  The front of
this queue then gets compared with the next processed entry.  If it is
larger, it is kept at the front, if it is equal, the conflict gets
treated/resolved, if it is smaller, it gets popped (since it can't
conflict anymore).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2008-03-06 15:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06  4:28 [PATCH 0/5] Split-up "unpack_trees()" cleanup series Linus Torvalds
2008-03-06  2:25 ` [PATCH 1/5] Add 'df_name_compare()' helper function Linus Torvalds
2008-03-06 13:03   ` David Kastrup [this message]
2008-03-06 15:58     ` Linus Torvalds
2008-03-06 21:50       ` David Kastrup
2008-03-06  2:59 ` [PATCH 2/5] Make 'traverse_tree()' use linked structure rather than 'const char *base' Linus Torvalds
2008-03-06  3:44 ` [PATCH 3/5] Add return value to 'traverse_tree()' callback Linus Torvalds
2008-03-06  4:06 ` [PATCH 4/5] Make 'traverse_trees()' traverse conflicting DF entries in parallel Linus Torvalds
2008-03-06  4:15 ` [PATCH 5/5] Move 'unpack_trees()' over to 'traverse_trees()' interface Linus Torvalds
2008-03-06  4:51 ` [PATCH 0/5] Split-up "unpack_trees()" cleanup series Linus Torvalds
2008-03-07  0:13 ` Daniel Barkalow
2008-03-07  2:04   ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8563w03sxv.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).