[kwlug-disc] Advanced(?) Git usage question

[Adam Glauser]

On Thu, Apr 10, 2014 at 2:52 AM, Chris Frey <cdfrey at foursquare.net> wrote:
>
> > I think the best practices approach would be to create a branch starting
> > with the revision where this feature was introduced (commit B), fix the
> > bug, then merge the fix in to whichever other branches need it.
>
> I don't understand why this would be best practices, unless you're trying
> to link the fix directly with the original bug.  Maybe I'm just sloppy,
> but I'd likely slap the bugfix on the nearest HEAD and merge or cherry-pick
> as needed. :-)
>

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?

I'm mostly basing this on the article
http://wiki.monotone.ca/DaggyFixes/#index2h1.
They make what seem like good arguments for this approach.

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.


The history is still contained at the file level, and putting an english
> description of the history of the bug into the bugfix commit, as well
> as including the SHA1 of the buggy commit, and maybe a "bugfix:" tag
> in the shortlog line, that seems more useful to me than an obscure
> internal merge link.  Because this:
>
>         git log buggy-file.c
>
> shows exactly what I need.
>
> The important information, to me, is that it was a specific bugfix, and
> there is nothing in git to help me find that except explicit and consistent
> commit messages that I can search on.
>

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.


On Thu, Apr 10, 2014 at 8:37 AM, John Johnson <jvj at golden.net> wrote:
>
> I do realize that this adds to the administration overhead and this brings
> me back an comment I offered earlier.
>
> IMO For the administration angle, The [overhead] [ ... ] is an evil,
> maybe even a necessary evil from a 'best practices'
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140410/e648f0cd/attachment.htm>