Christian MICHON, 23.12.2008:
>
> On Tue, Dec 23, 2008 at 3:39 AM, Markus Heidelberg
> <markus.heidelb...@web.de> wrote:
> >> 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.
>
> if I have a look at the gitk visual feedback, I would expect a linear
> history (this is how vim evolves).
This is how vim seems to evolve. Possibly Bram develops various topics
in parallel and merges the mature topics together, too. Whether with
help of an SCM or not. But that's another thing than vim_extended
anyway.
> I see you've a lot of branches in your vim_extended repo, hence a lot
> of merge, but most of these merges are actually empty (no difference,
> no patch).
> So actually the history you're preserving is very complicated and
> could be simplified: this is what I meant.
Yes, I knew what you meant. But simplification of the history is not
possible while keeping topic branches. Well, the history will be
simplified by 1 level, when the repo is not based on SVN anymore, but
that's it.
> > 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.
>
> I actually created a vim repo using patches and tarballs only,
> avoiding to sync with CVS/SVN for that purpose. I extracted the
> dates/timestamps from version.c to mimick what I would get from a
> cvs/svn import, and all commits are artificially from Bram.
>
> So the history can be linear there too!
As already stated in my previous mail, the 'vim' branch can only be
linear, when not being based on SVN anymore.
> >> 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.
>
> if you're using git (great!), I'd rather stick to a decentralized
> workflow than a centralized one.
> if you're allowing push access to your public git repo, what stops an
> accidental deletion of a branch ?
The same reason that stops me from deleting branches: we just know what
we are doing. If you just call 'git push' with the right settings in
.git/config, you cannot delete a branch. Hence the guideline.
> (remember there's no trace of such deletion, and it's very hard to
> recover from it, unless it's your public repo and you're the only one
> pushing into it)
There's git-reflog, making it easy to recover a deleted branch.
> > Then we shouldn't use distributed tools at all, because Bram's
> > development model is central? That doesn't make sense.
>
> I was not clear: I'd love Bram to move to a distributed model. We can
> always use git for forks/experiments and patching/merging/testing.
What's already done in vim_extended.
> I'd rather not use git to recreate another central repo: is this clearer now ?
You have created a central repo yourself as well as me.
It's not the purpose to be an alternative to sending patches to Bram.
> > 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.
>
> potential/accidental deletion of branches on your public repo is 1
> example (see above).
Everyone with push access can delete branches, me too.
But recovering is easy.
> >> 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.
>
> ok, I understand now.
>
> >
> >> 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.
> >
>
> so I guess it's fine: stick with your workflow and allow push access
> if you want :)
I think some questions/answers from above become superfluous now :)
Thanks for the feedback
Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
