3 ms·

Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?

blablabla123 12y ago
It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
- SargoDarya 12y ago
  If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.
  - megablast 12y ago
    What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?
    - ulisesrmzroche 12y ago
      You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.
jordigh 12y ago
Yeah, Mercurial phases handles this: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases
exDM69 12y ago
Why would this be advantageous? If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? In addition, git has a staging area (git add), which I use to stage intermediate steps of work. It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.
- lmm 12y ago
  > If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.
  - krupan 12y ago
    As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).
  - micampe 12y ago
    You can do that with autosquash https://coderwall.com/p/hh-4ea https://coderwall.com/p/hh-4ea
    - lmm 12y ago
      Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.
      - micampe 12y ago

blablabla123 12y ago

It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.

SargoDarya 12y ago
If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.
- megablast 12y ago
  What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?
  - ulisesrmzroche 12y ago
    You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.

jordigh 12y ago

Yeah, Mercurial phases handles this: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases

exDM69 12y ago

Why would this be advantageous? If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? In addition, git has a staging area (git add), which I use to stage intermediate steps of work. It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.

lmm 12y ago
> If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.
- krupan 12y ago
  As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).
- micampe 12y ago
  You can do that with autosquash https://coderwall.com/p/hh-4ea https://coderwall.com/p/hh-4ea
  - lmm 12y ago
    Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.
    - micampe 12y ago