4 ms·
This is the workflow I follow, but my experience is it's pretty high-mental-overhead in practice - Git doesn't draw a distinction between commits that I created
by geofft 6y ago
This is the workflow I follow, but my experience is it's pretty high-mental-overhead in practice - Git doesn't draw a distinction between commits that I created because I'm still working on something and want to switch branches, and are therefore reasonable to modify, and commits that came from some remote source and which you want to keep intact. They're both "commits." That means you, the user, have to keep track of which is which and think about which Git operations might disturb the wrong type of commits.
I'd like Git to have a mode where, say, git rebase -i won't show me published commits by default, only work-in-progress ones. (This isn't necessarily the same as "commits since the remote branch we're tracking," since it's possible to end up tracking a branch that's behind for some reason, or even in a situation like a detached HEAD where you're not tracking anything at all.)
I'd also like Git to keep track of whether I'm done with a commit and ready to publish it. Usually when I commit to switch branches, it's because I'm thinking about the branch I'm switching to, so I don't want to spend the time yet to write a three-paragraph commit message about my current work. But that makes it too easy to push an incomplete commit message.
- gmueckl 6y agoWhat you describe seems to be very close to phases in Mercurial. There, the repository keeps track of whether commits were pushed to other repositories. And you can mark commits as secret, which will stop them from getting pushed out: https://www.mercurial-scm.org/wiki/Phases https://www.mercurial-scm.org/wiki/Phases
- frutiger 6y ago> commits that came from some remote source and which you want to keep intact Don’t tags satisfy that use case?
- geofft 6y agoWell, no, because Git doesn't prevent you from modifying commits pointed to by tags. It prevents you from modifying the tags themselves, which point to the original commits, but that's not relevant - if your workflow involves a lot of "git commit --amend" or 'git rebase -i", it isn't going to stop you from accidentally rebasing or reordering tagged commits. Also, I don't think I've ever seen a repo where every pushed commit is tagged, and I suspect that will make lots of git operations that look at all refs scale poorly. The use case is that if I make a branch off current master, and then I run "git commit --amend" thinking I've already run "git commit," it shouldn't let me modify that commit - whatever it might be.
- frutiger 6y ago> modifying commits pointed to by tags You can’t modify commits. They are immutable. Tagged commits are reachable so they won’t get gc’ed. > Also, I don't think I've ever seen a repo where every pushed commit is tagged Sorry, I thought we were talking about releases (aka important commits). I’ve certainly seen plenty of repos where all the releases are tagged.
- iudqnolq 6y agoI'm in the very early stages of an alternative git client. One of the ideas I've had is marking commits as "WIP". Under the hood it'd just be a prefix, but you could toggle it like a tag. By default push would ignore them. I also think you should be able to have a bunch of WIP commits at once and stage changes to any of them equally easily (fixup/rebase but easier and by default).