git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Mikko Rantalainen <mikko.rantalainen@peda.net>
To: Pascal Obry <pascal@obry.net>
Cc: git@vger.kernel.org
Subject: Re: Porcelain support for daggy-fixes?
Date: Fri, 11 Jun 2010 14:25:09 +0300	[thread overview]
Message-ID: <4C121D15.7030004@peda.net> (raw)
In-Reply-To: <AANLkTikbe_0GlSkXxiSeIQl0x0tfTYmoI5RuyJPzZioM@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Pascal Obry wrote:
> I would probably create a topic/fix branch:
> 
> 1) figure out the proper parent for the bug fix
> 2) create the fix branch and move to it
>     $ git co -b fix-feature-whatever parent
> 3) implement the fix
> 4) commit the fix
> 5) checkout HEAD
> 6) merge with the commit from step 4
> 
> And also merge on release branch if needed.

OK. I agree with this. The only problem is step 1 above (plus the other
repeated steps if this is done every time you find a bug).

I'm still wondering if it would be possible to figure the correct parent
automatically. How about the following:

Given: minimal patch to fix a bug committed to tip of the master.
Target: find proper parent for daggy-fix for the given bugfix (and then
later rewrite history to put the fix as daggy-fix and merge with the master)

Idea:

Compare the list of removed lines from latest commit (the bugfix) with
the output of the same lines from git blame --cc (immediately before the
bugfix). Proper parent for the bug fix is the commit that is newest for
any removed line from the parent of the bugfix in the tip of the master
(HEAD^).

Does it sound sensible to assume that the proper parent for the bug fix
is the newest commit that has modified any line that is removed or
replaced by the bug fix?


Why do I even think about this? I believe that daggy-fix style would be
beneficial for many software projects but for small fixes it requires
many little steps to implement and extra work to figure out the correct
parent. Small bugs are often easy to fix at the tip of the master so the
fixes usually end up there. It would be awesome if git were smart enough
to move the fix to the correct location (daggy-fix)  and do automatic
merge, once told that the last commit was really a bugfix. If this ends
up working well enough, then it should be a flag for commit (--bugfix)
which does the commit to proper parent and then does another merge
commit with the current branch. Then the other branches (or forks) could
merge the fix more easily (daggy-fixes should merge without conflicts if
done correctly).

-- 
Mikko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

      reply	other threads:[~2010-06-11 11:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-10 13:55 Porcelain support for daggy-fixes? Mikko Rantalainen
2010-06-10 14:21 ` Pascal Obry
2010-06-11 11:25   ` Mikko Rantalainen [this message]

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=4C121D15.7030004@peda.net \
    --to=mikko.rantalainen@peda.net \
    --cc=git@vger.kernel.org \
    --cc=pascal@obry.net \
    /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).