Marat Radchenko <ma...@slonopotamus.org> writes:
> Problem #1: TortoiseGit GUI windows for common tasks have a heck
> lots of controls that a common Git user will never need.
Do people around TortoiseGit lurk on this list? Otherwise this may
not be something we can help you with here.
> Problem #2 occured the first day we started using Git on real
> project. It is explained in detail in older post to Git ML . I
> call it "swapped/reverse merge problem".
> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push
> The root of evil is step #4 that creates a merge commit with
> "swapped" parents.
Yes, this is a real issue, and I do not mind seeing a patch to
improve the situation (there may be different approaches, and one
random approach somebody takes may not necessarily be a good way to
improve the situation though).
- Perhaps by allowing an option to tell the "pull" at the fourth
step to record swapped parents in the merge?
- Perhaps in step #3, stop suggesting to "pull first" and instead
tell them to "fetch upstream, rebase your work on it and then
- Extending on the second one, wrap a large part of the procedure
in a single handy wrapper "git update" or something, whose point
is to "update your work to be mergeable and pushable"?
> Problem #3: on conflicts, user ends up with a working copy that
> marks all remote-changed files as modified. Luckily, nobody has
> problems with conflict resolution process, it's just confusing to
> see changes other way round.
If we flip the resolution process to "apply/merge your work to the
updated upstream (i.e. the topic of your problem #2 above)", that
"other way round" issue will disappear, no?
> Problem #4: when conflict happens during rebase, mergetool shows
> user own changes as "theirs" and remote changes as "mine". And
> believe me, explaining this to users doesn't increase their
> willingness to adopt Git.
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