Christian MICHON, 23.12.2008:
>
> On Mon, Dec 22, 2008 at 2:31 PM, Markus Heidelberg
> <markus.heidelb...@web.de> wrote:
> > http://repo.or.cz/w/vim_mainline.git
>
> nice to see another git repo for vim :)
> how often do you synchronize it ?
When I see a patch on the list, I look whether the svn repo is updated
and then normally merge and push it. The last patch 7.2.070 is already
in svn, but I haven't merged it yet, because of the work on the runtime
branch.
> quick feedback after a cloning of vim_mainline: tons of commits are
> due to git-svn merged commits and syncing with CVS.
> could this be avoided ? maybe some commits can be squashed.
Why should I squash only to loose/cripple history? Furthermore squashing
makes sense for something like topic branches, which are deleted
afterwards. The git repo is based on the official svn repo. The
'git-svn' branch, that is merged into the 'vim' branch, directly
reflects the svn branch 'vim7.2' and is not a topic branch. A branch
('vim') cannot be based on another ('git-svn') when I squash commits. I
just have to merge.
The reason for all the "git-svn merged" merge commits is that the 'vim'
branch is not totally equal to 'git-svn'. It contains two additional
commits, so it can't resolve as a fast-forward merge anymore and
"git-svn merged" commits are created.
Being based on the svn repo, the "syncing with CVS" also cannot be
avoided, these are just svn commits.
So no, neither "git-svn merged" nor "syncing with CVS" commits can be
avoided, as long as this repo is based on svn.
> I saw just now another post requesting for commit access. Beside the
> point it's granted with git by default (just clone the repo and host
> yours somewhere), I would disagree on the push access.
>
> why? because the current vim distribution and patch models are based
> on central approach, not distributed.
This is your argument against push access?
But giving push access is just that: one central repository for several
persons, instead of having several repos, each dedicated to one person.
Then we shouldn't use distributed tools at all, because Bram's
development model is central? That doesn't make sense.
> (somehow the patches from your repo or other's repo still need to be
> sent to the original vim repo or to Bram himself)
Maybe, but not necessarily. But I don't understand the relation between
this statement and the push access or the distributed/central model.
Well, I don't understand the argument against push access at all.
> as for the guidelines you mentioned, I think Bram should be involved,
> shouldn't he ?
Bram hasn't anything to do with theses repositories. The guidelines
should just cover things like formatting of commit messages, branch
access, awareness of rewriting history with rebase/commit-amend.
> or is this some repo you never intend to sync back to
> vim ?
What gets back into mainline depends on Bram. vim_extended is not fork,
it just sits on top of Vim.
Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
