Thread (11 messages) flat view 11 messages, 4 authors, 2016-06-15

Re: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

From: Eric Wong <hidden>
Date: 2016-06-15 22:57:06

Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
Ilya Basin [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help