5 ms·

They are updating the README files through the github web interface and saving as they update each section.

Avamander 7y ago
Why not make all the edits in one pass? It just looks horrendous. I wonder though, is there a git history fixer out there somewhere that rewrites history to merge commits with the same message into one?
- _-___________-_ 7y ago
  `git rebase -i` and then change `pick` to `squash` for the ones you want squashed, but if you’ve pushed all the commits to master you’re now going to have to force-push master, which is... sub-optimal.
  - Avamander 7y ago
    Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.
    - marble-drink 7y ago
      No it isn't. Are you thinking about filter-branch?
      - Avamander 7y ago
        I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.
        packetlost 7y ago
        ... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...
        Avamander 7y ago
        Yes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.
        falsedan 7y ago
        Why would you rebase an entire git history? No one is arguing for that.
        Avamander 7y ago
        I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.
        icebraining 7y ago
        Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.
    - echelon 7y ago
      I work in a large monorepo with so many commits you couldn't fathom. Rebase isn't at all slow. I know this because I do it often to squash my own commits or move things around between branches.
      - Avamander 7y ago
        I disagree about it not being slow, it depends on hardware. In addition to that I did not ask about how to fix a commit history manually, I asked for a tool that would go over an entire commit history and automatically fix the issues for me.
        falsedan 7y ago
        The entire comment is: > Nah, rebase is too slow on large histories and it might not be your own commit which complicates things. I don't see any questions being asked. Rebase on the commits we're discussing (readme tweaks) are trivial: fixup fixup fixup
        Avamander 7y ago
        > I don't see any questions being asked. Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.
        falsedan 7y ago
        OK, I see your original comment, no need to be rude. If you're working on a computer that struggles with 'making a commit' and 'editing a text file', I feel like you're working in an environment that's going to be very frustrating when writing code. Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.
        Avamander 7y ago
- lovetocode 7y ago
  You could I suppose but you run the risk of losing your work in the browser. It is a trade off.
  - toyg 7y ago
    “You” are a developer, why the heck are “you” working in a textarea rather than a proper editor? Updating a readme is not the sort of thing that you have to do urgently from a coffee shop while on holiday in South Asia...
    - marble-drink 7y ago
      Apparently the README is very important for this project. How else could I learn that it's the most downloaded python package and that I can certainly trust it?
      - falsedan 7y ago
        you can certianly trust it
    - mplanchard 7y ago
      Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser. That doesn’t apply in this case, though, where the README is markdown
      - icebraining 7y ago
        Even for .rst, the Github editor lets you create a new branch. More likely, they simply didn't feel that was particularly important.
      - dragonwriter 7y ago
        > Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser. rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.

Why not make all the edits in one pass? It just looks horrendous. I wonder though, is there a git history fixer out there somewhere that rewrites history to merge commits with the same message into one?

_-___________-_ 7y ago
`git rebase -i` and then change `pick` to `squash` for the ones you want squashed, but if you’ve pushed all the commits to master you’re now going to have to force-push master, which is... sub-optimal.
- Avamander 7y ago
  Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.
  - marble-drink 7y ago
    No it isn't. Are you thinking about filter-branch?
    - Avamander 7y ago
      I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.
      - packetlost 7y ago
        ... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...
        Avamander 7y ago
        Yes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.
        falsedan 7y ago
        Why would you rebase an entire git history? No one is arguing for that.
        Avamander 7y ago
        I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.
        icebraining 7y ago
        Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.
  - echelon 7y ago
    I work in a large monorepo with so many commits you couldn't fathom. Rebase isn't at all slow. I know this because I do it often to squash my own commits or move things around between branches.
    - Avamander 7y ago
      I disagree about it not being slow, it depends on hardware. In addition to that I did not ask about how to fix a commit history manually, I asked for a tool that would go over an entire commit history and automatically fix the issues for me.
      - falsedan 7y ago
        The entire comment is: > Nah, rebase is too slow on large histories and it might not be your own commit which complicates things. I don't see any questions being asked. Rebase on the commits we're discussing (readme tweaks) are trivial: fixup fixup fixup
        Avamander 7y ago
        > I don't see any questions being asked. Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.
        falsedan 7y ago
        OK, I see your original comment, no need to be rude. If you're working on a computer that struggles with 'making a commit' and 'editing a text file', I feel like you're working in an environment that's going to be very frustrating when writing code. Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.
        Avamander 7y ago
lovetocode 7y ago
You could I suppose but you run the risk of losing your work in the browser. It is a trade off.
- toyg 7y ago
  “You” are a developer, why the heck are “you” working in a textarea rather than a proper editor? Updating a readme is not the sort of thing that you have to do urgently from a coffee shop while on holiday in South Asia...
  - marble-drink 7y ago
    Apparently the README is very important for this project. How else could I learn that it's the most downloaded python package and that I can certainly trust it?
    - falsedan 7y ago
      you can certianly trust it
  - mplanchard 7y ago
    Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser. That doesn’t apply in this case, though, where the README is markdown
    - icebraining 7y ago
      Even for .rst, the Github editor lets you create a new branch. More likely, they simply didn't feel that was particularly important.
    - dragonwriter 7y ago
      > Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser. rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.