5 ms·

isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that. Here is a (made up), but generally real

• joshdick 11y ago
  Write better commit messages. Garbage in, garbage out.
• jarfil 11y ago
  Get yourself a WIP branch, do whatever you want on it, extract clean commits from it, kill it with fire when finished.
• conductor 11y ago
  I can relate to that. I don't like those WIP commits on a feature branch (when the program is crippled or even doesn't compile or doesn't pass the tests, when the code is filled with temporary "printf" debug messages, etc.) to be in the history of the master branch. Ideally, every commit that I'm making should be preferably not big, but logically complete and working. The problem is that sometimes I want to work on another branch and I have to commit in the middle of the work so I can checkout into the other branch in which case (without a squashing merge) the "offending" WIP commit would end up in the master branch's history.
  • Estragon 11y ago
    man git stash
    • jdfellow 11y ago
      also very handy for working on multiple branches concurrently, git worktree --help
    • kageneko 11y ago
      I can't trust git stash anymore. I mistyped something and it blew away a lot lot lot of work. So now I just commit stuff. If I want to get rid of the commit, I can follow it up with a reset.
      • gcommer 11y ago
        I use commit amends (`git commit -a`) for continually updating these pseudo-stash commits.
      • cname 11y ago
        If you can't trust `git stash`, you can't trust git in general, because you can do all kinds of destructive things (which are usually recoverable).
        • dahart 11y ago
          Not true. From the git stash man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms." Git stash is more dangerous than other git commands, and I've personally witnessed more people losing work with stash accidents than with commit accidents. There may be plumbing commands that can get you there like fsck but the fact of the matter is you are better off committing or branching, from a safety standpoint.
• WorldMaker 11y ago
  It does tell me a great deal about your development habits, yes. Maybe not information that I care to do much more than skim, of course, unless I'm your manager looking for reasons why you might be working from home too much. :) (That said, there's probably some cool deep learning applications here...) Some of the information, for instance, is that maybe you are working on pieces too large at a time and should find more ways to break them into smaller units of work that you can more easily commit in logical piece at a time rather than "snapshot dumps" between computers. Like I said, from a hyberbolic standpoint, how the sausage is made isn't pretty and is full of garbage sometimes, but it is informative.
  • dahart 11y ago
    I'm a manager, and I'd be happy to see commit messages about working from home. My team would never write commit messages like this, they are of negative value to the team. I would ask them to squash. If I saw these commit messages pushed, the employee would get a warning.
• ris 11y ago
  I think this is a strawman - I don't think anyone is suggesting publishing WIP commits.
  • serge2k 11y ago
    Sure they are, if you don't YOU'RE A LIAR!
  • brianpan 11y ago
    Isn't that exactly what the original commenter is suggesting? > no rebases, no squashes, sometimes not even fast-forwards
    • ris 11y ago
      I think the implication is rebases or squashes of already published work.
      • WorldMaker 11y ago
        Thanks, that was indeed the primary implication. That said, I've been happy to debate the larger implications that there are UI/UX tweaks/story-telling that could make even the work-in-progress non yet published stuff more appealing to publish without needed to mutate it from its as-developed states... But yes, I was mostly speaking to published commits.
• Pxtl 11y ago
  But why delete them? Why don't the tools just hide them?
• voltagex_ 11y ago
  Yep, on TFS where branches are a world of pain, commit messages look like this. Sorry.
• chris_wot 11y ago
  I think I would go insane with commit messages like that. Sorry, but they have very little value - I'm afraid that it's not important to know that you've gone out for a meeting, a coffee or sick. Commit messages in a mainline tree should be reserved to explain what you've done, and nothing more. I would hate to have done a bisect to land on your commit "WIP, heading home sick for the day" as the one that caused the bug. By all means, create a WIP branch and if you can then push this WIP branch to the main repo, but please use commit squashing into logical units of change when merging into the feature branch or main trunk!
• krisdol 11y ago
  Tell whomever is naming those commits to stop. We don't squash or do PRs, but that is not at all a realistic history.
  • jasode 11y ago
    >Tell whomever is naming those commits to stop. No. That advice is wrong. Git was designed for those type of low-friction wip commits in private/local/unpublished branches. Many programmers have a concept of "savepoints". Think of "git commit" as an "implementation detail" of that savepoint. Those savepoints were intended to extend the programmer's mental scratch space and never meant for public consumption. Therefore, squash/rebase is a logical followup step to consolidate meaningless savepoints into a meaningful commit. A private "commit" in git does not have the same semantics as the lock & checkout type of commits in svn/Perforce. Programmers should not be discouraged from making cheap commits as often as they want even with nondescriptive titles because those commits weren't meant for public dissemination anyway. Being judgmental about those wip commits makes no sense.