4 ms·
"Need to make a new branch? Try git branch--er... I mean 4 seemingly random Git commands that don't include the word branch. " 'git branch <branchname> [start-
by icefox 17y ago
"Need to make a new branch? Try git branch--er... I mean 4 seemingly random Git commands that don't include the word branch. "
'git branch <branchname> [start-point]' creates a new branch....
Maybe he is referring to the fact that git branch wont change change branches? You have to use git checkout to actually switch branches.
"Not only is documentation for some important features sparse, the documentation that does exist is rarely ever of the best quality."
I am curious what specifically he was referring to. The docs on git-scm are pretty extensive. Between the docs, books, cheatsheets, videos there is a ton out there. Even the man pages include example usage where many man pages for command line tools do not.
Something I can't help but ponder is that in switching to the second system they already had a grasp of some dvc concepts making it easier and if trying git second would have been easier.
- viraptor 17y agoI think he meant `git checkout -b ...` since that's what people want to do most of the time. What's the use case for creating a branch if you're not going to use it straight away? (and no 'branch' in the command really)
- jshen 17y agodoes he really have a problem remembering 'git checkout -b ...'? Seems like a non issue to me.
- viraptor 17y agoIt's not an issue, but it can be an annoyance. Put many of them together and you've got a reason why projects like Ubuntu's 100 papercuts exist. If you have to work with something that just isn't quite right even if it works in the end, it can affect your work.
- hannibalhorn 17y agoI always branch before rebasing. Especially when cleaning up history (merging 5-6 "checkpoint" type commits for a big feature into one, etc.) It makes it easy to get back to where you started and you have the original work for reference purposes.
- wmcc 17y agoI think the author meant these commands as I'm in the same OS class and this script has been circulating around the class: $ cat git-create-branch #!/bin/sh if [ $# -ne 1 ]; then echo 1>&2 Usage: $0 branch_name exit 127 fi branch_name="$1" git push origin origin:refs/heads/${branch_name} git fetch origin git checkout --track -b ${branch_name} origin/${branch_name} git pull
- theli0nheart 17y agoWow...just wow. Why would you do this to yourselves? First of all, git push origin origin:refs/heads/${branch_name} is totally unnecessary when creating a new branch. I see that there are remote branches you want to track. It's simple, no need for a script. Just make sure you are synced with the current version of the repo you are using (using `git pull`). Then: git checkout --track -b bugfix origin/bugfix Easy as pie. I even have an alias set when I want to do this, so I just call git cot bugfix origin/bugfix To create a new branch locally (that doesn't track a remote), just call git checkout -b new-feature Note: When using `git pull`, `git fetch` doesn't need to be called. Pulling changes will fetch them for you automatically.
- davidw 17y agoThat's not simple. Simple would be doing what everyone wants it to do with one command that's really easy to remember/discover.
- stevelosh 17y agoThe problem is that every git command tries to be extremely flexible. That means the documentation for command X has to cover everything X can do, and when you're just trying to find out how to do action A you have to skim through all the other crap X can do. For example, 'git help checkout' clocks in at 236 lines. 'git checkout' can change the revision/branch you're at, create a new branch, or revert files without changing HEAD. The help output for the equivalent Mercurial commands: * hg help update: 38 lines * hg help revert: 41 lines * hg help branch: 24 lines If I want to revert a file's contents in a git repo I need to wade through 236 lines to figure out the exact command I need. With Mercurial I need to wade through 41, because I know: "Oh, I'm reverting a file, I need an 'hg revert' command of some kind." Mercurial commands each do one thing (rarely two, almost never more than that) and do it well. If you want to combine commands, write a script. This makes the documentation concise and easy to read as you're working. Git commands each try to be flexible enough to do many different things. The price you pay is that any time you need to read through the documentation it's an exercise in trying to search for a word in a man page and hoping everything you need is somewhere nearby.