> I swear, someone needs to invent a Git-wizard program. Interactive with a wizard-like interface, it will walk you through all the common kinds of tasks, even if they're fairly advanced, explaining all the ramifications along the way.
Sounds like a great idea for making one type of workflow easy. The great part about Git not having an abstraction is that it supports almost any workflow. You can choose what flow is right for your project.
Which is, by the way, why the documentation is not task-oriented, it's data-model oriented. The same command might be used for two completely different tasks in two different processes.
Other tools that aim to make the basics for committing easy do so at the expense of implicitly supporting only certain workflows. Think of something like Perforce. You don't enforce your process with Perforce, you choose your process so that it will work with Perforce.
That's why I said it's a UI designer's worst nightmare.
Because there are a lot of different kinds of workflows, and I don't even know how you'd begin to organize them. I mean, maybe it's not even possible.
It would just be nice if it were more possible to "ease into" Git, rather than feel like you have to go through the equivalent of a college semester learning it.
I've learned Git about the same way I've learned *nix systems and programming languages in general: piecemeal, a step at a time, on a largely need-to-know basis. It's been 4 years now and I feel like a complete novice, but I rarely need to do anything other than (1) synching local with remote repo, (2) committing a change, and (3) using a feature branch.
Then maybe there should be tools that use git to create a specific workflow. What I have now is a text file with all the git commands I need to follow the chosen workflow. I don't have that for any other command line tools I use.
Just because something is very flexible and supports many ways of doing something doesn't mean it has good UI and doesn't mean it has good discoverability.
I don't understand where you think I said it did. I specifically said it was a great idea to slap a better UI on git, but mentioned the caveat that to do a good job, the interface would have to be geared to a specific work flow.
Sounds like a great idea for making one type of workflow easy. The great part about Git not having an abstraction is that it supports almost any workflow. You can choose what flow is right for your project.
Which is, by the way, why the documentation is not task-oriented, it's data-model oriented. The same command might be used for two completely different tasks in two different processes.
Other tools that aim to make the basics for committing easy do so at the expense of implicitly supporting only certain workflows. Think of something like Perforce. You don't enforce your process with Perforce, you choose your process so that it will work with Perforce.