[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

Dear Grant,

in message <528646bc0610121208i2b9b3b4at8e7de8c0b3800276 at mail.gmail.com> you wrote:
> 
> > Maybe there is a clever way to auto-generate the CHANGELOG  from  the
> > commit  message;  I  tried  this  once and failed. Ummm... just tried
> > again and found that it's actually working  when  I  use  git-commit;
> > however,  it  seems  that cg-commit does not run the pre-commit hook.
> > Maybe a cogito issue. I'll ask...

I asked, and received pretty clear statements: even if we'd  use  the
pre-commit  hook  it  wouldn't  work  as  this run before editing the
commit message. On the other hand, as long as we  manually  edit  the
commit  message  we can point EDITOR to some wrapper script. But also
the general opinion about my idea was  pretty  clear.  Linus  himself
wrote unequivocally: "Why? That's just stupid."

> Hopefully this is fixable.  It would certainly make developers lives
> easier.  Alternately, can the changelog be generated at the time of
> tarball extraction?  Of course, this would mean that the changelog no
> longer exists in the git repo.  What are you using as a pre-commit
> hook?

Nothing yet. I thought about some script, but  it  seems  it  doesn't
work.  And  my  other idea of using git-format-patch + git-mailinfo +
some  custom  script  to  re-play  the  sequence  of   commits   with
automatically  editing  the CHANGELOG before comitting is not as easy
either since both format-patch and mailinfo have their own ideas  how
to reformat the commit message.

> Jon, do you have any experience with this?

> Fair enough.  However it is not always easy to do so.  Let's take
> jdl's git tree as an example.  The patches in that tree have been
> submitted to the mailing list over the last 6 months or so.  I don't
> necessarily have that mailing list history in my inbox.  Nor would I

Ah, I see. This emanates from my own style of working -  for  me  the
mailing  list  archive is everything - history and patch database and
task tracking system... On the other hand,  there  are  mailing  list
archives at SF and gmane...

> So, the question still remains "How do I provide the appropriate
> context for an off-mainline patch?"

I see your point.

> My preference is definitely #2.  I guess my opinion is: development is
> going to occur in off-mainline trees regardless.  Most of them are
> private (and therefore irrelevant to this discussion), but some like
> jdl's and the freescale trees are public.  The changes have been
> around a long time, but they are still not in mainline.  In this case,
> I do not think replying to one of the original patches is relevant or
> convenient due to additional changes applied on top, the amount of
> time that has passed, and the git workflow.

You convinced me. Thanks for the explanation.

> On rereading my comment here, I realize it's harsher than I intended.
> I'm sorry.  I just wanted to state my disagreement, but this statement
> could be read as a personal comment.  I apologize.

No offence taken. I often sound harsher than I intend, too. I know
that lack of time is no real excuse, but I don't have a better one.

> Okay, then I misunderstood and I apologize.

I'm glad to see we're discussing problems and solutions  again.  This
is all I want.

Thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain: an apparatus with which we think we think.    - Ambrose Bierce