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 [3]. 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 push"? - 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. Likewise. -- 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
