vim-latex-devel

[Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Gerd W. <ger...@ma...>]

Hi,

after vim-latex changed to git, I want to put my vim configuration in a 
local git repo located at ~/conf. I would like to link ~/.vim to 
~/conf/vim.

Therefore, I have to merge the commits at vim-latex/master:vimfiles/ into 
my local repo at the point master:vim/.

I fiddled arround with git subtree, but I can't get it work. Does anybody 
know, how I can merge the subdirectory vimfiles into my subdirectory vim??

Does anybody else have his vim configuration in a git and merge it with 
the upstream vim-latex?

Regards
Gerd

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Ted P. <te...@te...>]

Since no one else has responded to this yet, I'll add my probably 
useless comments...

> I fiddled arround with git subtree, but I can't get it work. Does anybody
> know, how I can merge the subdirectory vimfiles into my subdirectory vim??

Personally, I'm just using rsync (actually, there's an old Makefile.in 
in the vimfiles directory that includes "install", "stallin", and "sync" 
targets and is already configured for ~/.vim).

I know more about hg than git. In hg, there is a "convert" that allows 
you to map changesets from one repo into changesets in another repo 
while also moving files into an alternate location (of course, this 
process destroys the original changeset ID, and so the id-to-id mapping 
is stored in a file in the target repo). I don't know how to do 
"convert" in git, but I have a feeling you aren't interested in that. 
[There's probably a better way to do what you're talking about doing 
even in Mercurial, but I happen to know about convert because I use it 
to create public versions of some of my private repositories with 
certain files/directories stripped from the change history.]

It does appear like "git submodule" is what you would want to use, but I 
have no experience with using it.

Have you tried posting to the git mailing list? It's very active.

--Ted

-- 
Ted Pavlic <te...@te...>

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Till M. <ope...@ti...>]

On Fri, Feb 18, 2011 at 01:52:37PM -0500, Ted Pavlic wrote:
> > I'm looking forward when Till will put vimfiles/ in a separate repo (or
> > branch). Then I can use the method described in
> 
> It would make sense to split out the web and the vimfiles into two 
> separate repos. However, is that really necessary?

What disadvantages do you see? I am pretty sure that most of vim-latex
users are only interested in the vimfiles directory. With svn it was
straight-forward to checkout only that part of the repository.

The only potential issue I see is that after the splitting of the
repository, they will have different commit ids than the original
repository had. Since the repository is not published that long, I tend
to think that this is not important.


Regards
Till

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Ted P. <te...@te...>]

> I know more about hg than git. In hg, there is a "convert" that allows

In fact, if you were willing to manage your conf repo with Mercurial, 
you could probably use convert to do all of the work for you. The 
simplest thing you'd want would be:

hg convert --filemap vimfiles_only /path/to/vim-latex ~/conf

where the "filemap" is a file that looks like:

include path/to/file-or-dir
exclude path/to/file-or-dir
rename path/to/source path/to/destination

In particular, the file "vimfiles_only" contacts

include "vimfiles"
rename "vimfiles" "vim"

But you could tweak things a bit (branchsort or datesort, for example). 
I don't know of a way to "squash" in hg convert, and so you'd end up 
with a bunch of heads corresponding to each of the unclosed heads of the 
vim-latex. You could --close-branch on each of them if you prefer. 
Otherwise, you can just merge with the most recent head, and I think you 
would be on your way. Run the convert periodically to pull new revisions 
in, and then merge again. That is..

hg update -C old_conf_head
hg merge -r latest_vimfiles_head
hg commit -m "Merge"

I would recommend naming the old branch and the branch holding the 
latest vimfiles head. That will make future merges easier 
(alternatively, you can close the several old vimfiles branches that are 
dead).

I gave it a test run on my system, and it seemed to work.

--Ted

-- 
Ted Pavlic <te...@te...>

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Gerd W. <ger...@ma...>]

Hi,

I'm looking forward when Till will put vimfiles/ in a separate repo (or 
branch). Then I can use the method described in

http://vimcasts.org/episodes/synchronizing-plugins-with-git-submodules-and-pathogen/

This sounds very handy. I think I will also publish my configuration at 
github.

Best Regards
Gerd

On Fri, 18 Feb 2011, Ted Pavlic wrote:

