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?
next 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.