Hacker News Reader

Comment by lmm | Hacker News Reader

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.

View on HN

> 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.

> 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.

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.

Reply on news.ycombinator.com