>> I know more about hg than git. In hg, there is a "convert" that allows
>
> In fact, if you were willing to manage your conf repo with Mercurial,
> you could probably use convert to do all of the work for you. The
> simplest thing you'd want would be:
>
> hg convert --filemap vimfiles_only /path/to/vim-latex ~/conf
>
> where the "filemap" is a file that looks like:
>
> include path/to/file-or-dir
> exclude path/to/file-or-dir
> rename path/to/source path/to/destination
>
> In particular, the file "vimfiles_only" contacts
>
> include "vimfiles"
> rename "vimfiles" "vim"
>
> But you could tweak things a bit (branchsort or datesort, for example).
> I don't know of a way to "squash" in hg convert, and so you'd end up
> with a bunch of heads corresponding to each of the unclosed heads of the
> vim-latex. You could --close-branch on each of them if you prefer.
> Otherwise, you can just merge with the most recent head, and I think you
> would be on your way. Run the convert periodically to pull new revisions
> in, and then merge again. That is..
>
> hg update -C old_conf_head
> hg merge -r latest_vimfiles_head
> hg commit -m "Merge"
>
> I would recommend naming the old branch and the branch holding the
> latest vimfiles head. That will make future merges easier
> (alternatively, you can close the several old vimfiles branches that are
> dead).
>
> I gave it a test run on my system, and it seemed to work.
>
> --Ted
>
>

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Ted P. <te...@te...>]

> I'm looking forward when Till will put vimfiles/ in a separate repo (or
> branch). Then I can use the method described in

It would make sense to split out the web and the vimfiles into two 
separate repos. However, is that really necessary?

I haven't used pathogen before, but it looks like you could just symlink 
the vimfiles directory from vim-files into your ~/.vim/bundle. At least 
in the near term, I think that would work. <?>

> http://vimcasts.org/episodes/synchronizing-plugins-with-git-submodules-and-pathogen/

(regarding hosting on github, you could still manage your conf in 
Mercurial (with the imported changesets from vim-latex.git) and publish 
it on Google Code/etc.)

--Ted


-- 
Ted Pavlic <te...@te...>

   Please visit my 2010 d'Feet ALS walk page:
         http://web.alsa.org/goto/tpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Ted P. <te...@te...>]

>> It would make sense to split out the web and the vimfiles into two
>> separate repos. However, is that really necessary?
>
> What disadvantages do you see? I am pretty sure that most of vim-latex

None aside from the grunt work. My comment was sort of an "in the 
meanwhile, symlinks with pathogen should work."

> The only potential issue I see is that after the splitting of the
> repository, they will have different commit ids than the original
> repository had. Since the repository is not published that long, I tend
> to think that this is not important.

That probably won't be much of an issue... Aside from the fact that it 
will create a new head when anyone pulls down the new repo (hopefully 
that wouldn't confuse any automated package managers, like Arch Linux's 
yaourt (there is already a vim-latex-git on AUR)).

Alternatively, you could keep the htdocs in the history. Clone the 
current repo into two, and then (within each clone) move the files to 
their desired locations and commit the changes. Of course, you probably 
don't need to maintain the changelog within the new "vim-latex-htdocs" 
repo, and so that one could be split out regardless.

--Ted

-- 
Ted Pavlic <te...@te...>

Re: [Vim-latex-devel] Merging vim-latex/master:vimfiles into local repo

[Gerd W. <ger...@ma...>]

>> The only potential issue I see is that after the splitting of the
>> repository, they will have different commit ids than the original
>> repository had. Since the repository is not published that long, I tend
>> to think that this is not important.
>
> That probably won't be much of an issue... Aside from the fact that it
> will create a new head when anyone pulls down the new repo (hopefully
> that wouldn't confuse any automated package managers, like Arch Linux's
> yaourt (there is already a vim-latex-git on AUR)).
>
> Alternatively, you could keep the htdocs in the history. Clone the
> current repo into two, and then (within each clone) move the files to
> their desired locations and commit the changes. Of course, you probably
> don't need to maintain the changelog within the new "vim-latex-htdocs"
> repo, and so that one could be split out regardless.

I think, one could separate both repos with "git filter-branch". For the 
vimfiles a "--subdirectory-filter vimfiles/" will work and for the 
remaining part one has to use '--tree-filter "rm -rf vimfiles"'. This 
split the repo into two and preserves all commit/log entries. Both repos 
do not know the history of the other one - thus there is no "history 
overhead".

Regards
Gerd