5 ms·

I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. Using stashes would be just reimplementing the index using les

I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. Using stashes would be just reimplementing the index using less convenient UI. I really don't understand what's so difficult about the index... It's just the stuff you will be inserting into the repository when you next commit. Having it separated enables a very convenient workflow that would've required manually using patch and diff when using tools that don't support you. Git is more than just revision storage. I like to think of code as clay, and the index as a tool you use to mould that into the final construct that gets baked

Certhas 8y ago
It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity As far as I can see the use case you describe is actually covered in gl commit.
- cyphar 8y ago
  "git commit -a" will skip staging entirely if that's what you'd like to do. Should "-a" have been the default? Maybe, but that doesn't mean that you can't use it. Now, if you want to exclude certain files from a commit I will freely admit this is a pain. The easiest way, especially if you have loads of untracked files you don't want to commit, is to do: % git commit -a && git reset HEAD~ <file> && git commit --amend Which is pretty awful, I will admit. I had an alias to do this a while ago (without the need to amend the commit) but it wasn't great fun. However staging is still a useful concept, and "gl commit" as far as I can tell doesn't really allow me to do something I do quite often ("git add -p" to add partial hunks of a change to staging for a commit). I recognise that I'm probably in the vast minority (outside of the kernel community) when it comes to my Git usage, but staging is definitely quite important for some Git usecases.
jobigoud 8y ago
> I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. I don't quite understand the use of the command line for git or hg. In my typical workflow before I commit I want to quickly review all the changes I just made. With the GUI you have a list of files and when a file is selected a diff of that file, without opening a new window. That means you can browse all the diffs in a few seconds just by moving the cursor along the changed files. If you see an unrelated change that doesn't have an impact you can just uncheck these lines to remove these changes from the commit. Or uncheck the file itself if all its changes are unrelated. I feel I'm much more confident of what ends up in the commit than using the cli.
- maxxxxx 8y ago
  Sounds like how I work.
- chousuke 8y ago
  I often find GUIs restrictive because they don't lend themselves well to ad-hoc scripting. I also don't use GUI editors, so that may be a part of it. I can see how a TUI/GUI for being able to quickly stage things from the UI is useful, but it doesn't make the concept of the index useless on the command line either. Using git from the command line is second nature to me at this point, and the index is a large part of my workflow. When I use git for revision control (as opposed to eg. Subversion. Or anything that doesn't have lightweight branching, something akin to an index, and rebases), it feels like the tool is helping me organize my commits instead of just being a place to shove things after I'm done coding.
- Shorel 8y ago
  What you describe is achieved by using git diff, and then git commit -p. I use that everyday. Whatever you imagined we command line people use, it is just not accurate, IMO.
quietbritishjim 8y ago
I have a different workflow in TortoiseHg than ufo. In your terminology, I only consider revisions that have been pushed as being baked, while unpushed revisions are the clay. We already have tools to manipulate revisions, while the index, stash/shelve and patches are all just reimplementations of revisions with less convenient UIs. I just go ahead and commit whenever I like (without having to stage!), and sort it out afterwards with a combination of update (like git checkout), revert on specific files (like git reset --soft), and rebase (like git rebase!). You might say this is trading one complexity (staging area) for another. But you need to be familiar with these commands anyway, so you might as well use the same things for other tasks. Plus, they're visualised on the same revision graph as everything else (e.g. "oh look, one month ago I saved that private commit"). Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind). (PS: Having said all of this, 90% of the time I just go ahead and commit and push everything, and 90% of rest of the time it suffices to just untick the checkboxes next to files that I don't want to commit before clicking the commit button in TortoiseHg. This is massively easier than any of these strategies, and it's opt-in. I'm sure there is a command line way to do this but I find a GUI is great for this task because it's quite visual.)
- chousuke 8y ago
  > Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind). I don't get it. What does mercurial have instead of refs? HEAD in git is just one kind of a ref; differentiated from a branch only by when the tooling updates it (ie. when you create a commit in the checked out branch, or when you check out another commit) "branches" are mutable references. "remote" branches are just refs pointing at the commit that was the remote branch the last time you fetched it to your local repository. They're all the same thing in the end, though. The way Mercurial branches seem to be a special thing instead of a property of the structure of a repository is partially why I prefer git. In git, the fact that a "named branch" is actually just a ref to a particular commit that gets updated occasionally makes perfect sense to me. The way mercurial does it has never clicked; why does a branch have to be something special? I mean, in git, a branch that has no ref pointing to it is still a branch, but if you have no reference to a commit, why would its existence matter? Sure, you can end up "losing" commits when working with rebase, but no-one actually leaves their repo that way if the commit was important; you just look it up from the reflog and give it a name again, and it won't get garbage collected. And after a branch is merged, why would you keep around a named reference to a branch head that no longer matters? IIRC mercurial has a feature to "close" branches, but I don't understand why that even needs to be a thing? In git, you just delete unnecessary branches (that is, refs), and you're done. Maybe I misunderstand how mercurial works, but I've not found a source explaining the rationale behind why it works this way.

