1. 30
  1.  

  2. 10

    There is a new (disabled by default, undocumented) shell option to enable and disable sending history to syslog at runtime

    this sounds abusable…

    1. 3

      I agree, totally. Now, on the other hand, why the need to add another feature like this? And why undocumented? I know it is not hard to write about it on the man page (in the case of GNU, info pages too) a few lines mentioning how to use it and such shouldn’t take more than a couple of minutes to put together. When I switch completely to OpenBSD (which I hope to happen anytime soon), for things like this I won’t miss GNU/Linux.

      1. 3

        “Undocumented” is how GNU tends to say, “don’t use this” or “this is internal, don’t rely this, we might change it or get rid of it.”

        Not saying I agree, but that’s just how I understand they do things.

    2. 2

      It turns out that the entire release is one commit: https://git.savannah.gnu.org/cgit/bash.git/commit/?id=d233b485e83c3a784b803fb894280773f16f2deb

      This is not how I would have expected it.

      1. 3

        Yeah I noticed this odd approach while developing the Oil shell as well.

        A related odd thing is that nearly all commits have no meaningful description:

        https://git.savannah.gnu.org/cgit/bash.git/log/

        There’s just a long list like:

        • Bash-4.4 patch 18
        • Bash-4.4 patch 17
        • Bash-4.4 patch 16
        • Bash-4.4 patch 15

        Each one is a wildly different bug fix or functionality change.

        Example: https://git.savannah.gnu.org/cgit/bash.git/commit/?id=2fb21d75bfddd724b0e45d4a51455a166467e496

        I think this is fairly hostile to getting to know the codebase, and I can’t think of any other project which is like this. Especially large GNU projects, which usually have multiple authors and pass between different maintainers.

        sqlite is developed by one person as well (give or take), over a long time period, and it even lives in its own VCS (Fossil), but I think it has better change management.

        1. 3

          This is because Chet doesn’t actually use git. The git repo for bash is mostly a “fine, you guys wanted a git repo, here it is, but I’m not changing how I’m actually working” kind of thing. I sort of sympathise with him. We never really wanted commits, branches, merges, refs, messages, reflogs. We just wanted to write code.

          1. 4

            It’s OK if someone wants to “just write code”, but I would strongly discourage anyone from using the code produced by that process. Standrad practice changed while Chet was maintaining bash (i.e. in the last 30+ years), but the project didn’t keep up, but unfortunately the world is too locked into bash to migrate off it.

            If you’re going to produce code for other people, it’s useful to communicate with future users and contributors with meaningful commit messages, as well as release management. Bash is not doing too badly on the release management part, as they tend to version everything carefully and write release notes.

            But IMO calling a change “patch 18” is unnecessarily hostile. At the very least you should write “the fixes bug X” or “adds feature Y”. The description and the actual code diff should be strongly linked for some sense of auditability, which is important when your code is running on millions of systems.

            1. 1

              Make git usable for Chet and maybe he’ll actually use it, then.

              Honestly, seeing what he does here,

              http://git.savannah.gnu.org/cgit/bash.git/log/?h=devel

              Seems like what a lot of people would like to do. Lots of people never wanted a VCS, just a shared versioned filesystem.

              1. 2

                It doesn’t matter if he uses git – hg, Fossil, svn, cvs, etc. would be fine too. Plenty of projects don’t use git.

                1. 1

                  He doesn’t want to use a VCS is the point. He doesn’t want to care about the things a VCS forces you to care about. He just wants daily snapshots and a way to share them. A lot of people want that. For example, the golang devs also don’t really like any VCS.

                  We really should consider the plight of these people, because they have a valid point.

                  1. 2

                    What are those crazy things that a VCS forces him to do? I think this is just childish behavior, but to each their own…

                    1. 2

                      There are a lot of people who don’t like using a VCS at all, who think they shouldn’t use one, and who feel it just gets in the way of getting things done. It’s not childish behaviour. It’s a valid position, especially with a DVCS. There are a lot of concepts a VCS add that seem to get in the way of what people want to do.

                      People don’t want commits, branches, clones, references, reflogs, obsmarkers, pushes, pulls, along with two or three commands for each of those operations. While some of us have gotten to intimately know all of these concepts, it’s somewhat elitist that anyone who writes code has to internalise all of this as well.

                      Other people just want to save their code and share it. It’s a totally valid position. Subversion gained popularity back in the day because for most users it was usually just commit and update. People like the golang devs just want a versioned filesystem, another possible approach.

                      Git is often and widely derided and mocked for being too difficult to use. Those people have a point, they’re not children. We shouldn’t consider git to be the zenith of software evolution.

                      1. 3

                        There are a lot of people who don’t like using a VCS at all, who think they shouldn’t use one, and who feel it just gets in the way of getting things done. It’s not childish behaviour. It’s a valid position, especially with a DVCS. There are a lot of concepts a VCS add that seem to get in the way of what people want to do.

                        Citation needed ;-). I have never met any software person, who is against VCS. Some may not like git, but that is something else. Nobody forces anybody to use git.

                        People don’t want commits, branches, clones, references, reflogs, obsmarkers, pushes, pulls, along with two or three commands for each of those operations. While some of us have gotten to intimately know all of these concepts, it’s somewhat elitist that anyone who writes code has to internalise all of this as well.

                        You implicitly have a commit any time you chose to publish something. It is a version at a given time. Is it so hard to write a few words about what happened and keep it in a repository for people to look at? Nowhere did I say they should use git and/or a complex git workflow. If they want something like subversion, fine, use that. Even github speaks the subversion protocol if you want to.

                        Git is often and widely derided and mocked for being too difficult to use. Those people have a point, they’re not children. We shouldn’t consider git to be the zenith of software evolution.

                        I have not said anywhere that they have to use git. The bash project chooses to publish things in git, but the way they use it is totally useless.

                        1. 1

                          Citation needed ;-). I have never met any software person, who is against VCS.

                          Chet.

                          Rob Pike.

                          Lots of young students.

                          Lots of gamedev artists.

                          Really, get out more, talk to more people. Lots of people don’t like using VCSes at all and many just use it out of some kind of ritualised obligation without really seeing the point. Look at projects on github that have a ton of meaningless commits like bash’s. People generally don’t like babysitting a VCS.

                          1. 2

                            Rob Pike does not like a lot of things, that does not make them less useful. Also if young students do not like them, that is their problem. It is called “learning the tools of the trade”.

                            I challenge you to tell your team at work that you abandon VCS because Rob Pike does not like them. Tell me how that goes.

                            1. 3

                              I think you’re talking past each other. @JordiGH is saying that there are people, who aren’t students, who don’t want to use a VCS. You’re saying that appeals to authority to change a development methodology are insufficient. To my way of thinking – you’re both right!

                              Using a VCS imposes costs, as well as bringing benefits. It seems entirely reasonable to me that for different people and different projects, that cost/benefit balance can lean towards or against VCS usage.

                              1. 1

                                My team at work would gladly leave git if we could find something better and if the entire world didn’t use git. Lots of people are in a similar situation.

                                I am not sure what something better would be, but I don’t think the misery of git is inevitable just because that’s how things are right now.

                                1. 2

                                  You are conflating git and VCS. VCS means Version Control Software. git is a possible VCS to use, but there are more: https://en.wikipedia.org/wiki/List_of_version-control_software

                                  1. 1

                                    Well, my team didn’t like Mercurial either before that. People are generally annoyed with VCS, but I don’t think I can change your opinion that people who matter have this opinion.

                      2. 1

                        Sure, everyone’s free to do what they want. He doesn’t owe us anything.

                        I’m just saying that I would discourage everybody from using software produced by that process.

                        If you care about users and contributors, there’s no valid reason to avoid change management. It’s OK if you don’t want to care about those things, but don’t expect other people to like it or sympathize with you.

                        FWIW, this isn’t an idle opinion, or a lightly held one. I have worked on source control since 2003-2004, before git or hg existed, often professionally. If you don’t use change control, you’re behind the times, and it hurts your collaborators. This is not controversial at all.

                2. 2

                  That’s kinda how I use git myself! So many of my commit messages are “idk catchup i guess lol” when I finally hit commit after playing with it for a few months.

                3. 2

                  They mainly develop using mailing lists and a patch manager. Details: http://savannah.gnu.org/projects/bash/

                  1. 4

                    So is Linux, but they land each patch in a commit with a meaningful description. In fact they’re pretty religious about change management, i.e. not using Github because it doesn’t have the rigor that they want.

                    Bash is not like this at all.