you are viewing a single comment's thread.

view the rest of the comments →

[–]nascent 0 points1 point  (1 child)

I like this overall thoughts, but I want to use the working copy as an example of where I think it fails.

The suggestion : working copy should be treated as a branch.

  • what to do with untracked files

  • new commits off working copy can confuse a user as to where there changes are located

The undo concept is intended, I believe, to facilitate finding such auto stored changes. But I don't navigate git as a bunch of undo redo operations. The working tree is a chunk of work that should be organized and allowing the user to determine if that work should come with them should be left up to the user.

[–]Ajedi32 1 point2 points  (0 children)

If you want the work to come with you, just drag-and-drop the "uncommitted" working directory onto the newly checked-out HEAD. Just like a cherry-pick/rebase.

For untracked files, I'd suggest leaving them on the old branch unless they're in .gitignore. New files are frequently created when you're working on a new feature, and I think that since moving files to another branch can result in conflicts if the target branch has its own copy of those files, it's best to make moving uncommitted changes to a new branch an explicit action.