3 ms·

Love that the repo has two commits and they're both "initial commit"

by ctkhn 1y ago

dylan604 1y ago
i've done that when i forgot to add some necessary files in the initial initial commit. since the adding the forgotten files did not include any changes warranting a different message, it lets me know i was a knucklehead and the commits are meant be considered the same commit. it's much faster than looking up to see if there's a way to amend an existing commit with additional files, and then going through the process of actually doing it. my use of git is add/commit/push/clone/switch/fetch. after that, it's 100% look it up and hope i'm not going to bork my repo by following some SO thread
- lcnPylGDnU4H9OF 1y ago
  For what it's worth, you can still do it with those commands, though I understand part of the point is that you don't necessarily remember all of the options for them. But in this case, it should be simple: git add . git commit --amend -m "initial commit" git push -f origin HEAD I don't know when `--amend` was added. I used to do a squash rebase but this is much nicer.
  - monkpit 1y ago
    git commit --amend --no-edit
  - Terr_ 1y ago
    > I used to do a squash rebase This probably wouldn't apply to the "initial commit" problem, but I almost always use fixup instead of amend, ex: git add foo.code git commit --fixup {commit_with} git rebase -i --autosquash {main_or_whatever} Unlike amend, you can target an older commit rather than just the very-most-recent (great if you're separating the rename/refactor from the rewrite) and you can delay the second step of actually changing history until you're sure stuff is in a good state. This is particularly useful for the review process: All the changes during the review process can be "fixup" commits, allowing reviewers to easily see what did (or didn't) change since their last interaction. At the same time, all the fiddly fixes and back-and-forth stuff won't be in the final history, only a smaller number of "real" commits that future maintainers would care about.
  - tczMUFlmoNk 1y ago
    --amend was added in 2006 :-) https://github.com/git/git/commit/b4019f045646b1770a80394da876b8a7c6b8ca7b https://github.com/git/git/commit/b4019f045646b1770a80394da8...
sotix 1y ago
The government required them to scrub the commit history. Hilarious that they used that message for the second commit.

Love that the repo has two commits and they're both "initial commit"

by ctkhn 1y ago

Love that the repo has two commits and they're both "initial commit"

i've done that when i forgot to add some necessary files in the initial initial commit. since the adding the forgotten files did not include any changes warranting a different message, it lets me know i was a knucklehead and the commits are meant be considered the same commit. it's much faster than looking up to see if there's a way to amend an existing commit with additional files, and then going through the process of actually doing it. my use of git is add/commit/push/clone/switch/fetch. after that, it's 100% look it up and hope i'm not going to bork my repo by following some SO thread

lcnPylGDnU4H9OF 1y ago
For what it's worth, you can still do it with those commands, though I understand part of the point is that you don't necessarily remember all of the options for them. But in this case, it should be simple: git add . git commit --amend -m "initial commit" git push -f origin HEAD I don't know when `--amend` was added. I used to do a squash rebase but this is much nicer.
- monkpit 1y ago
  git commit --amend --no-edit
- Terr_ 1y ago
  > I used to do a squash rebase This probably wouldn't apply to the "initial commit" problem, but I almost always use fixup instead of amend, ex: git add foo.code git commit --fixup {commit_with} git rebase -i --autosquash {main_or_whatever} Unlike amend, you can target an older commit rather than just the very-most-recent (great if you're separating the rename/refactor from the rewrite) and you can delay the second step of actually changing history until you're sure stuff is in a good state. This is particularly useful for the review process: All the changes during the review process can be "fixup" commits, allowing reviewers to easily see what did (or didn't) change since their last interaction. At the same time, all the fiddly fixes and back-and-forth stuff won't be in the final history, only a smaller number of "real" commits that future maintainers would care about.
- tczMUFlmoNk 1y ago
  --amend was added in 2006 :-) https://github.com/git/git/commit/b4019f045646b1770a80394da876b8a7c6b8ca7b https://github.com/git/git/commit/b4019f045646b1770a80394da8...

sotix 1y ago

The government required them to scrub the commit history. Hilarious that they used that message for the second commit.