1. 4

    I feel like the disclaimer isn’t big enough on this post. Rebase will enrage your teammates if you push to the public repo. Even setting up to rebase on git pull might annoy your peers, even though it’s awesome.

    A word of caution: changing the history of public, stable branches is generally advised against. Editing the history of feature branches and personal forks is fine, and editing commits that you haven’t pushed yet is always okay. Use git push -f to force push your changes to a personal fork or feature branch after editing your commits.

    1. 13

      In the immortal words of Doug Gwyn(?): “UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.”

      1. 8

        It might also be helpful to highlight the less well-known --force-with-lease option as a safer (albeit harder to explain) default.

        1. 6

          feel like the disclaimer isn’t big enough on this post. Rebase will enrage your teammates if you push to the public repo. Even setting up to rebase on git pull might annoy your peers, even though it’s awesome.

          That’s not my experience at all, in fact, in the last several companies I’ve worked at, git pull –rebase and git rebase -i to squash long strings of commits into one for a nice clean merge was considered good etiquette and de rigeur.

          1. 2

            I think it says something about git that “Don’t rewrite history on branches you’re sharing with other people” is still not a common understanding.

            1. 4

              The number of developers has doubled every ~5 years for decades now.

              This implies that fully half the workforce has fewer than 5 years experience.

              “Things you expect everyone to know” are not going to become widespread knowledge until that changes.

              1. 1

                It’s not the newbies’ fault. The CLI encourages mistakes by having bad or missing defaults.

            2. 1

              Mercurial makes this distinction clear by enforcing what is a draft commit and what is a published commit (roughly, published commits are those that have been pushed to a publishing repo).

              Mercurial will disallow rewrites of public commits (but you can always forcibly move them back to the draft phase if you’re so inclined). Together with Evolve which propagates metahistory of which commit replaces which other commit, it’s perfectly reasonable to share and modify WIP commits.

              There is currently a proposal floating around to give evolve to git, so hopefully some day we will all have a clear understanding of how to share mutable commits.

              1. 1

                When would rebase on pull annoy anyone? It is a local branch that nobody else sees.

                1. 1
                1. 3

                  I ran into exactly the same bug when I tried to move the not-so-nice environment variables out of my profile and into the lesskey file. Ultimately I never got around to finding out why it wouldn’t work - but together with someone else, came up with a small C wrapper around less(1) which lets the user set colours in a more sane manner.

                  With this, you only have to do:

                  export MANPAGER_COLORS='md=31,me=,us=4;35,ue='
                  export MANPAGER=manpager
                  

                  See here for a more detailed description along with the source code.

                  1. 2

                    This is great, I like that it avoids polluting the shell environment.

                    The issue should be fixed in the most recent less version (released just 10 days ago) but most systems won’t have this up-to-date version so there is still a need for a solution like yours to set the variables elsewhere.