121–130 of 136 posts
Earlier quoted context omitted.
Yeah, deleting a remote branch by "git push remote :branch" is pretty terrible, one colon between heaven and hell.
If you understand how git push works, it sort of makes sense. But fortunately the devs added a --delete option to git push which is much more clear.
They say it's for humans, but then explain the commands in terms of "normal git". This'd made a lot more sense for me if they explain for what particular workflow it's intended and how to use it as such. With examples and all.
Maybe I should update it to "Git for Humans (that already use git)"
1. It's casually dismissive of us cyborgs, who are too often marginalised already;
2. It's a subjective claim;
3. It claims you have taste that your competitors lack;
4. I've seen enough examples where my taste finds something inferior or seriously wrong with the design (not saying this is the case here) that I don't take these claims seriously.
Earlier quoted context omitted.
I'd be curious to see a few examples. Git is guilty of using a bunch of non-standard nomenclature, and of using existing terms in non-standard ways ("checkout", I'm looking at you). But I certainly wouldn't call the interface or syntax "inconsistent" or "random". It's actually very tersely designed and very well put together. The "actual concepts" are, for the most part, first class citizens in the interface.
> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…
> I can `checkout remote-name/branch` but I have to
> `push remote-name branch`
> Deleting a local branch is `branch -D` but deleting a
> remote branch is (I still can't fucking believe it)
> `push remote :branch`.
In any case, writing to remote repos was never part of the core design of git. It was designed to be a distributed group of people that would pull down remote branches, make changes, and then submit pull requests to the code maintainer (or use the various 'email patch' commands). Remember that it was developed with Linux kernel development in mind, where there is a hierarchy of developers responsible for sections of the codebase.
Earlier quoted context omitted.
So, in the end it worked on a file. :-)
It worked on a branch, filtered by a file name. I think that's an important distinction. That distinction unifies the definition of `git checkout`.
But it doesn't lead to an obvious, consistent command syntax, and that was the point.
Earlier quoted context omitted.
> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…
> for someone who doesn't understand git internals Looks like that's the difference. As someone who does understand Git internals, everything seems perfectly logical and consistent to me. Perhaps it's the same with the person you are replying to. And really, using Git without understanding the internals is a suicide, quite a few people broke their repos and asked me to recover them. The internals are very easy to lea…
This is called usability.
Earlier quoted context omitted.
> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…
> I can `checkout remote-name/branch` but I have to > `push remote-name branch` So I can use the same command in svn/cvs to switch branches and publish changes? > Deleting a local branch is `branch -D` but deleting a > remote branch is (I still can't fucking believe it) > `push remote :branch`. It's not that hard to understand. Most git commands only affect the local repo, but git-push and git-remote are used to affe…
No, it's about the notation for remotes and branches. It's confusing that sometimes when I refer to a branch I call it remote/branch and other times I call it remote branch. It would've been way more consistent if it were always remote/branch.
As a result, git push sometimes gets confusing. Suppose I'm on staging. I then say, git push heroku staging:master (push the staging branch to the master branch on heroku) whereas git push staging:heroku/master is imho easier to understand.
Earlier quoted context omitted.
> I can `checkout remote-name/branch` but I have to > `push remote-name branch` So I can use the same command in svn/cvs to switch branches and publish changes? > Deleting a local branch is `branch -D` but deleting a > remote branch is (I still can't fucking believe it) > `push remote :branch`. It's not that hard to understand. Most git commands only affect the local repo, but git-push and git-remote are used to affe…
>So I can use the same command in svn/cvs to switch branches and publish changes? No, it's about the notation for remotes and branches. It's confusing that sometimes when I refer to a branch I call it remote/branch and other times I call it remote branch. It would've been way more consistent if it were always remote/branch. As a result, git push sometimes gets confusing. Suppose I'm on staging. I then say, git push h…
> git push heroku staging:master
git push heroku refs/heads/staging:refs/heads/master
git push heroku staging:refs/personal/phillmv/staging
git push ssh://hostname/path/to/repo staging:staging
git push ~pyre/work/repo staging:pillmv-staging
E.g.
% cd /tmp
% mkdir test1 test2
% pushd test1
% git init .
Initialized empty Git repository in /tmp/test1/.git/
% popd
% pushd test2
% git init .
Initialized empty Git repository in /tmp/test2/.git/
% git ci --allow-empty -m 'ini commit'
[master (root-commit) 54ec2a3] ini commit
% git push ../test1 master:test2-master
Counting objects: 2, done.
Writing objects: 100% (2/2), 168 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
To ../test1
* [new branch] master -> test2-masterEarlier quoted context omitted.
>So I can use the same command in svn/cvs to switch branches and publish changes? No, it's about the notation for remotes and branches. It's confusing that sometimes when I refer to a branch I call it remote/branch and other times I call it remote branch. It would've been way more consistent if it were always remote/branch. As a result, git push sometimes gets confusing. Suppose I'm on staging. I then say, git push h…
> git push heroku staging:master Without the shortcuts, this command would be: git push heroku refs/heads/staging:refs/heads/master "refs/heads/master" is literally the branch location in the $GIT_DIR on the remote. You could do something like: git push heroku staging:refs/personal/phillmv/staging to stick the branch in a non-standard location, or you could do: git push ssh://hostname/path/to/repo staging:staging or:…
> git push heroku staging:refs/personal/phillmv/staging
Will it still appear in git branch lists?
I get what you're saying and I appreciate the lesson :).
Is there a reason for the syntax in checkout being remote/branchname then? I care about consistency more than the specific syntax.
Earlier quoted context omitted.
> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…
It's surprisingly hard to unstage a file. Is there a case when it's not a simple git reset my-file away?