On Tue, Mar 24, 2015 at 11:36:02PM +0100, Bram Moolenaar wrote:I do have the tags in my local git repository. Do they not get pushed to the repository with "git push" ?No, one always has to use 'git push && git push --tags'. It's one of the biggest warts of Git IMHO. (This being git there are of course a myriad of other options,
...on twitter, "generates a random man page for a made-up git command... more or less indistinguishable from the official docs" http://git-man-page-generator.lokaltog.net/
Since Google Code is going to be shut down we need a new place for the
Vim repository. Many users have given their opinion and github appears
to be the preferred site.
I disagree. Keep the whole history:Manuel Ortega <manny...@gmail.com> wrote:
>
> It would be nice if, when this gets finalized, the new repo trims out
> ancient stuff like 7.0, 7.1, and 7.2. There's no reason for everyone to
> have to clone all that and carry it around on disk. Yes, I know about
> shallow clones, but they're pretty wonky, especially wrt making PRs from a
> shallow clone to the main repo (not that Bram is going to look at them).
>
> -Manny
* the whole history would bloat if had many revisions of binary files,
but that's not the case, so it should not take much more space to
keep the whole history.
* Vim is not that big. At least it's much smaller than Linux where
all history is kept in git.
* The whole history is useful at least for bisections, or find out when
a piece of code was changed and why.
On Mar 25, 2015 7:18 PM, "Manuel Ortega" <manny...@gmail.com> wrote:
>
> On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>>
>>
>> Since Google Code is going to be shut down we need a new place for the
>> Vim repository. Many users have given their opinion and github appears
>> to be the preferred site.
>
>
> Darn.
>
> It would be nice if, when this gets finalized, the new repo trims out ancient stuff like 7.0, 7.1, and 7.2. There's no reason for everyone to have to clone all that and carry it around on disk.
$ git clone https://github.com/vim/vim
...
$ cd vim
$ du -hs .git .
685M .git
47M .
$ git gc --aggressive
...
$ du -hs .git .
34M .git
47M .
For reference, are similar numbers for a fresh Mercurial clone:
$ du -hs .hg .
55M .hg
47M .
I'm not sure if there's something that can be done so that the initial git clone has similar results as the post-gc results, but an extra 34M of disk space isn't worth the added complexity of juggling multiple repos.
Note that I also find bisecting to be very useful and have used it many times when working on Vim, so I am also in the camp of not hampering that functionality because of a one time cost.
work harder by adding yet more complexity in repo maintenance!
I initially ran just "git gc" and there was no change in disk space. I'm using a new enough git that it periodically kicks off a background "git gc" after a normal git command. Maybe clone is one those cases.
On Friday, March 27th, 2015 at 9:11AM, Bram Moolenaar wrote:
>
> Kana Natsuno wrote:
>
> > On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote:
> > > Isn't there a way to clone only up to some time ago, e.g., the 7.4
> > > release? I rather leave this a decision on the user side than on the
> > > server side (meaning that history would be lost forever).
> >
> > git clone --depth 1
>
> Right, that is what I was looking for. So whoever just wants a
> convenient way to pull the latest version can use this as the fastest
> method. We should add this to the instructions (e.g. for users who have
> limited bandwidth).
For users who do this, when they update, I believe they will need the
following:
git pull --update-shallow
Otherwise, any normal update (via `git pull` or `git fetch`) will pull down
everything.
On Mar 27, 2015 1:32 PM, "Benjamin Fritz" <fritzo...@gmail.com> wrote:
> If we use Bitbucket (or another service that supports both), nobody
> needs to learn a new tool. And we can combine both repositories together
> under one project page. People could clone server-side from either
> repository depending on their system of choice, and that decision
> wouldn't impact their ability to easily contribute back.
>
> Of course, I suppose we could always link to two sites from one vim.org
> page. But I'd rather any Hg repository be just as "valid" as the Github
> one, not some read-only mirror nobody looks at. But it sounds like that
> is the way it is heading.
Why should this be different than any other open source project? If you want to contribute, you need to learn the tools that are being used. When tools change, then something different needs to be learned. It's not up to the project to accommodate every user's individual desires.
I didn't know Mercurial when Vim switched to it from CVS, but I've learned to use it. Other projects I contribute to use git. Thanks to that I'm now comfortable with both Mercurial and git.
Change happens.
Having a canonical repo for Vim's code is important. Introducing multiple repos for a single codebase just increases the risk of errors. I've never encountered a project which officially supports more than one (especially with differing VCS). Unofficial mirrors I've seen, but people using those communicate suggested changes back by using patches and email.
We can't forget either that a MAJOR part of the Vim plugin ecosystem lives on Github already.
On Friday, March 27, 2015 at 1:21:48 PM UTC-5, James McCoy wrote:Why should this be different than any other open source project? If
you want to contribute, you need to learn the tools that are being
used. When tools change, then something different needs to be learned.
It's not up to the project to accommodate every user's individual
desires.
Because so far the ONLY reason I've seen for moving to git AT ALL is "it
makes the git users happy." Why are the git users more important than
the Mercurial users?