I have a few git suggestions, in case anybody doesn't know about them yet. I don't know if this is what you are looking for, but git ships with some gui functionality for displaying the state of repositories/branches.
"*git log --graph*" outputs an ascii graph representation of your branch (can use additional options to set what info comes up) "*gitk*" opens up a gui showing the commit history of your current branch (everything in the branch's history). I use this at pretty much each commit. "*gitk --all*" opens up the same gui, but shows all branches also, speaking of gui's, you can do gui-based merges "*apt-get install meld*" (on debian-based, and other tools are available as well) to install meld, a gui merging tool "*git config --global merge.tool meld*" to set the git merge tool to meld "*git mergetool*" after a merge fails due to conflicts. the center pane is the output, and the left and right are the two inputs. similar tools exist for diff-ing One more nice git thing is to use colored text by doing the following (makes reports MUCH easier to read) "*git config --global color.ui true*" The git documentation is actually very good, in case anybody is curious about more functionality or its innards. It's available at http://git-scm.com/book/en/ I've found that I like git MUCH better than svn, but I had to read up on how the system works (it was non-intuitive for me at first). If one understands this, it is actually extremely convenient. It's extremely easy to branch out for a little experiment and merge it back into the master branch, or to work on a large separate branch and keep it up to date with an upstream branch. -- Sherwood Richers, III Department of Energy Computational Science Graduate Fellow Graduate Student | Caltech Physics | TAPIR www.linkedin.com/in/richers [email protected] On Tue, Aug 13, 2013 at 9:31 PM, Erik Schnetter <[email protected]>wrote: > 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/. > > > _______________________________________________ > Users mailing list > [email protected] > http://cactuscode.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
