Javier Domingo Cansino wrote:
> = The publish tracking branch =
> I still have problems getting upstream branches correctly configured
> as to have this introduced, anyway, I suppose it's optional, so
> nothing to add on that.
I did so too, until I patch `git branch -v` to be useful.
> = Reject non-fast-forward pulls by default =
> Not having this introduced yet allows newbie people to use git with
> just 4 commands, without bothering around with fetch and merge and so.
I don't understand what you are trying to say. There is no change for those
people, when the pull fails they would be told to use `git pull --merge` if not
> = Use "stage" instead of "index" =
> Totally agree with this.
> = Default aliases =
> I hate aliases, make scripts more difficult to read and understand.
You are assuming that everyone will start to use aliases in scripts, which is
not going to happen enough to be a problem.
Try to find svn or hg scripts with aliases, let's see how many you find.
> I have taught (or tried to) a lot of people Git. And this is some of
> the stuff I have seen they have difficulties with:
> - Remembering the commands, for example, remembering add, commit push
> and pull, which I think we can all agree is the most core and simple
> combination of Git commands.
> - What command comes for what they need. If I want to share
> everything, what should I do?
> - Most of them, have real difficulties on remembering the flows. There
> are too many commands for the start.
> I wouldn't nevertheless suppress any of them, I would rather do a tuto
I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.
The real problem is that the core developers of Git don't acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html