On Sun, May 11, 2008 at 7:08 AM, Justin Leung <jleung@xxxxxxxxxxx> wrote: > Hi all, > > * This email probably represent the whole hardware ASIC community about git > * I'm an ASIC designer too. > 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. > > - 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. > > - 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 > > - 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. > > 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. > > 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) > > We don't use branches. this is the wrong approach. > 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. > - '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 > - '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. > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