Certhas 8y ago

It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity As far as I can see the use case you describe is actually covered in gl commit.

cyphar 8y ago
"git commit -a" will skip staging entirely if that's what you'd like to do. Should "-a" have been the default? Maybe, but that doesn't mean that you can't use it. Now, if you want to exclude certain files from a commit I will freely admit this is a pain. The easiest way, especially if you have loads of untracked files you don't want to commit, is to do: % git commit -a && git reset HEAD~ <file> && git commit --amend Which is pretty awful, I will admit. I had an alias to do this a while ago (without the need to amend the commit) but it wasn't great fun. However staging is still a useful concept, and "gl commit" as far as I can tell doesn't really allow me to do something I do quite often ("git add -p" to add partial hunks of a change to staging for a commit). I recognise that I'm probably in the vast minority (outside of the kernel community) when it comes to my Git usage, but staging is definitely quite important for some Git usecases.

jobigoud 8y ago

> I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. I don't quite understand the use of the command line for git or hg. In my typical workflow before I commit I want to quickly review all the changes I just made. With the GUI you have a list of files and when a file is selected a diff of that file, without opening a new window. That means you can browse all the diffs in a few seconds just by moving the cursor along the changed files. If you see an unrelated change that doesn't have an impact you can just uncheck these lines to remove these changes from the commit. Or uncheck the file itself if all its changes are unrelated. I feel I'm much more confident of what ends up in the commit than using the cli.

maxxxxx 8y ago
Sounds like how I work.
chousuke 8y ago
I often find GUIs restrictive because they don't lend themselves well to ad-hoc scripting. I also don't use GUI editors, so that may be a part of it. I can see how a TUI/GUI for being able to quickly stage things from the UI is useful, but it doesn't make the concept of the index useless on the command line either. Using git from the command line is second nature to me at this point, and the index is a large part of my workflow. When I use git for revision control (as opposed to eg. Subversion. Or anything that doesn't have lightweight branching, something akin to an index, and rebases), it feels like the tool is helping me organize my commits instead of just being a place to shove things after I'm done coding.
Shorel 8y ago
What you describe is achieved by using git diff, and then git commit -p. I use that everyday. Whatever you imagined we command line people use, it is just not accurate, IMO.

quietbritishjim 8y ago

I have a different workflow in TortoiseHg than ufo. In your terminology, I only consider revisions that have been pushed as being baked, while unpushed revisions are the clay. We already have tools to manipulate revisions, while the index, stash/shelve and patches are all just reimplementations of revisions with less convenient UIs. I just go ahead and commit whenever I like (without having to stage!), and sort it out afterwards with a combination of update (like git checkout), revert on specific files (like git reset --soft), and rebase (like git rebase!). You might say this is trading one complexity (staging area) for another. But you need to be familiar with these commands anyway, so you might as well use the same things for other tasks. Plus, they're visualised on the same revision graph as everything else (e.g. "oh look, one month ago I saved that private commit"). Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind). (PS: Having said all of this, 90% of the time I just go ahead and commit and push everything, and 90% of rest of the time it suffices to just untick the checkboxes next to files that I don't want to commit before clicking the commit button in TortoiseHg. This is massively easier than any of these strategies, and it's opt-in. I'm sure there is a command line way to do this but I find a GUI is great for this task because it's quite visual.)

chousuke 8y ago
> Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind). I don't get it. What does mercurial have instead of refs? HEAD in git is just one kind of a ref; differentiated from a branch only by when the tooling updates it (ie. when you create a commit in the checked out branch, or when you check out another commit) "branches" are mutable references. "remote" branches are just refs pointing at the commit that was the remote branch the last time you fetched it to your local repository. They're all the same thing in the end, though. The way Mercurial branches seem to be a special thing instead of a property of the structure of a repository is partially why I prefer git. In git, the fact that a "named branch" is actually just a ref to a particular commit that gets updated occasionally makes perfect sense to me. The way mercurial does it has never clicked; why does a branch have to be something special? I mean, in git, a branch that has no ref pointing to it is still a branch, but if you have no reference to a commit, why would its existence matter? Sure, you can end up "losing" commits when working with rebase, but no-one actually leaves their repo that way if the commit was important; you just look it up from the reflog and give it a name again, and it won't get garbage collected. And after a branch is merged, why would you keep around a named reference to a branch head that no longer matters? IIRC mercurial has a feature to "close" branches, but I don't understand why that even needs to be a thing? In git, you just delete unnecessary branches (that is, refs), and you're done. Maybe I misunderstand how mercurial works, but I've not found a source explaining the rationale behind why it works this way.