var-tabstops
Tobia Conforto
Has anybody had any success in merging the var-tabstops branch with
MacVim? I thought it would be easy, as the two branches must have a
common ancestor, but when I tried it gave me endless conflicts. What
am I missing? If anybody knows any better, any help is appreciated.
git://repo.or.cz/vim_extended.git/refs/heads/feat/var-tabstops
This is an unofficial branch which adds a 'tabstops' option, to set a
list of tab stops instead of a single value (for example, the first
stop at 8, then at 20, 50...) It's most useful when editing tab-
separated values or other tabular data, especially when combined with
some vimscript to auto-detect the optimal list of tab stops.
Tobia
björn
>
> Has anybody had any success in merging the var-tabstops branch with
> MacVim? I thought it would be easy, as the two branches must have a
> common ancestor, but when I tried it gave me endless conflicts. What
> am I missing? If anybody knows any better, any help is appreciated.
>
> git://repo.or.cz/vim_extended.git/refs/heads/feat/var-tabstops
Tobia,
The MacVim repo is not based on the vim_extended repo (it was created
after I set up the MacVim repo). There was a discussion on vim_dev a
while back regarding rebasing MacVim.git on top of vim_extended.git
which would simplify the merging of unofficial patches, but I find
this dask rather daunting. As far as I can tell, the only way to
accomplish this is to apply all MacVim.git commits as a series of
patches on top of vim_extended.git and this way I'll loose all dates
when each MacVim commit was performed (they'll all have the same
date).
If somebody were to tell me how to "merge" the two repositories whilst
retaining all original commit information from the MacVim.git repo I'd
consider doing this, but until then it is easier for me to simply keep
things the way they are.
Björn
Tobia Conforto
I'm not sure what's the best way of doing it either, but your idea
sounds good. Did you investigate the possibility of faking the commit
dates?
Seeing as Git is a distributed system, I don't see why you shouldn't
be able to set arbitrary commit dates, with a custom rebasing script.
At worst, you'll have to compile a custom git, hacking around the
getdate() call, to accept a commandline parameter with the date to
use. Then, after the macvim patches are rebased on top of an old vim-
extended commit, automatic merges (both ways) will be possible. The
only real downside is that all commits would change hash.
In my case, I'll try to see if vim_extended tracks vim trunk someway,
then I'll format a patch from the branch I'm interested in and apply
it to macvim. That should be smoother.
Tobia
René Köcher
Pleas, both of you -- stop reinventing the wheel!
Git has two tools working hand in hand to just do what is needed:
#1 is git format-patch which will transform a series of commits into mailbox-formated
messages containing the specified commit as a patch
#2 is git am which will import (re-apply) the patches in a given directory in order.
git am has a switch to explicitly *not* use the original commit date:
--ignore-date
By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date.
This allows the user to lie about the author date by using the same value as the committer date.
Which basically means - you can convert the whole vim_mac repo into patches (one per commit).
Put them into a directory and then apply them to another repository using git am.
If all goes well you will end up with a repository containing all patches with their
respective author and original commit date.
Cheers,
----------------------------------------------------------------------------------
BitSpinn.org - don't get twisted up!
----------------------------------------------------------------------------------
björn
>
> Pleas, both of you -- stop reinventing the wheel!
>
> Git has two tools working hand in hand to just do what is needed:
>
> #1 is git format-patch which will transform a series of commits into mailbox-formated
> messages containing the specified commit as a patch
> #2 is git am which will import (re-apply) the patches in a given directory in order.
This is exactly what I was referring to in my email and what has
already been done [1].
> git am has a switch to explicitly *not* use the original commit date:
>
> --ignore-date
> By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date.
> This allows the user to lie about the author date by using the same value as the committer date.
>
> Which basically means - you can convert the whole vim_mac repo into patches (one per commit).
> Put them into a directory and then apply them to another repository using git am.
Aha! But here is a switch I did not know about! Thanks for pointing
it out. I'll look into this when I get the time. But...this is not
something I enjoy doing so it will take a while before I get around to
fiddling around with this. (And I know that there are multiple
conflicts due to the fact that I merge the latest runtime updates into
the "vim" branch in MacVim.git.)
Another problem is that Markus explicitly points out that he'll
rewrite the entire vim_mainline repository at some point in the future
[2] and I'm not sure what kind of problems this would cause me.
Björn
[1] http://repo.or.cz/w/MacVim_ext.git
[2] http://repo.or.cz/w/vim_mainline.git