On 2013-08-14, at 0:05 , Frank Loeffler <[email protected]> wrote: > On Tue, Aug 13, 2013 at 11:56:03PM -0400, Erik Schnetter wrote: >> Or: Use a graphical user interface that provides a quick overview over >> possible actions, as well as their options. > > I agree that a GUI might be useful at times, but when I need a GUI to > get what probably most users would expect from a simple 'push', then > something is wrong.
I took me a long time to realize that git is different from svn. svn is like cvs, only better -- but git has some fundamental differences from svn. There are a few tutorials on the web that try to map svn commands to git commands. Ultimately these fail, because what is a good svn workflow doesn't make sense with git. If one tries to use git like svn, then one only has a more complicated version of svn, and there's no benefit, only trapdoors. On the other hand, if one changes the workflow, then git can be much better. Actions such as creating a repository, creating a branch, pushing commits around etc. are then cheap, easy tasks, and as long as there's one repository or branch that has the original code, nothing can really get lost during these actions, even if one throws away a branch or repository. However, managing multiple branches and repositories, quickly switching between them, and juggling some uncommitted code at the same time quickly leads to so many variables than one either (a) is an absolute git wizard (and I am not), or (b) there's a GUI that shows me the state of the repositories, branches, staging areas, etc., so that I don't get confused. One key element of a good git workflow seems to be to be able to quickly and easily create new public (!) repositories, where others can look at my code. This would replace creating, uploading, describing, downloading, applying, updating, and modifying patches. This is unfortunately difficult these days, since most workstations are hidden behind firewalls, so repositories need to live on special servers. Coming back to the original issue: In a typical git workflow, "git push" isn't the second half of a "git commit" that, when combined, are equal to an "svn commit". In a git workflow, it makes a lot of sense to push a whole repository, including all branches. In one typical workflow you have two repositories locally: One is your working repository, the other essentially a copy of the official repository. You would pull into the latter those commits/branches you want, and then push this to the remote server. This is not the only way to do things, but many people work that way, and the git push behaviour is useful in this case. -erik -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
