Is this scattered workflow implemented in Git?

Question

This is what I would like my workflow to look at an understandable level:

• I'm hacking my new feature a bit
• I noticed a typo in the comment
  • I change it
  • Since the typo is completely unrelated to anything else, I put this change in a bunch of comment corrections
• I keep working on the code
• I understand that I need to create several utility functions
  • I'm doing it
  • I made this change to my bunch
• Steps 2, 3, and 4 are repeated throughout the day.
• I am completing a new function and making changes to this function in a heap
• I click interesting patches upstream: one with a new function, several for other settings, and one with a bunch of comment corrections, if enough has accumulated

Since I am lazy and a perfectionist, I want to be able to do some things out of order: I could fix a typo, but forgot to put it in a bunch of comment fixes; when I prepare the initial corrections (I use git-svn, so I need to be quite intentional about this), then I will pull out the comment corrections at this point. I can forget to share things to the very end. But I could / also / made some of the piles along the way (sorry, the metaphor is collapsing ...).

All this looks like just using Eclipse change sets with SVN, only I can have different changes in the same file in different piles (the need to differentiate the changes into different commits is what prompted me to switch to git-svn, in fact ... ), and with Git I can have my own full discussion history of changes, experimental branches and all, but still make a nice, neat patch.

I recently started with Git after I wanted to for a while, and I'm still happy. The biggest way that the above workflow doesn’t really appear in Git is that "bin" cannot be just a local branch, since the working tree only ever reflects the state of a separate branch. Or maybe the Git index is a heap, and I want it to have several ways (efficiently).

I can come up with several ways to get closer to what I want (maybe creative use of a wallet? Sophisticated styles-check-merge dances?), But my understanding on Git is not strong enough to be sure how best to put all the pieces together . He said that Git is more of a toolbox than VCS, so I guess the question boils down to this: How do I create this thing with these tools?

Answer 1

It seems like you want to make a lot of commits every time you do something separate, and then use git rebase -i to reorder and combine your commits before pushing them upstream.

The rebase function is one of the really powerful Git functions, and it works well for your mode of operation.

Since you can modify commit messages using rebase , you can add tags to your rebase like COMMENT or UTILS, so you can easily identify them later when you shuffle things with git rebase -i .

One of the limitations of git svn dcommit can be inconvenient - you can only send a “complete” set (from the point of view of Git) of patches to Subversion. That is, dcommit only makes an error from the moment you start making changes to HEAD. If you have commits (e.g. typos) that you want to keep for a later batch commit, you can make a temporary branch for them using git rebase to update it.

I have a “list of things to do someday” to try and make a patch for git svn dcommit , which allows you to choose which patches to send to Subversion.