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). 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. > 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! >> 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 ? (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) > > 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. I'd rather not use git to recreate another central repo: is this clearer now ? > >> (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. potential/accidental deletion of branches on your public repo is 1 example (see above). > >> 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 :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
