2015-04-01 22:52 GMT+03:00 Bram Moolenaar <[email protected]>:
>
> Markus Heidelberg wrote:
>
>> if switching to Git, we could seriously consider cleaning up the
>> repository, now it might be the last chance for quite a while.
>>
>> I have collected some possibilities for improvement - some simple, some
>> a bit more complicated, but if found the proper commands/scripts, the
>> automated tasks should work without much hassle.
>
> [...]
>
> I generally like cleaning up, but at the same time we should not spend
> time on things nobody will really care about. Adding tags to old
> commits is not very useful. In fact, github already has a problem with
> the number of tags that Vim has.
>
> Removing empty and useless meta data sounds useful.
> Branches were only used temporarily, I don't think they contain useful
> information.
>
> I don't think I will want to change the commit messages because some git
> tools can't handle them properly. AFAIK the message do show up properly
> in most places.
Commit messages were not handled properly even with mercurial, though
there were less cases when it shows summary.
In mercurial these were `hg histedit` and `hg log` without additional
options. Git has a bit more AFAIR. *And* you definitely have problems
with current commit messages on GH: GH expects all messages follow
Summary
Extended description
…
…
convention (thus you need to tap `…` to determine WTF does “updated
for version” summary actually mean), bitbucket also (it even does not
allow expanding)… Well, even look at
https://code.google.com/p/vim/source/list. What you see here is
(black) Added tag …
(black) updated for version … (gray) Problem: …
(note: most useless information is highlighted with black).
Oneline summary at the top is the expected convention used by every
site and every used VCS out there. Current commit format is completely
wrong then: “updated for version 7.4.684” is a “super useful” summary
given that you can already deduce this line from the attached tag
name.
>
> Some things can perhaps be done on the Mercurial repository before the
> import, but I suppose some are only possible in git. What will happen
> for the mirror in Mercurial then? We need to make sure we don't break
> anything.
>
>
> --
> There are only two hard things in programming: Cache invalidation,
> naming things and off-by-one errors.
>
> /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
