Re: A failing attempt to use Git in a centralized environment

From: Junio C Hamano <gitster@pobox.com>
To: Marat Radchenko <marat@slonopotamus.org>
Cc: git@vger.kernel.org
Subject: Re: A failing attempt to use Git in a centralized environment
Date: Mon, 28 Apr 2014 11:41:43 -0700	[thread overview]
Message-ID: <xmqqoazlqot4.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com> (Marat Radchenko's message of "Mon, 28 Apr 2014 10:29:07 +0400")

Marat Radchenko <marat@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.