Threads for ryro
-
This blames
gitunfairly. The reason why a developer ends up with such a huge change set is because the fixes were ad hoc and unplanned.gitat least allows you to pick lines to stage, allowing you to split the huge change set into smaller and more logically cohesive ones. IDEs like VS Code help a lot in this.If we were perfect we would do something like make a WIP commit, branch, make and commit the ad hoc changes, return and keep working, amending the main commit as needed, then merge in the ad hoc fixes in the end.
-
-
Why shouldn’t developers expect their VCS to naturally handle the sorts of ad hoc unplanned fixes that naturally happen when working in a codebase on some other change? I wouldn’t necessarily “blame” git for not doing so (insofar as it even makes sense to personify a code tooling program). But this really is a missing feature from git; and it would be nice if git could be modified to handle this common use case better, or if another tool could be used to track changes in this way. There’s no rule that git as it exists right now is the perfect VCS system.
-
-
I can relate to this problem and I am glad there’s some creative work in this area.
The result of this workflow is still a chain of commits in a single branch. That might be ok for a solo project, but in a team environment, the workflow usually calls for separating topics by branch, so they can each be reviewed as a separate pull request (or similar review tool). I guess one could cherry pick changes into different branches after the fact, but could that have a role in this tool?
My usual workflow, when making multiple unrelated changes to a repo, is to use
git worktreeto get isolated directories in which to make each change. Each worktree is a separate branch, which also makes it easy to push each set of commits separately, to be reviewed as PRs.-
Hey I’m the author. I think it could be extended to support a more branch-based workflow.
When you plan a commit, the working branch is stored with it. In theory, the
git plan commitcommand could switch you onto the plan’s branch first, before creating the commit.Perhaps when creating a planned commit, you could set a
commit_in_new_branchflag to control this kind of behaviour.I’m cautious about adding too much functionality to the tool, but if you have any other ideas for branch-based workflows I’d love to hear them.
-
-
To completely eliminate the context switch, I suppose you could write commit messages in comments in the source code. Choose a special syntax that denotes a commit message, like
///, and then you could create a tool that goes through the source code, finds all the commit comments and creates commits containing the code following each comment. Or something like that.-
Hey, I’m the author and I actually built that too: https://github.com/synek/codeline
It’s earlier in development though, so it’s technically not “released” yet.
-
-
I don’t see any reason to use Linux unless your primary activity is writing code. And I say that as someone who uses Linux exclusively.
I think it’s astronomically better for programming, and significantly worse for basically everything else.