Re: [Ctags-devel] Future of ctags

[Colomban W. <lis...@he...>]

Hi,

Le 03/02/2015 06:31, Darren Hiebert a écrit :
> I haven't forgotten you. My main apprehensions have been migrating to
> Git, and hosting off of SourceForge.
> 
> We began using git on a project at work and it has been a ride. While
> I knew how to use Subversion thoroughly, I do not have such a comfort
> level with git and don't know how to undo problems that occur. We
> have had changes wiped out at work that had to be restored when folks
> would push from their local repository that didn't get fully merged
> with changes from others. This necessitated the only two guys who
> know how to get us out of the mess in order to restore the files that
> got overwritten with older files. Considering how often this has
> happened, I have some trepidation.

Admittedly Git allows the user to do a lot more, and this includes
breaking everything.  However I believe that with a small learning time
you can get comfortable with Git if you don't try and do complex things
without taking time to properly understand them.  Sure, Git allows you
to rewrite history, force push and the like, but that's not commonly
required.  I guess what you saw was people trying to force a push
because some other changes happened and they didn't know what to do --
though, at least recent Git versions will tell you you probably should
pull and then try again -- as with SVN you couldn't even commit if your
clone was outdated.

Anyway, I believe that if you restrict yourself to the basics required,
like commit, checkout, add, push, pull, merge, branch and the like,
without trying weird stuff everything should be OK.  Also, Git has
lightweight branches [1], and you're advised to make extensive use of
them.  Basically, instead of working on master (Git's "trunk") you'd
work on a branch and merge [2] it when you're done, or make a pull
request out of it.

I can understand that one has to get used to the decentralized model
when coming from a long centralized experience, and that Git may let the
user do a little too much too easily -- but I believe there is much to
gain.  My first VCS experience was SVN (though I admit I didn't know
much about it), and it was just fine, but I wouldn't trade Git for it
for the world anymore :)

One thing for example I find very useful with Git and missing with SVN
is the ability for anyone to work on the repository.  With SVN, if you
don't have commit access you cannot prepare commits, and you pretty much
can only provide one single patch for inclusion with svn diff.  With
Git, you can commit on a local branch as much as you like, and easily
export several commits, allowing to break things into relevant units
rather than one large thing.  Or you can publish your repository and ask
for commits to be pulled from it -- that's what PR are basically, just
with a nicer interface.
For me as a developer it makes things a lot easier, because I can work
on whatever I have to (even several branches at once if I need to) and
take the time and steps I need to prepare clean commits [3].


[1] lightweight branches may be a concept that might be a bit weird to
SVN users, like SVN branches are a bit weird to me :)
But basically a Git branch is local unless explicitly pushed on a
remote, and "replaces" the current file tree.  There is no
/branches/trunk/ or /branches/otherbranch/, you just switch between
states of the one and only file tree.  Git branches are references to
the last commit on them, and checking a branch out gives you the state
of that last commit.

[2] you may not want to know, but if you want, Git also allows you to
avoid a merge by "importing" the commits instead of creating a merge,
that's the call of the person trying to "merge" the branch.

[3] and with Git's advanced features, I can even fix my commits (if they
haven't been pushed) if I realize there's something wrong in them.  OK,
admittedly that's the kind of power-feature that Git users grew to love
but that can easily scare people off and lead to some breakage if misused :)

> Secondly, I prefer that ctags be hosted on SourceForge. I am
> uncertain how we can use git to do that, but still host on
> SourceForge. Can you please explain further to me how that can be
> done?

SourceForge supports Git repositories just like they support SVN ones.
However, AFAIK they don't provide the whole pull request and review
interface people like on GitHub and similar platforms.

However, if your concern is that you want to also have the code on
SourceForge, it's not a problem: with Git (and any decentralized VCS
actually) you can have as many public repositories you want, and they
all are as much complete as the next one (so are local ones).  So, we
could very well push all changes to SourceForge in addition to any other
platform (like GitHub for example) we want.  We could even probably have
a "hook" [4] that would automatically propagate the changes to whichever
mirror we want.

For example with Geany, we have a hook set up so that any change pushed
to our GitHub repository is propagated to our own server mirror
http://git.geany.org/geany/


[4] automated action triggered by some event, typically push or commit.
 I'm not sure GitHub has a builtin one for propagating to sourceforge,
but without having tested it it should be possible to get something to work.



I hope this helps a bit and didn't scare you further off :)

Regards,
Colomban