
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html; charset=ISO-8859-1"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

<big>On 2014-04-09 15:44, Adam Glauser wrote:</big>

<blockquote

 cite="mid:CAFgBy5_5WvVfzTAg8cZh3z5TUs3yCj1-uLX1Sn4Q3mMKyB5B_w@mail.gmail.com"

 type="cite"><big>It seems

like an awful lot of work for a very minor bugfix,<tt> ...</tt><br>

  </big></blockquote>

<big><br>

IMO For the administration angle, The "awful lot of work" has no

relation to the complexity or the severity of the bugfix. It is an

evil, maybe even a necessary evil from a 'best practices' point of view.<br>

<br>

Having said the above, an alternate approach would be to take a branch

now of the release candidate, fix the bug in that branch and migrate

the patch back to the mater and the feature branch. What I call the

"rewind" approach, i.e. rewinding to the commit before A, lets call it

commit A-1, is a valid approach, but you may have to migrate many more

changes made since A-1, A and B, etc. back to that branch. <br>

<br>

IMO Focusing on only the current bug and its bugfix is less risky.<br>

<br>

FWIW: This is from a Git newbie, having just started with Git, working

with two local repositories one of which is branched as a result of a

"rewind".<br>

<br>

JohnJ</big><br>

<br>

</body>

</html>