Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] git feedback

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Andra AT swoolley.homeip.net
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Fri, 28 Jul 2006 10:35:25 -0700

On Fri, Jul 28, 2006 at 10:26:52AM +0200, Andra?? ruskie Levstik wrote:
> Jeremy Blosser wrote :
>
> > > ------- Additional Comment #6 From Seth Woolley 2006-07-27 16:32
> > > -------
> > >
> > > Yes, for changelogs, git's merges don't work. I'd almost prefer to have
> > > HISTORY be a git commit that took the commit info and auto-generated the
> > > HISTORY.
> >
> > It's been suggested before, and it's certainly doable, but the typical
> > response is that our HISTORY files are a different use case than the info
> > we want in the raw SCM changelog. That we keep history different places
> > in
> > different forms is intended as a feature. Arwed can speak to that more if
> > he wants...
> >
>
> What kind of info could there be autogenerated??? I mean will it read the
> devs mind on what he was fixing. I mean ok you can get what files were
> fixed and if maybe there was a version bump(just parse the VERSION in
> the diff) but the rest is kinda impossible.
> Like:
> * BUILD: completly overhauled it, made it use scons instead of make
> * DEPENDS: added FOO to be non-optional but this might change in the
> future so it shoud be checked on each update
>
> I just don't see having autogenerated HISTORY be so precise.
>
> The thing I'd like to see with git and bugzilla is a link between
> them(bugscm) so that one can link the bug and the commit hash without
> the need of double checking the commit hash and posting it in etc.
>
> Just my 0.2 ???

As in, you'd put that data in your commit message:

section/spell:
* BUILD: ...
* DETAILS: ...

section/spell:
* PRE_BUILD: ...
* DETAILS: ...

and it would insert the date, name, address into appropriate HISTORY files,
and even perhaps add a new line:
* COMMIT: (sha1sum commit ID)

You'd be able to easily cherry-pick what you need based off the HISTORY, and
the user-level display could even filter out the COMMIT ids by default.

More advanced changelogs could be generated based off a diff of the COMMIT
ids.

Not sure if this all would work as easily as I'm imagining, but it's a
thought.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page