Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs

[Kirill Smelkov]

On Fri, Sep 05, 2008 at 02:50:51PM -0500, Rob Landley wrote:
> On Friday 05 September 2008 14:08:48 Daniel Glöckner wrote:
> > At this point I would like to remind those who pick up the patches
> > that there are two other mails by me with uncommitted fixes:
> > http://lists.gnu.org/archive/html/tinycc-devel/2003-10/msg00044.html
> > http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00007.html
> 
> Well, I'm no longer picking up patches.  When the 0.9.24 release came out, I 
> pretty much lost interest in my fork.
> 
> My objection all along has been that CVS is not a real source control system, 
> and no modern project should be burdened with it.  CVS doesn't even 
> understand changesets.  You were kind enough to post your patches to the 
> list: if they went directly into CVS (as Grischka does, although he only 
> really seems to care about the windows target), I couldn't see what files got 
> touched in what groups, because CVS simply wasn't designed to track that 
> information.
> 
> I can't even go "how many changes were checked into the project in the month 
> of August", because cvs thinks about individual files, and doesn't understand 
> that a project is made up of ore than one, or that the same change can touch 
> more than one file.  (According to 
> http://cvs.savannah.gnu.org/viewvc/tinycc/?root=tinycc the project hasn't had 
> a checkin in four months, although that's just a guess from looking down the 
> list at the age field of EVERY DARN FILE), including the windows 
> subdirectory.
> 
> I have an enormous todo list for tinycc.  No modern compiler can be relevant 
> without generating x86-64 code, but there are simpler and more fundamental 
> things it needs just as badly.  For example, I wanted to redo the command 
> line parsing logic to work like busybox: call it like ld and it understands 
> linker arguments, call it like as and it jumps straight to the inline 
> assembler.  It can easily work as "strip", and it would be easy enough to 
> grab the uClibc code for readelf and ldd and whip up an nm and objdump and 
> ar...  (And if you do all that, adding support 
> for "-Wl,--dynamic-linker,/blah" becomes trivial.  And without doing that, 
> adding support for that is an amazingly ugly hack.)
> 
> All that's not actually very hard, I've done it before and most of the code 
> is 
> already there.  But before I touch tinycc again, I need to deal with the fact 
> that my fork isn't based on 0.9.24.  There are changes in CVS that I need to 
> look at to make what I'm working on relevant again, but that involves dealing 
> with CVS.  And it wouldn't be the last time.  And I just haven't been able to 
> bring myself to care.
> 
> If this project decides to move off of CVS, let me know.  But it's 2008, CVS 
> is dead, and I've run out of the patience necromancy requires.

I'm not a compiler guy, but why don't we use git?

Rob, I know you use Mercurial. We used hg in SymPy [1] too, but came to
conclusion that git is better. I myself came through CVS -> Darcs -> Hg
-> Git and don't regret.

So why not use git?


For this I've created tinycc git mirror [2] and put Daniel's patches
except those from 2003 to patches-from-Daniel branch


The mirror was created with 'git cvsimport' and could be incrementally
updated should we wish to sync with CVS.

With git everyone can commit to their local repositories, or their own
branches and it is easier to keep track of patches and exchange them.

Again, I'm not a compiler guy, but I think this is what you need.

Sorry for the noise if this is not relevant.

-- 
    Всего хорошего, Кирилл.


[1] http://www.sympy.org/
[2] http://repo.or.cz/w/tinycc.git


P.S.

Appendix - how to use it
========================

1. clone tinycc.git repository

    $ git clone git://repo.or.cz/tinycc.git
    # this will create tinycc directory with sources

    $ cd tinycc


2. let's see which branches we have

    $ git branch -a
    * master
      origin/HEAD
      origin/initial
      origin/master
      origin/origin
      origin/patches-from-Daniel

3. let's visualize history

    $ gitk --all
    # shows all commits on all branches

4. let's build our work on top of what Daniel has done so far

    $ git checkout -b my-work origin/patches-from-Daniel
    # hack ...
    
    # now let's commit

    # see what we did
    $ git diff

    $ git add -p
    # interactively record some hunks

    # see what is recorded
    $ git diff --cached

    # ... and still not recorded
    $ git diff

    # and finally commit
    $ git commit -v


Read more about git here:

http://git.or.cz