5 ms·

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be som

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

dahart 8y ago
> git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. Yeah, completely unreachable commits have 30 days, even when you run git gc. The default reflog for a branch is even longer: 90 days! https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc
MichaelMoser123 8y ago
How comes that I see older commits with git log -p ? I can even see what the commit changed.
- tomcatfish 8y ago
  Those commits are referenced. Parent comment is talking about commits that have no references to them (ie. You make a commit then remove all traces of it, it is not gone completely until after a certain amount of time).
shandor 8y ago
This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they can't trash the origin even if they try.
- kohtatsu 8y ago
  Which merge strategy do you recommend? # Merge commit git merge --no-ff -m <message> <hash> # Squash and merge git merge --no-commit --squash <hash> git commit -m <message> # Rebase and merge git rebase --force-rebase <hash> From https://stackoverflow.com/a/52301456 https://stackoverflow.com/a/52301456
  - shandor 8y ago
    I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.
    - greyskull 8y ago
      +1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. I'd say another couple of benefits: - It's relatively easy to teach git workflows when the log/graph is linear, and similarly it's _way_ easier to reason about your workspace when you have an actual production codebase. - Merge commits can make certain operations like reverts and patches harder to reason about
      - u801e 8y ago
        > In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. One command I often use is git blame which allows me to find the commit that's associated with a particular line of code. Then I can look at the commit message and the diff against its parent. Perhaps what I'm changing may undo a bugfix and I wouldn't have realized it without reading the associated commit message.

dahart 8y ago

> git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. Yeah, completely unreachable commits have 30 days, even when you run git gc. The default reflog for a branch is even longer: 90 days! https://git-scm.com/docs/git-gc https://git-scm.com/docs/git-gc

MichaelMoser123 8y ago

How comes that I see older commits with git log -p ? I can even see what the commit changed.

tomcatfish 8y ago
Those commits are referenced. Parent comment is talking about commits that have no references to them (ie. You make a commit then remove all traces of it, it is not gone completely until after a certain amount of time).

shandor 8y ago

This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they can't trash the origin even if they try.

kohtatsu 8y ago
Which merge strategy do you recommend? # Merge commit git merge --no-ff -m <message> <hash> # Squash and merge git merge --no-commit --squash <hash> git commit -m <message> # Rebase and merge git rebase --force-rebase <hash> From https://stackoverflow.com/a/52301456 https://stackoverflow.com/a/52301456
- shandor 8y ago
  I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.
  - greyskull 8y ago
    +1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. I'd say another couple of benefits: - It's relatively easy to teach git workflows when the log/graph is linear, and similarly it's _way_ easier to reason about your workspace when you have an actual production codebase. - Merge commits can make certain operations like reverts and patches harder to reason about
    - u801e 8y ago
      > In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. One command I often use is git blame which allows me to find the commit that's associated with a particular line of code. Then I can look at the commit message and the diff against its parent. Perhaps what I'm changing may undo a bugfix and I wouldn't have realized it without reading the associated commit message.