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 dual...@gmail.com 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
Re: -i option of set missing in man bash
Here's the other side: allowing `set -$-' to succeed keeps a Posix-mode shell running a script from throwing a fatal error. Allowing it also keeps the bug reports down. The same rationale can be used to add -c and -s to the no-op flags, since those are command-line options that end up in $-. I know this following line of thought doesn't help much, but, have you really seen that used in the wild? So: dualbus@hp ~ % for sh in bash dash ksh93 mksh zsh; do echo $sh; $sh -c 'set -i$-'; done bash bash: line 0: set: -c: invalid option set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] dash ksh93 ksh93: set: -i: unknown option ksh93: set: -c: unknown option Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...] mksh mksh: set: -i: unknown option zsh zsh:set:1: can't change option: -i Or dualbus@hp ~ % for sh in bash dash ksh93 mksh zsh; do echo $sh; $sh -c 'set -$-'; done bash bash: line 0: set: -c: invalid option set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] dash ksh93 ksh93: set: -c: unknown option Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...] mksh mksh: set: -c: unknown option zsh Don't seem to be very useful in general. Honestly, I'm happy with whatever path you decide to follow. The only thing I don't like about being able to turn the 'i' flag with set is that it doesn't really put the shell in interactive mode, and it bit me into thinking that it did (because the flag was showing in $-). And I don't know of a way to query the shell to print the status of the 'interactive' global var (as you can do with shopt login_shell).
Experiment to provide a mirror of bash with detailed git history
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. Now, I'm not requesting to add more workload to the already heavy workload that Chet has, so, what I'm asking is for help to keep an always up-to-date mirror of bash where we follow the best git practices. We'd also link every individual commit to the parent commit in the official bash repository. I don't want this repo to be used to build bash. My only goal is that people who are involved somehow in the development of bash have a good history reference, and make it easier for us to read updates and peer review the changes. This way we can test Chet changes, check if there are no evident mistakes, and make the overall development process of bash better. 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 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. I would like to know what you think about this, Chet. And also, for any other followers of this list, if they want to help me with the process of splitting the commits, that would be great. Also, we could perhaps start looking into the somewhat messy tests/ subdirectory, and make it a robust test system to check for regressions, posix compatibility, and so on. The link to the aforementioned repo: https://github.com/dualbus/bash So, for now, I volunteer to the effort of keeping the history in sync. Oh, I also removed stuff like automake's cache, the configure file (that should be generated with autoconf -i anyways), the -i files, and many other stuff that shouldn't be in the repo. -- Eduardo
Re: -i option of set missing in man bash
On 3/13/15 8:47 PM, Eduardo A. Bustamante López wrote: You can avoid these surprises by making -i just as other options, i.e., working within the shell not just when a shell is started. [..] I don't think it's good to have set +/-i available after initialization. It's more complex to handle, and with little (or null?) gain. If you're using set -i inside a script, then you're clearly doing it the wrong way (whatever you're trying to achieve). *But* I do think it's misleading to have bash accept the 'i' flag, but not others. It also leads people to think that setting it from 'set' worked, because it's in $- if it has an 'i' in $-, then it *must* be interactive, right?, wrong. Here's the other side: allowing `set -$-' to succeed keeps a Posix-mode shell running a script from throwing a fatal error. Allowing it also keeps the bug reports down. The same rationale can be used to add -c and -s to the no-op flags, since those are command-line options that end up in $-. Chet -- ``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/
