3 ms·

I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually c

I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work). 3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit. 4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message. What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now. Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there. Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed. Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...

black-tea 8y ago
Doesn't git reset do what you want? For example git reset <remote>/<branchname> would usually do it for me, but you could just as easily do it to any other commit.
brmgb 8y ago
> What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository. I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.
klyrs 8y ago
> What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash... If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history

black-tea 8y ago

Doesn't git reset do what you want? For example git reset <remote>/<branchname> would usually do it for me, but you could just as easily do it to any other commit.

brmgb 8y ago

> What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository. I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.

klyrs 8y ago

> What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash... If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history