GIT (was: Coverity Scan)

GIT (was: Coverity Scan)

[Jim Garrison]

> -----Original Message-----
> Corinna Vinschen
> Sent: Friday, April 25, 2014 6:33 AM
> > >>  There have been a few hints on this list about a possible move
> > >> from CVS  to git. If such a move were on the cards then that should
> > >> probably  happen first - I wouldn't want the nugatory effort of
> > >> getting this  working from CVS only to have to change it almost
> immediately.
> > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> > >with CVS or SVN, but have nothing but trouble with git.  But since
> > >everybody else is so very happy with git, I guess I'll have to adapt.
> > >Teeth-gnashingly.

I recently went through the same reluctant switch to Git from SVN.

I can tell you from personal experience that there's a period of disorientation when even the simplest tasks require a quick trip to Google.  And Git requires a major shift in your mental model of how things work. Instead of 2 places where stuff is (local and remote) there are now 4 (workspace, stage, local repo, remote repo).

HOWEVER... once you get over the learning hump you see that Git is MUCH better and allows much finer control over what's happening.  Plus, the online documentation is very good, and questions have been asked enough times that Google serves up good answers to just about any question.  If you have Cygwin/X installed, the "git gui" and "gitk" tools will make the transition easier.

I started learning Git in earnest back in December, and really started "thinking in Git" soon after.  Now, if I had to go back I would be disappointed.

Re: GIT (was: Coverity Scan)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Apr 25 15:24, Jim Garrison wrote:
> > Corinna Vinschen
> > > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> > > >with CVS or SVN, but have nothing but trouble with git.  But since
> > > >everybody else is so very happy with git, I guess I'll have to adapt.
> > > >Teeth-gnashingly.
> 
> I recently went through the same reluctant switch to Git from SVN.
> 
> I can tell you from personal experience that there's a period of disorientation when even the simplest tasks require a quick trip to Google.  And Git requires a major shift in your mental model of how things work. Instead of 2 places where stuff is (local and remote) there are now 4 (workspace, stage, local repo, remote repo).
> 
> HOWEVER... once you get over the learning hump you see that Git is MUCH better and allows much finer control over what's happening.  Plus, the online documentation is very good, and questions have been asked enough times that Google serves up good answers to just about any question.  If you have Cygwin/X installed, the "git gui" and "gitk" tools will make the transition easier.
> 
> I started learning Git in earnest back in December, and really started "thinking in Git" soon after.  Now, if I had to go back I would be disappointed.

Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT (was: Coverity Scan)

[Reini Urban]

On Fri, Apr 25, 2014 at 11:22 AM, Corinna Vinschen wrote:
> On Apr 25 15:24, Jim Garrison wrote:
>> > Corinna Vinschen
>> > > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
>> > > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > > >Teeth-gnashingly.
>>
>> I recently went through the same reluctant switch to Git from SVN.
>>
>> I can tell you from personal experience that there's a period of disorientation when even the simplest tasks require a quick trip to Google.  And Git requires a major shift in your mental model of how things work. Instead of 2 places where stuff is (local and remote) there are now 4 (workspace, stage, local repo, remote repo).
...
> Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/

Only experience helps.
I needed about a year to not loose too much changes after the switch
from svn to git, but feeling very happy now.
It helps having backups for the beginning if you try out rebase or
reset --hard or
git pull --force.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT

[Christopher Faylor]

Everyone:
Maybe it isn't clear but, with the exception of newlib, the rest of the
repository in which Cygwin used to reside has moved to git.  Cygwin is
moving too, soon.  I actually had planned on doing this last year before
Corinna asked me to stop (it was apparently going to impact the x86_64
port).  I can't use the git repo that I had built then because I had
changed the configury in a way that is now incompatible with what's in
CVS.

So, I already have a little experience using git and making the
conversion.  And, given the number of people who are not contributing to
the project (see previous discussion) I don't think we have to worry too
much about Cygwin CVS diehards besides Corinna.

Please don't get carried away with offering alternatives to git,
expressing dislike of git, or telling stories about your use of git.  I
don't see how any of that is really useful until Cygwin makes the move.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT

[Achim Gratz]

Corinna Vinschen writes:
>> > > >Yeah, I'm not exactly looking forward to it since I'm very familiar
>> > > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > > >Teeth-gnashingly.
>
> Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/

My recommendation for newcomers to Git would be to take any
not-too-large Git repository(*) and work out a few dozen ways of
breaking it; then freshly clone it to start over once you've thoroughly
messed it up.  Once you've done that a few times and maybe know how to
recover from a few less catastrophic sins (like resetting to where you
didn't want to be and then finding out where the former branch head
was), you should have a good base for deciding what kind of workflow
works for you and Git alike.  The thing that Git gets right is that it's
incredibly cheap to make yet another clone or branch for when you want
to try something even remotely risky.


(*) http://repo.or.cz/r/cygwin-setup.git perhaps?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT

[Eliot Moss]

