git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ilya Basin <basinilya@gmail.com>,
	Git mailing list <git@vger.kernel.org>,
	Ray Chen <rchen@cs.umd.edu>
Subject: Re: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()
Date: Thu, 2 May 2013 02:49:26 +0000	[thread overview]
Message-ID: <20130502024926.GA12172@dcvr.yhbt.net> (raw)
In-Reply-To: <7v1u9q5pu5.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Ilya Basin <basinilya@gmail.com> wrote:
> >> JCH> comment line "# added by git-svn only to keep the directory" and
> >> JCH> consider a directory that has nothing but .gitignore that consists
> >> JCH> of only that exact comment line an "added placeholder" directory to
> >> JCH> work it around.
> >> Sounds good, but it's not I who decided to use the config file.
> >
> > Ugh, I didn't review Ray's original commit closely enough to notice
> > this :x
> >
> > Perhaps we should migrate users to use YAML storage for this, instead
> > (we already use YAML for Git::SVN::Memoize::YAML).
> 
> But does it solve the impedance mismatch between "per tree"
> information and "per project" information?  Unless you key the
> information not just with path but also with revision or tree object
> name, use of YAML vs config would not make a difference in the
> semantics, I am afraid.

No it doesn't solve the impedance mismatch, but the YAML project would
be more flexible than the git config file.

> I am reading the placeholder-added flag as: "This .gitignore file
> does not exist in the Subversion original; it is there only so that
> we can keep the otherwise empty diretory in the checkout, and it
> should not be pushed back to the Subversion side".  Am I mistaken?

You're right, I had forgotten this feature completely :x

> That however is not a property of the directory containing it (or
> the path to that .gitignore file) that is valid throughout the
> history of the project.  It is a property of a specific tree object
> (or you could say it is a property of the revision).  When at some
> point in the history the upstream project adds .gitignore there
> because many people use git-svn to contribute to their project, it
> stops to be "should not be pushed back".
> 
> So it seems to me that the information this "placeholder added"
> thing wants to express belongs to the tree object (and .gitignore
> file itself is a natural place to have that information).

Perhaps that was the better way to go...

How would (the presumably few) existing users of this feature be
affected?

Currently with the config file, there are problems with interop between
git-svn users that do git <-> git repo sharing, an updated version with
the "placeholder added" .gitignore would allow git <-> git repo sharing,
but only between users of newer git versions.  Perhaps that's fine and
better than the current situation.

  reply	other threads:[~2013-05-02  2:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01  5:09 [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list() Ilya Basin
2013-05-01  8:31 ` Re[2]: " Ilya Basin
2013-05-01 17:09   ` Junio C Hamano
2013-05-01 19:51     ` Re[2]: " Ilya Basin
2013-05-01 21:30       ` Eric Wong
2013-05-01 21:53         ` Junio C Hamano
2013-05-02  2:49           ` Eric Wong [this message]
2013-05-02 17:31             ` Re[2]: " Ilya Basin
2013-05-02 20:40               ` Eric Wong
2013-05-03  5:26                 ` Re[2]: " Ilya Basin
2013-05-03  6:42                   ` Re[3]: " Ilya Basin
2013-05-06  8:14                     ` Re[4]: " Ilya Basin
2013-05-06  8:58               ` Re[3]: " Ilya Basin
2013-05-09  1:05                 ` Eric Wong
2013-05-28 12:57                 ` Re[4]: " Ilya Basin
2013-05-02 18:59             ` Ray Chen
2013-05-02  3:51         ` Re[2]: " Ilya Basin
2013-05-02 20:09           ` Eric Wong
  -- strict thread matches above, loose matches on Subject: below --
2013-04-30 17:37 Ilya Basin

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=20130502024926.GA12172@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=basinilya@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=rchen@cs.umd.edu \
    /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).