Re: Experiment to provide a mirror of bash with detailed git history
On 21 Mar 2015 20:19, Chet Ramey wrote: > On 3/16/15 4:54 PM, Eduardo A. Bustamante López wrote: > > I know that some people are interested in a more detailed commit history in > > bash's git repository. After all, it's easier for all of us to just learn to > > use a tool, and use that for everything. > > > > The changelog files distributed with bash are useful, *but*, I claim that > > it'd > > be more useful to use the facilities that git provides for this. Because, it > > already has many useful things, like bisect, blame, log, and so on, that > > only > > work properly if you follow the good practice of making "logical commits". > > I'm interested in how well this turns out. I'm also interested in how > useful you find the changelog entries, since I try to make them very > detailed. i love very detailed changelogs, but their up-front usefulness is curtailed when they can't be clearly attributed to file changes. this is why the idiom of one logical change per git commit works out nicely -- when there's a problem, you've got specific commits & their reasons, and you can use git bisect to help automate tracking down regressions. -mike signature.asc Description: Digital signature
Re: Experiment to provide a mirror of bash with detailed git history
On 3/16/15 4:54 PM, Eduardo A. Bustamante López wrote: > I know that some people are interested in a more detailed commit history in > bash's git repository. After all, it's easier for all of us to just learn to > use a tool, and use that for everything. > > The changelog files distributed with bash are useful, *but*, I claim that it'd > be more useful to use the facilities that git provides for this. Because, it > already has many useful things, like bisect, blame, log, and so on, that only > work properly if you follow the good practice of making "logical commits". I'm interested in how well this turns out. I'm also interested in how useful you find the changelog entries, since I try to make them very detailed. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Experiment to provide a mirror of bash with detailed git history
On 03/16/2015 02:54 PM, Eduardo A. Bustamante López wrote: > Also, I'd like to start using github issues to track bug reports, again, as a > mirror, so that we can provide people with an always up to date reference of > the status of the bugs they reported, and in what specific point of bash's > history a fix was provided. I'm opposed to the use of github as a bug tracker (it practically requires the use of non-free software, and I'd much rather use email than be forced to use http access when interacting with a bug database). I'm less opposed to a repo stored in github, which I can access the same as any other git repository without needing APIs specific to github, but then github is no longer a necessity for hosting such a repo. > I know that we already have savannah for that, but > since I'm not a project member, and since I'm a bit lazy and didn't research > what I had to do to request access, I decided to start with this mirror. That is, I'm fine with keeping savannah (already low volume) and this mailing list (already the main source of bug information) as is. But the idea of maintaining a git repository with cleaner history, even if you have to manually split Chet's weekly commits into what is hopefully saner chunks, seems nice, if you are willing to give it the effort. Sadly, I don't think I have enough free time to commit to helping in the effort. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Experiment to provide a mirror of bash with detailed git history
On Mon, Mar 16, 2015 at 3:54 PM, Eduardo A. Bustamante López wrote: > I know that some people are interested in a more detailed commit history in > bash's git repository. After all, it's easier for all of us to just learn to > use a tool, and use that for everything. How are you planning on creating a more detailed commit history than the history that's already there? You're going through the changelog and guessing about how code changes map to certain changelog entries? I'm not sure how well that can work. I've thought about ways to improve the situation but I'm not sure about how to improve commit detail when almost all the changes come in periodic code drops. You would have to do a lot of guesswork. Starting with a better workflow now is certainly possible. There should ideally be a stable branch for each stable release (4.0, 4.1, ...) forked from master from the correct points. Development of patch releases should of course be done in their own branches and merged into stable branches. New features would ideally have per-feature branches that get merged to master rather than a single "devel" branch that tends to be way ahead of master. Maybe you have better ideas. It's probably best to do whatever you plan on your own branch if possible. -- Dan Douglas
