On Sun, May 11, 2008 at 7:08 AM, Justin Leung <jleung@redback.com> wrote:
quoted text
> Hi all,
>
> * This email probably represent the whole hardware ASIC community about git
> *

I'm an ASIC designer too.

quoted text
> here are the things not fitting right in ASIC dev:
>
> - no incremental revision numbers (they are so scared of the 40hex SHA1)

this is unimportant: if they want to track a specific release of a
file, it's better to look at what was the file's content from this cut
to that cut.

quoted text
>
> - Inability to reference without SHA1, they want simple numbering (ie,
> version 100, 120, 120.1, 130.4.5)

this is where tags and branches are useful to point to a specific release/cut.

quoted text
>
> - Inability to refer to a file by a simple number
> (the backend guys will be confused by SHA1; they can't work with anything
> more than 4-5 digits)

same answer

quoted text
>
> - Complexity of commands (although we can have warpper, but real git
> commands for non-sw guys is not going to happen)

just use gitk and git-gui: almost all can be done with these two
graphical tools.

quoted text
>
> Most hardware chip designers were using CVS since their first job.
> It suited the purpose very well.

for linear development, yes. but when we were requested to perform
maintenance on a specific old cut, this was becoming a nightmare.

quoted text
>
> Most RTL design veterans only use less then 5-6 cvs commands in their whole
> life (LOL, i m serious) :
>
> $ cvs checkout
> $ cvs update
> $ cvs log
> $ cvs diff (tkdiff)
> $ cvs status
> $ cvs commit

gitk, git-gui: two commands (actually gitk can be called from git-gui)

quoted text
>
> We don't use branches.

this is the wrong approach.

quoted text
> Our model is strict forward with a centralized, one main branch model to
> avoid mistakes .
> We see branches as evil ; some merges in Verilog codes means another 10+
> hours of simulation and regression.

use branches to reference the different ressources (rtl, simulation, layout).
then track these branches between them for deliveries and work/flow.

use tags to mark specific releases/cuts.

quoted text
> - 'git-show-branch' actually show reversed serialized version numbers (we
> want it the other way, accending)

you can create an alias: git-show-branch | tail -r

quoted text
> - 'git-describe' gives you commit numbers since your last annotated tags (
> ie, git-5423-g7def45b)
>
> so, i understand that a simple numbering scheme can be done .

yes, I used to be scared by sha1 too: I even created numbered tags for
each commit. Until I read more about git, and stopped expecting using
git as svn/cvs.

quoted text
>
> I truly hope that the in the main repository model of git this can be turned
> on by a switch or in the git config .

no, it would kill the right approach: embrace the index, and never look back.

quoted text
>
> Is it too complicated to incorporate this model ?

you have to adapt your methods instead: trust another ASIC designer :-)

-- 
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html