Hacker News Reader

Comment by m12k | Hacker News Reader

Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff really is non-trivial. Could it be made easier? Yes, by limiting what operations you're even allowed to make, and streamlining those (c.f. git flow).

View on HN

Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't?

If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?

Why can't I pull without fetching?

Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"?

Why is there no way to stop git from setting master as the upstream every time I do git checkout -b myfeature origin/master?

Why do I have to detach from a branch before deleting it?

None of this stuff is inherent to the problem or due to being a precise model of things; quite the opposite.

> Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't?

What do you mean by this? It sounds like how stash already works.

> If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?

This is how git has worked for years: you can checkout a non-conflicting branch without stashing.

> Why can't I pull without fetching?

Have you customized Git to not support this?

> Why do I have to detach from a branch before deleting it?

When does it make sense to do this? I can understand deleting a remote branch (which doesn’t require this) but deleting the current local branch doesn’t seem to make sense in any normal workflow.

> What do you mean by this? It sounds like how stash already works.

I want to switch branches when I have some added (staged) changes and some unstaged changes, and keep the same set of staged and unstaged changes afterwards.

> This is how git has worked for years: you can checkout a non-conflicting branch without stashing.

Only if none of the changes are to the same file, even if they don't conflict.

> Have you customized Git to not support this?

If I do "git pull" it does a fetch and then something else. I'd like to do just the part that's not a fetch (because I fetched the same remote recently).

> When does it make sense to do this? I can understand deleting a remote branch (which doesn’t require this) but deleting the current local branch doesn’t seem to make sense in any normal workflow.

When I've finished working on something and aren't going to work on that repo again for a bit, I'd like to delete the feature branch that I just merged remotely, but I don't want to check out anything else in particular. So I usually end up doing a git checkout --detach just so that I can delete the branch, which feels cumbersome.

> If I do "git pull" it does a fetch and then something else. I'd like to do just the part that's not a fetch (because I fetched the same remote recently).

Pull = fetch remote branches + merge remotes -> local tracking branches

If you want to do the second part without the first, the git merge command will do it.

From the first line in the man page for git-pull:

"Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD."

But FETCH_HEAD only exists because of the fetch command. Git knows what the upstream branch for this branch is. It should know what the remote-tracking branch for that branch is. So why isn't there a command to merge that branch in?

Git remote-tracking branches are just a cache except when they're not. A better model would be for every command that can interact with remote refs to fetch first by default (like pull does) but take an option to "work offline" and use the remote-tracking version (which would then be a proper cache). Or vice versa, for every command to not fetch unless given a parameter that tells it to. It's ridiculous to have to guess which commands will fetch or not.

1. This isn't currently possible. It would require git to track the staging area for each commmit and branch.

2. See 1.

3. `git pull` by definition conducts a fetch because it Incorporates changes from a remote repository into the current branch.

4. Use `git config push.default current`.

5. Use `git branch --no-track new existing`.

6. I assume this is something to do with the reflog.

> Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't?

But git stash does keep track of what it added?

> If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?

If your current changes apply to files which haven't changed between said branches, you don't need to stash your changes when switching between them.

> Why can't I pull without fetching?

The command for that is `git merge`.

> Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"?

The command for that is `git push origin HEAD`.

> Why is there no way to stop git from setting master as the upstream every time I do git checkout -b myfeature origin/master?

The option for that is `--no-track`.

> Why do I have to detach from a branch before deleting it?

Because the `git branch` command never changes the working tree, which in this case uses the branch name to identify its location. If the branch were to be deleted without first detaching (or switching to a different branch), stuff would break.

> But git stash does keep track of what it added?

Added as in staged

> If your current changes apply to files which haven't changed between said branches, you don't need to stash your changes when switching between them.

Yeah, I know. So why do I have to stash when I've changed an unrelated part of the same file?

> The command for that is `git merge`.

But that doesn't know which branch is upstream, I have to tell it explicitly each time.

> The command for that is `git push origin HEAD`.

I want "git push" to just do that.

> The option for that is `--no-track`.

Yeah, I know, but I wish I could just turn it off for when I forget, or when I'm doing it from an IDE or similar.

It would be great to have a GUI tool that allows you to do common tasks with a sort of Wizard interface with validation, precise human-understandable explanations, delayed execution (like GParted) and Undo functions. Personally, I don't use GUI tools for Git because they are either as complex as the command line version or I'm afraid they do something under the hood that is not what I intended. I'm not sure GUI tools for Git are programmed in a way that makes data loss impossible.

Some kind of troubleshooter GUI tool that covers 90% of all use cases would be great. I'd certainly be willing to pay for it.

Exactly what I feel about this tool. I don't get it what is the structure of the inner tree of git changes. Once I though I understand those graphical graphs where branches go out of other branches and than after some commits are merged back. But then I learnt something more and I lost confidence in what I believed before.

yes agreed. very well said.

Reply on news.ycombinator.com