<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 2:52 AM, Chris Frey <span dir="ltr"><<a href="mailto:cdfrey@foursquare.net" target="_blank">cdfrey@foursquare.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
> I think the best practices approach would be to create a branch starting<br>
> with the revision where this feature was introduced (commit B), fix the<br>
> bug, then merge the fix in to whichever other branches need it.<br>
<br>
</div>I don't understand why this would be best practices, unless you're trying<br>
to link the fix directly with the original bug.  Maybe I'm just sloppy,<br>
but I'd likely slap the bugfix on the nearest HEAD and merge or cherry-pick<br>
as needed. :-)<br></blockquote><div><br></div><div>Your process is the one I would be inclined to use too. I do try to avoid cherry-picking though. This is probably because cherry-pick changes could cause annoying merge conflict problems in Bazaar. Is this less of a problem in Git?</div>
<div><br></div><div>I'm mostly basing this on the article <a href="http://wiki.monotone.ca/DaggyFixes/#index2h1">http://wiki.monotone.ca/DaggyFixes/#index2h1</a>.</div><div>They make what seem like good arguments for this approach.</div>
<div><br></div><div>To be honest though, I haven't gone back and looked at history in depth often enough that the supposed benefits outweigh the extra overhead. I feel like the main benefit is the ease of porting the bugfix to various branches. On the other hand, if you have good branching practices, it probably should be quite easy to port the change from one existing branch to another.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The history is still contained at the file level, and putting an english<br>
description of the history of the bug into the bugfix commit, as well<br>
as including the SHA1 of the buggy commit, and maybe a "bugfix:" tag<br>
in the shortlog line, that seems more useful to me than an obscure<br>
internal merge link.  Because this:<br>
<br>
        git log buggy-file.c<br>
<br>
shows exactly what I need.<br>
<br>
The important information, to me, is that it was a specific bugfix, and<br>
there is nothing in git to help me find that except explicit and consistent<br>
commit messages that I can search on.<br></blockquote><div><br></div><div>This is the sort of thought process I am interested in. I agree that good commit messages are really important. In the case where I make a new branch for a bugfix, I'd be inclined to include a custom merge message explaining the bugfix.</div>
<div><br></div><div><br class="">On Thu, Apr 10, 2014 at 8:37 AM, John Johnson <span dir="ltr"><<a href="mailto:jvj@golden.net" target="_blank">jvj@golden.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"><big>I do realize that this adds to the administration overhead and this brings me back an comment I offered earlier.</big><br><br><big>IMO For the administration angle, The [overhead] [ <tt>...</tt> ] is an evil, maybe even a necessary evil from a 'best practices' </big></div>
</blockquote><div><br></div><div>Agreed. I don't have a problem with administration overhead when I know that I will thank myself later. The trick is figuring out which things are necessary or not. I think it probably varies depending on the project. I know I'd be less organized on a personal pet project than on something that will be shared, or that I'll be expected to meet deadlines on at some point. </div>
</div></div></div></div>