Another suggestion w.r.t. git.  While I realize the
I am perhaps (probably) losing some of the touted
strengths of git, I tend to use it as a front-end
(client side) to subversion repos.  Therefore I
tend to use a simple subversion-like workflow.
It's one way to get started with git.  You could
"branch out" from there (pun intended!).

Best wishes -- Eliot

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT (was: Coverity Scan)

[Andrey Repin]

Greetings, Jim Garrison!

>> -----Original Message-----
>> Corinna Vinschen
>> Sent: Friday, April 25, 2014 6:33 AM
>> > >>  There have been a few hints on this list about a possible move
>> > >> from CVS  to git. If such a move were on the cards then that should
>> > >> probably  happen first - I wouldn't want the nugatory effort of
>> > >> getting this  working from CVS only to have to change it almost
>> immediately.
>> > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
>> > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > >Teeth-gnashingly.

> I recently went through the same reluctant switch to Git from SVN.

> I can tell you from personal experience that there's a period of
> disorientation when even the simplest tasks require a quick trip to Google.
> And Git requires a major shift in your mental model of how things work.
> Instead of 2 places where stuff is (local and remote) there are now 4
> (workspace, stage, local repo, remote repo).

> HOWEVER... once you get over the learning hump you see that Git is MUCH
> better and allows much finer control over what's happening.

This is exactly what makes me dislike it strongly. This, and idiotic model of
copying whole repository to my machine, when I only want to glance at the
source code, and find the culprit of my current issues.
I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
idiotic weight I pulled and went to google to see if it can be done better.
And "fine control" doesn't mix with "project consistency" at all.
Subversion is aimed at versioning of a whole project, in a supposedly
consistent state at each version. What can be more "fine" than this, is beyond
my understanding.
You can still commit separate files from working copy, though, but this
practice is discouraged for the greater good of the project you develop.

> Plus, the online documentation is very good, and questions have been asked
> enough times that Google serves up good answers to just about any question.
> If you have Cygwin/X installed, the "git gui" and "gitk" tools will make the
> transition easier.

> I started learning Git in earnest back in December, and really started
> "thinking in Git" soon after.  Now, if I had to go back I would be
> disappointed.  


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 26.04.2014, <03:19>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT (was: Coverity Scan)

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On 4/26/2014 07:27, Andrey Repin wrote:
> This is exactly what makes me dislike it strongly. This, and idiotic model of
> copying whole repository to my machine, when I only want to glance at the
> source code, and find the culprit of my current issues.
> I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
> client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
> idiotic weight I pulled and went to google to see if it can be done better.
> And "fine control" doesn't mix with "project consistency" at all.
> Subversion is aimed at versioning of a whole project, in a supposedly
> consistent state at each version. What can be more "fine" than this, is beyond
> my understanding.

git clone --depth 1 if you don't care about history.

> You can still commit separate files from working copy, though, but this
> practice is discouraged for the greater good of the project you develop.
> 

Don't you need to git add individual files to mark for commit? Won't you
get into the same problems if you forgot to commit files in SVN?




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GIT (was: Coverity Scan)

[Duncan Roe]

On Sat, Apr 26, 2014 at 08:42:34AM +0800, JonY wrote:
> On 4/26/2014 07:27, Andrey Repin wrote:
> > This is exactly what makes me dislike it strongly. This, and idiotic model of
> > copying whole repository to my machine, when I only want to glance at the
> > source code, and find the culprit of my current issues.
> > I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
> > client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
> > idiotic weight I pulled and went to google to see if it can be done better.
> > And "fine control" doesn't mix with "project consistency" at all.
> > Subversion is aimed at versioning of a whole project, in a supposedly
> > consistent state at each version. What can be more "fine" than this, is beyond
> > my understanding.
>
> git clone --depth 1 if you don't care about history.
>
> > You can still commit separate files from working copy, though, but this
> > practice is discouraged for the greater good of the project you develop.
> >
>
> Don't you need to git add individual files to mark for commit? Won't you
> get into the same problems if you forgot to commit files in SVN?
>
>
>
"git commit -a" commits modified files without the need to add them first.
You always have to add new files.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: GIT

[Achim Gratz]

Andrey Repin writes:
> This is exactly what makes me dislike it strongly. This, and idiotic model of
> copying whole repository to my machine, when I only want to glance at the
> source code, and find the culprit of my current issues.
[…]

You might want to learn about shallow clones, but unless you really have
a slow or metered internet connection it's usually not worth the
trouble.  By the time you found the culprit of your current issues you
are asking yourself "how did it get there?" and at that point you'll
want the history anyway.

> And "fine control" doesn't mix with "project consistency" at all.

Eh?

> Subversion is aimed at versioning of a whole project, in a supposedly
> consistent state at each version. What can be more "fine" than this, is beyond
> my understanding.
> You can still commit separate files from working copy, though, but this
> practice is discouraged for the greater good of the project you develop.

I don't think you can comment on things you don't seem to have tried in
earnest.  Yes, Git doesn't come with a canned workflow in the same way
that SVN does.  That's a good thing in my book, but there's no shortage
of writeups on how to mimic different workflows in Git if you want to do
that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple