sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- 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
-
Re: [SM-Discuss] git feedback
, (continued)
- Re: [SM-Discuss] git feedback, Matthew Clark, 07/22/2006
- Re: [SM-Discuss] git feedback, seth, 07/22/2006
- Re: [SM-Discuss] git feedback, Robin Cook, 07/22/2006
- Re: [SM-Discuss] git feedback, Jeremy Blosser, 07/22/2006
-
Re: [SM-Discuss] git feedback,
Ladislav Hagara, 07/22/2006
-
Re: [SM-Discuss] git feedback,
Jeremy Blosser, 07/22/2006
- Re: [SM-Discuss] git feedback, Jeremy Blosser, 07/22/2006
-
Re: [SM-Discuss] git feedback,
Jeremy Blosser, 07/27/2006
-
Re: [SM-Discuss] git feedback,
Andraž "ruskie" Levstik, 07/28/2006
- Re: [SM-Discuss] git feedback, Jeremy Blosser, 07/28/2006
- Re: [SM-Discuss] git feedback, seth, 07/28/2006
-
Re: [SM-Discuss] git feedback,
seth, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Arwed von Merkatz, 07/28/2006
- Re: [SM-Discuss] git feedback, Andraž "ruskie" Levstik, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Arwed von Merkatz, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Ladislav Hagara, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Jeremy Blosser, 07/28/2006
- Re: [SM-Discuss] git feedback, Andraž "ruskie" Levstik, 07/28/2006
- Re: [SM-Discuss] git feedback, Andrew Stitt, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Arwed von Merkatz, 07/28/2006
- Re: [SM-Discuss] git feedback, Arwed von Merkatz, 07/28/2006
- Re: [SM-Discuss] git feedback, Ladislav Hagara, 07/31/2006
-
Re: [SM-Discuss] git feedback,
Jeremy Blosser, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Andraž "ruskie" Levstik, 07/28/2006
-
Re: [SM-Discuss] git feedback,
Jeremy Blosser, 07/22/2006
Archive powered by MHonArc 2.6.24.