All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marius Bakke <marius@devup.no>
To: git@vger.kernel.org
Subject: RFC: Merge hints
Date: Sun, 02 Feb 2020 12:52:24 +0100	[thread overview]
Message-ID: <87pnexmcjr.fsf@devup.no> (raw)

Hi,

It would be convenient if git had a facility for adding "merge hints",
both for automatic conflict resolution, as well as giving clues to
persons inheriting or merging a branch.

The main use case here is aiding long-running branches.  Imagine a
feature branch where all uses of FOO_STR is replaced with STR.  For
various reasons this branch cannot be merged to master, yet it needs to
be kept up to date, and new uses of FOO_STR keeps getting added.

If you are lucky, your compiler will complain that FOO_STR is undefined
when running whatever tests you have after a merge.  But perhaps the new
code is for a different platform and not reached during a test run.  A
diligent developer might also run 'git grep FOO_STR' *if* they know
about the change.  Fixing these trivial problems is boring and manual.

A more tricky case is where...

  def foo(a,b)

has become

  def foo(a,b,c)

...and c is a required positional argument.  Any new uses of 'foo' will
need to be adjusted during a merge.  This function can be multi line and
not easily greppable.

The diligent developer is in no shortage of tools: "git log -G foo
..master" will reveal any potential problems, even before the merge.
Yet, they still have to 1) know about the change; and 2) fix up the uses
manually.

It seems to me that git could offer better tools to deal with this.
Perhaps a ".mergehints", where you could provide a regular expression
either for automatic merge resolution, or just have git complain loudly
when a given pattern is merged (say, introduce conflict markers even
though there were no "real" conflicts).  I.e.:

[hint1]
files = *.c
pattern = FOO_STR
transform = s/FOO_STR/STR

[hint2]
files = *.py
pattern = 'foo('
conflict = true

Thoughts?  Are there other tools at the diligent developers disposal
that can aid with these kinds of problems?

             reply	other threads:[~2020-02-02 12:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-02 11:52 Marius Bakke [this message]
2020-02-14  6:44 ` RFC: Merge hints Jeff King

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

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

  git send-email \
    --in-reply-to=87pnexmcjr.fsf@devup.no \
    --to=marius@devup.no \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.