Hmm, what about having a branch that was automatically regenerated based on
'master'? It would be 'reset' after build files were regenerated, and
patches would always go on top of a normal branch, so it would never show
up in the history.
This is somewhat similar to the throw-away integration branch 'pu' in the
workflow for the Linux kernel and for git itself. You would never use it
for the basis of new work (or if you did accidentally, you would rebase
onto a stable branch before merging).
If you did this, .gitignore in 'master' would exclude all the generated
files so users with proper autotools would use their own generated files,
but anyone could 'git checkout bootstrapped' if they couldn't generate
their own files.
Presumably a remote hook would auto-update 'bootstrapped' after each push.
On Sat, Feb 2, 2013 at 11:50 AM, Derek Gaston <fried...@gmail.com> wrote:
> On Sat, Feb 2, 2013 at 7:00 AM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> Now I'm not going to defend this as a solution. There was a fair amount
>> of discussion recently about checking in generated files at all, and for
>> now we are.
>>
>
> Right, this was mostly my fault. I still like having them checked in
> (with the in-tree build stuff working people can do a "checkout ./configure
> make" (and optionally "make install") ) without doing anything else or
> having to rely on autotools at all. That said, I do agree with having an
> issue with tons of diffs. Like Ben says, just make sure you use the
> autotools that libMesh builds and it keeps down the number of diffs.
>
>
>> And I have enjoyed them being there recently when git cloned onto an sgi
>> ice with a crusty automake.
>>
>
> Right, this is what I was worried about. We have an old SGI Ice machine
> hanging around ourselves with fairly old everything.
>
> Derek
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
