Re: latest runtime files merged into vim_extended.git
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
Re: latest runtime files merged into vim_extended.git
On Mon, Dec 22, 2008 at 14:31, Markus Heidelberg markus.heidelb...@web.de wrote: Richard, I hope you can understand that I haven't yet tackled the Readme file. I haven't forgotten it. Sure, no worries, I know how it is ;) There are a few new interesting patches listed on Josh's site, maybe you could merge them, once you have more free time? I plan on spending a lot of time away from computers over christmas, but after than, if you give me commit access, I can try to help merge new patchsets and the README into vim_extended so you have less work. RIchard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
PS: There is a bug on http://repo.or.cz/w/vim_extended.git edit and build as usual vim; make; make install :s_vim_./configure_ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
Richard Hartmann, 22.12.2008: PS: There is a bug on http://repo.or.cz/w/vim_extended.git edit and build as usual vim; make; make install :s_vim_./configure_ The 'vim' command belongs to 'edit' from above. I usually never call configure directly, make calls it automatically. The 'make' is a placeholder for several different methods of building Vim: make ./configure make make -f Make_bc5.mk ... --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
Richard Hartmann, 22.12.2008: On Mon, Dec 22, 2008 at 14:31, Markus Heidelberg markus.heidelb...@web.de wrote: Richard, I hope you can understand that I haven't yet tackled the Readme file. I haven't forgotten it. Sure, no worries, I know how it is ;) There are a few new interesting patches listed on Josh's site, maybe you could merge them, once you have more free time? I wanted to apply the patches Unified colors for consistent color schemes, but the runtime.diff was really ugly: it contained 3 *.orig files and an older ctermrgb-runtime.diff itself. I wasn't keen on doing it anymore. And I want to try the Correctly indent wrapped lines patch, where I probably also have personal interest in. But I didn't get round to it so far. I'd really like the authors of these patches to send me up-to-date patches that can be applied without problems, if they are interested to have it in vim_extended. I plan on spending a lot of time away from computers over christmas, Me too, but it didn't work for now :) but after than, if you give me commit access, I can try to help merge new patchsets and the README into vim_extended so you have less work. You already have commit access, it's distributed, just let me pull :) But giving you push access is fine with me. We just have to write some guidelines before it to keep the repository clean and consistent. The final README I'd like to commit myself because of some git specific stuff. But I also wonder if we should put it into a 'stuff' branch as I did it in vim_mainline.git (not yet the README file)? Maybe a new branch would rather be recognized than yet another README_*.txt file beside others. If you want to have the files from the 'stuff' branch in your custom branch, you can just merge it, if it doesn't contain conflicting paths. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
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
-~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
On 22/12/08 20:26, Markus Heidelberg wrote: Richard Hartmann, 22.12.2008: PS: There is a bug on http://repo.or.cz/w/vim_extended.git edit and build as usual vim; make; make install :s_vim_./configure_ The 'vim' command belongs to 'edit' from above. I usually never call configure directly, make calls it automatically. The 'make' is a placeholder for several different methods of building Vim: make ./configure make make -f Make_bc5.mk ... Even on Linux, I don't call configure directly. The first time make is run on a new version (or a new shadow directory), it will call configure; if I have upgraded the software Vim uses (for instance after installing a new version of my Linux distro), or if I have changed my configuration options, I run make reconfig. make config can also be used to configure and not compile. And make picks my configure options from the environment: see http://users.skynet.be/antoine.mechelynck/compunix.htm Best regards, Tony. -- MORTICIAN:Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! CUSTOMER: Here's one -- nine pence. DEAD PERSON: I'm not dead! The Quest for the Holy Grail (Monty Python) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
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
-~--~~~~--~~--~--~---
