git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Chris Packham <judge.packham@gmail.com>
To: GIT <git@vger.kernel.org>
Subject: Sharing merge conflict resolution between multiple developers
Date: Mon, 11 Aug 2014 16:59:15 +1200	[thread overview]
Message-ID: <CAFOYHZCiKC4TR4jFVUB=W5qbDG8XvB2Obx1ZfTH8OF3E_c5BnA@mail.gmail.com> (raw)

Hi List,

At $dayjob we maintain internal forks of the a number of upstream repositories.

Unsurprisingly updating these forks can be extremely problematic,
especially when it's only one person doing the merge. Fortunately most
of us are in the same physical location so it is possible to drag in
someone who knows more about the code than the person merging but I
can't see that scaling with remote developers.

Is there any way where we could share the conflict resolution around
but still end up with a single merge commit. I'm thinking of something
like the following workflow

developer A:
  git merge $upstream
  <conflicts>
  git mergetool ...
  <resolves some of the conflicts>
  git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer B:
  git pull developer_A
  git reset HEAD^
  <at this point it's be nice if developer B's work tree and index
were in the same state as developer A's before they ran 'git commit'>
  git mergetool ...
  <resolves the conflicts that they know about>
  git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer A:
  git pull developer_B
  git reset HEAD^
  git mergetool ....
  <finishes off anything left>
  git commit
  <It'd be really nice if MERGE_MSG was retained through all of this>
  git push

Any thoughts on if something like this is currently possible? Is this
something other git users would find useful?

Thanks,
Chris

             reply	other threads:[~2014-08-11  4:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11  4:59 Chris Packham [this message]
2014-08-11 18:44 ` Sharing merge conflict resolution between multiple developers Junio C Hamano
2014-08-11 23:29   ` Chris Packham
2014-08-12  1:57     ` Junio C Hamano
     [not found] ` <CAP8UFD0_zfB_D-9EVZ4K=Zdq_G+9C-QhX7WED53zExV+Nv8Arg@mail.gmail.com>
2014-08-11 18:57   ` Christian Couder
2014-08-11 19:33 ` Nico Williams
2014-08-17  7:52 ` Jeff King
2014-08-17 13:30   ` Signinig a commit with multiple signatures Jason Pyeron
2014-08-19  8:05     ` Jeff King
2014-08-19 13:09       ` Jason Pyeron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFOYHZCiKC4TR4jFVUB=W5qbDG8XvB2Obx1ZfTH8OF3E_c5BnA@mail.gmail.com' \
    --to=judge.packham@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).