True,
I'm no fan boy Gordon... I have read many times this has been the
problem with GIT for years is that it was created be developers for
developers. They add things in the core that make sense to them or as
an after thought no thinking of the implications of what they are doing.
So yes, the commands are ridiculous and archaic in some sense. I use
windows and tortoise GIT is a pretty good UI for this stuff once you
understand what you need to do. It hides the commandline from you.
Another problem here that I see is a lot of the times yu would make a
local branch, work on it and then merge it back into develop, that way
you can merge your offline commits back in small pieces at a time as
you work. But that seems to go contrary to this model Apache is
supporting, thus more complication. Some one please tell me I am wrong
here.
I am making it my duty to learn this all and still use tortoise. :)
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
My initial impression is that Git is designed to make complicated
team workflows possible rather than simple team workflows easy. The
fact that nobody agrees on how to do things is indicative that it is
overly complex.
I've read the chapter of the Git book about how it just stores
files, trees, and commits in a content-addressable filesystem, and
the architecture seems elegant. But the commands on top of that
architecture are less so.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Tuesday, March 19, 2013 4:05 PM
To: dev@flex.apache.org
Subject: RE: Git's "branches are cheap and fast but modal" model
Ha,
I just had this same scenario today and was talking to Roland about it.
I'm learning the darker recesses if GIT now to Gordon since I am
working with more people. Its really easy when the team is not
complicated.
I asked this exact same question, "Why would I commit, if I'm not
ready to commit if I just want to sync the branch".
I do like GIT better than SVN and I was hardcore svn for years, GIT
has a huge learning curve but, once you get passed it you will see
you over thought some principles it uses.
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
That seems silly. I wouldn't want to commit if the code is in some bad
state. What would I put for the commit message... "Oops, gotta go."?
- Gordon
-----Original Message-----
From: Sylvain Lecoy [mailto:sylvain.le...@gmail.com]
Sent: Tuesday, March 19, 2013 3:57 PM
To: dev@flex.apache.org
Subject: Re: Git's "branches are cheap and fast but modal" model
When you work on a branch, and you want to work on another branch, you
first have to commit in the current branch you working on to save your
work.
Then, you git checkout the branch you want to work on, and so on...
Cheers !
2013/3/19 Gordon Smith <gosm...@adobe.com>
Is that what you do?
- Gordon
-----Original Message-----
From: Dasa Paddock [mailto:dpadd...@esri.com]
Sent: Tuesday, March 19, 2013 3:38 PM
To: <dev@flex.apache.org>
Subject: Re: Git's "branches are cheap and fast but modal" model
You could use the stash command:
http://git-scm.com/book/en/Git-Tools-Stashing
http://git-scm.com/docs/git-stash
--Dasa
On Mar 19, 2013, at 3:25 PM, Gordon Smith <gosm...@adobe.com>
wrote:
> I'm having a hard time with the fact that, although Git branches
> are
cheap and fast, you can work on only one of them at a time. In
Subversion, of course, they're just different directories and you can
have editable files for multiple branches simultaneously.
>
> So suppose I'm editing files on one branch and haven't gotten to
> the
point where I want to commit. When I want to work on another branch,
what do I do with those edits?
>
> - Gordon
>
--
Sylvain Lecoy
Ingénieur d'étude et développement
+33(0)6 67 36 20 85
+44(0)7599 618 024
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
