* git-svn feature request: exclude certain subpaths on clone
@ 2008-12-04 16:43 Wade Berrier
2008-12-06 0:13 ` Eric Wong
0 siblings, 1 reply; 2+ messages in thread
From: Wade Berrier @ 2008-12-04 16:43 UTC (permalink / raw)
To: git
Hi,
Consider the following example layout:
trunk/src
trunk/big_fat_binary_blobs
trunk/doc
I think it would be really nice to be able to tell git-svn to ignore
'big_fat_binary_blobs' while keeping 'src' and 'doc'.
I know someone is thinking, "Why did you check in
'big_fat_binary_blobs' in the first place?" In this case, the
repository is out of my control. For the svn users, it's not that big
of a deal since they only get one HEAD version of the binary_blobs.
But when trying to clone with git-svn, I repeatedly get out of memory
and packing errors (every 1000 commits) when packing several revisions
of these binary_blobs. (Now, that may be a bug in of itself... which
can reproduced by creating an svn repo with several revisions of
KNOPPIX at the same path, followed by a git svn clone )
Anyway, I still think it may be useful to be able to ignore certain
paths on a clone. In thinking about the implementation details, I
figure probably the best approach would be to manually purge the
unwanted path after it has been fetched, but before it is committed.
That way, if a commit contains changes in paths that are both wanted
and unwanted, the commit could be 'pruned'.
I've looked at the git-svn script a little, but wanted to solicit
feedback and ideas before continuing further.
Thoughts?
Wade
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: git-svn feature request: exclude certain subpaths on clone
2008-12-04 16:43 git-svn feature request: exclude certain subpaths on clone Wade Berrier
@ 2008-12-06 0:13 ` Eric Wong
0 siblings, 0 replies; 2+ messages in thread
From: Eric Wong @ 2008-12-06 0:13 UTC (permalink / raw)
To: Wade Berrier; +Cc: git
Wade Berrier <wberrier@gmail.com> wrote:
> Hi,
>
> Consider the following example layout:
>
> trunk/src
> trunk/big_fat_binary_blobs
> trunk/doc
>
> I think it would be really nice to be able to tell git-svn to ignore
> 'big_fat_binary_blobs' while keeping 'src' and 'doc'.
>
> I know someone is thinking, "Why did you check in
> 'big_fat_binary_blobs' in the first place?" In this case, the
> repository is out of my control. For the svn users, it's not that big
> of a deal since they only get one HEAD version of the binary_blobs.
> But when trying to clone with git-svn, I repeatedly get out of memory
> and packing errors (every 1000 commits) when packing several revisions
> of these binary_blobs. (Now, that may be a bug in of itself... which
> can reproduced by creating an svn repo with several revisions of
> KNOPPIX at the same path, followed by a git svn clone )
>
> Anyway, I still think it may be useful to be able to ignore certain
> paths on a clone. In thinking about the implementation details, I
> figure probably the best approach would be to manually purge the
> unwanted path after it has been fetched, but before it is committed.
> That way, if a commit contains changes in paths that are both wanted
> and unwanted, the commit could be 'pruned'.
>
> I've looked at the git-svn script a little, but wanted to solicit
> feedback and ideas before continuing further.
Maybe... What about git-filter-branch?
I realize that doing it at the git-svn level can save bandwidth; but it
might not be possible with the way SVN deltas work...
I'll try to get around to splitting git-svn.perl out to separate source
files this weekend so it's easier to navigate.
--
Eric Wong
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-12-06 0:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-04 16:43 git-svn feature request: exclude certain subpaths on clone Wade Berrier
2008-12-06 0:13 ` Eric Wong
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 NNTP newsgroup(s).