On Jan 9, 2013, at 10:25 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> > On Jan 9, 2013 10:13 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote: > > > > > > On Jan 9, 2013, at 10:03 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > > > > > > > > On Jan 9, 2013 9:51 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote: > > > > > > > Then I would consider switching over to git and proceeding to make fun > > > > of hg users, > > > Is this the only reason to switch? > > > > Yes, making fun of other people is the highest priority. > > > > > Since otherwise it would have to be equivalent to hg (as per your > > > aforementioned requirements). Besides, currently there is no > > > globally-visible use of branches in the petsc workflow, as far as I can > > > tell. Finally, you would have to deal with the INDEX and the extra states > > > that it implies. > > > > Sorry I was not clear. ___I____ want to be able to continue with my > > simple-minded work flow and have it be compatible with what other people > > do. It is fine if Jed and Karl and Matt and whoever uses all kinds of cool > > Git features so long as it doesn't make ___my___ workflow too > > intellectually difficult for me. That is I only object to the change if it > > requires always wrestling with several new concepts that don't exist in Hg. > > I do > > > > hg clone > > hg pull > > hg commit > > hg merge > > hg push > > > > I want to be able to do something similar with git; I don't want new > > __required__ things introduced like > > > > git sanitize x y z > > > > where x y z are particular changing options that I HAVE to magically know > > what they are each time and get right or I fuck myself over. Which did > > happen the one time I tried to use one of Jed's git repositories when it > > won't let me push because I hadn't indicated the right branch or some such > > shit. That is I don't want the repository system to require __me__ to keep > > in my brain any state information that I need to convey to the repository > > when interacting with it each time. > I think the presence of the index will be the biggest curveball for you. But if I make sure I always do a git commit immediately after a git add then am I in business and can use the usual > > hg clone > > hg pull > > hg commit > > hg merge > > hg push model? Barry > > > > Barry > > > > > > > > > > Barry > > > > > > > > Dmitry > > > > > > > > > > > Barry > > > > > > > > > > > > > > On Wed, Jan 9, 2013 at 5:48 PM, Barry Smith <bsmith at mcs.anl.gov> > > > > > wrote: > > > > > > > > > > Yes but given their absolutely horrible decision to stick with SVN > > > > > all these years I cannot trust their decision to go with GIT. Sadly > > > > > this is a very big argument for NOT switching PETSc to GIT. This > > > > > email is only partly in jest, it has a serious component as well: is > > > > > the "everyone's switching to git" just a case of the sheeple > > > > > following the latest new thing without a proper technical evaluation > > > > > or is it a carefully thought out decision? > > > > > > > > > > Barry > > > > > > > > > > On Jan 8, 2013, at 6:38 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > > > > > > > Everyone's doing it. ;-) > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > From: Dave Goodell <goodell at mcs.anl.gov> > > > > > > Date: Tue, Jan 8, 2013 at 6:23 PM > > > > > > Subject: [mpich-discuss] MPICH migration to git > > > > > > To: discuss at mpich.org > > > > > > > > > > > > > > > > > > MPICH users & developers, > > > > > > > > > > > > The MPICH project has transitioned from using SVN as our version > > > > > > control system (VCS) to using git instead. Details of the switch > > > > > > are described here: > > > > > > > > > > > > http://wiki.mpich.org/mpich/index.php/Git > > > > > > > > > > > > Highlights from the document and the transition: > > > > > > > > > > > > * Read-only git clones are available at > > > > > > http://git.mpich.org/mpich.git and git://git.mpich.org/mpich.git > > > > > > * All critical history from SVN has been imported into the git > > > > > > history. > > > > > > * The SVN server and its associated history are not going away, > > > > > > although it has been made read-only. > > > > > > > > > > > > We continue to work through our documentation and automated > > > > > > processes (cron jobs, etc.) to update them to the new system. Our > > > > > > trac instance will transition to understand the new VCS soon, > > > > > > although it currently displays only historical SVN data. > > > > > > > > > > > > Please bear with us as we work through this transition period. If > > > > > > you have trouble with the new setup, please contact devel at > > > > > > mpich.org or discuss at mpich.org for assistance. > > > > > > > > > > > > Regards, > > > > > > The MPICH Team > > > > > > _______________________________________________ > > > > > > discuss mailing list discuss at mpich.org > > > > > > To manage subscription options or unsubscribe: > > > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > > > > > > > > > > > > > > >
