Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lesser known Git commands

hackernoon.com

Post reply on HN
Print view View original

111–120 of 142 posts

Re: Lesser known Git commands

#111

Post by jakub_g »

__david__ wrote: post #105
dahart wrote: post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

> do people actually find stashing easier than branching? Absolutely. I stash things all the time. I find feature branches only useful for pull requests. My own code never uses feature branches unless I'm unsure of where I'm headed with the feature—I'll need to continually come back to it and build it a little at a time. But that's very rare. > Right from the man page: "If you mistakenly drop or clear stashes, they c…

One of the hardest thing about git is the multitude of options and workflows. It makes it powerful but also intimidating for newbies - so many commands and flags!

Having several years of git experience, I've set up on the following workflow, which avoids stashing and mixed resets. I think it's quite safe and simple.

1. using feature branches for everything (except when I'm the only developer in a given repo); I have `goto` and `forkto` and aliases for git checkout / git checkout -b

2. frequent, small commits - for backups, and to have "recovery point" for this scenario when you change one line and everything's on fire and you can't find out what's going on for next one hour

3. try to never do partial commits, always commit everything ( git add -A . && git commit ). This teaches you a discipline to do one thing at a time. If you have a sudden need to do something else, git branch, git commit, git checkout previous-branch. Or git commit, continue working, git rebase -i to reorder/squash commits later if needed.

4. for "work in progress, will come back later" commit I have an alias "wip" = "git commit -A . -m 'wip'"

5. for permanently throwing away stuff, "git reset --hard" (used rarely)

6. since I do lots of small commits, at the end of development I clean up with `git rebase -i`, squash stuff, improve commit messages if needed, maybe reorder etc.

Due to 2 and 3 I basically don't use stash at all. I think however not everyone is so keen on interactive rebase as much as I do :)

Re: Lesser known Git commands

#112

Post by dahart »

phasmantistes wrote: post #110
dahart wrote: post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

In Chromium (well, actually depot_tools[1], the closest thing Chromium has to a developer SDK) we provide `git freeze`[2] and `git thaw`[3]. These behave similarly to 'stash', but instead of taking your content and putting it who-knows-where, they commit it on top of your current branch in a special FREEZE commit (or multiple commits, if you have both staged and unstaged changes) which they then know how to thaw out…

Brilliant! I wonder why git stash wasn't implemented similarly in the first place.

Re: Lesser known Git commands

#113

Post by dahart »

__david__ wrote: post #105
dahart wrote: post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

> do people actually find stashing easier than branching? Absolutely. I stash things all the time. I find feature branches only useful for pull requests. My own code never uses feature branches unless I'm unsure of where I'm headed with the feature—I'll need to continually come back to it and build it a little at a time. But that's very rare. > Right from the man page: "If you mistakenly drop or clear stashes, they c…

> I find feature branches only useful for pull requests

I wasn't super clear in my top post, sorry. Mentioned a couple times in the thread, but as an alternative to a single stash, I would normally commit, not branch. Consider whether a WIP commit is that much easier than a stash, given that a commit is harder to lose.

I mentioned branches because that's the alternative to a multi-stash workflow, or to having a large time gap with a lot of work in-between stash & pop. Otherwise, my question is how much harder, really, is git commit & git reset --soft, compared to git stash & git stash pop?

> Then don't ever use those commands. I don't.

That seems like a great way to use stash safely. A couple others here mentioned using stash as an alternative to git reset. I'm in favor of that kind of stash usage, it's even safer & easer than losing something to a premature reset.

Re: Lesser known Git commands

#114

Post by brown9-2 »

CGamesPlay wrote: post #86

A few that weren't mentioned below: git alias start 'checkout @{u} -B' All my branches track origin/master (rather than local master), which makes it easy to git push / git pull without extra arguments. This will checkout a new branch from whatever the current branch is tracking. Usage: `git start my-new-feature` git alias track 'track = branch --set-upstream-to' Sets up your current branch to track some other branch…

nitpick: I don't think you need --no-track in `branch --merged` as no branch is being created with that command.

Re: Lesser known Git commands

#115

Post by majewsky »

prashnts wrote: post #56
ryanSrich wrote: post #17

Earlier quoted context omitted.

I use stash when I forget to branch. So I might be working and then realize I never branched. So I stash my changes, create a new branch, and then pop my changes on the new branch.

I use `legit` aliases for this. It allows me to do `git sprout `, where it stashes my untracked changes, create a new branch, pop the stash and applies it. Pretty handy! legit: https://github.com/kennethreitz/legit [1] [Ignore the pretentious "for humans" tagline though...]

`git sprout ` looks identical to `git checkout -b `.

Re: Lesser known Git commands

#116

Post by anarcat »

one thing i wish git would do would be to allow me to specify default options for certain aliases. for example, I quite like the `--short --branch` format of git status. but I can't do this:

  [alias]
     status = "status -sb"
because git just ignores those. i am then forced to setup non-standard commands just to bend git to my will.

in some cases, there are distinct `git-config` options I can set to get the right behavior, but that's way less flexible since stuff like `--force-with-lease` don't have their own config options.

the rationale behind this is, according to the git-config manpage, that "To avoid confusion and troubles with script usage, aliases that hide existing git commands are ignored". but then there's --porcelain for that, so i don't understand that limitation.

sigh.

Re: Lesser known Git commands

#117

Post by derefr »

dahart wrote: post #112
phasmantistes wrote: post #110

Earlier quoted context omitted.

In Chromium (well, actually depot_tools[1], the closest thing Chromium has to a developer SDK) we provide `git freeze`[2] and `git thaw`[3]. These behave similarly to 'stash', but instead of taking your content and putting it who-knows-where, they commit it on top of your current branch in a special FREEZE commit (or multiple commits, if you have both staged and unstaged changes) which they then know how to thaw out…

Brilliant! I wonder why git stash wasn't implemented similarly in the first place.

My hypothesis: git was implemented assuming that—at least for large projects—you would have a local on-disk bare clone of the repo, and then multiple workdir checkouts of that bare clone sitting on different branches. The setup with a single clone containing a workdir with a .git dir inside it is a hack that's nice for "on-the-go" use-cases, but wasn't intended for serious developers contributing many changes to the same codebase.

git-stash, then, is only for the use-cases that are not better solved by just leaving your WIP workdir as it is and checking out another, concurrent workdir for your new feature. Such as, for example, taking code you were accidentally writing on one branch, and "shifting it over" onto some other branch; or "moving your changes out of the way" to run some tool that is broken by them, then putting them back in place, because you really still are working on them.

Re: Lesser known Git commands

#118

Post by _lce0 »

anarcat wrote: post #116

one thing i wish git would do would be to allow me to specify default options for certain aliases. for example, I quite like the `--short --branch` format of git status. but I can't do this: [alias] status = "status -sb" because git just ignores those. i am then forced to setup non-standard commands just to bend git to my will. in some cases, there are distinct `git-config` options I can set to get the right behavior…

    [alias]
      pull = push
      push = pull
:)

Re: Lesser known Git commands

#119

Post by Asooka »

derefr wrote: post #117
dahart wrote: post #112

Earlier quoted context omitted.

Brilliant! I wonder why git stash wasn't implemented similarly in the first place.

My hypothesis: git was implemented assuming that—at least for large projects—you would have a local on-disk bare clone of the repo, and then multiple workdir checkouts of that bare clone sitting on different branches. The setup with a single clone containing a workdir with a .git dir inside it is a hack that's nice for "on-the-go" use-cases, but wasn't intended for serious developers contributing many changes to the…

Er... but then you have (N+1) checkouts of the repository where N is the number of workdirs, no? How does this even work with submodules? Will I have a copy of the submodules tree in each workdir? Our submodules tree is like 4Gb at this point, I can't very well have 5 of them. Disks are large, but not yet infinite.

Re: Lesser known Git commands

#120

Post by derefr »

Asooka wrote: post #119
derefr wrote: post #117

Earlier quoted context omitted.

My hypothesis: git was implemented assuming that—at least for large projects—you would have a local on-disk bare clone of the repo, and then multiple workdir checkouts of that bare clone sitting on different branches. The setup with a single clone containing a workdir with a .git dir inside it is a hack that's nice for "on-the-go" use-cases, but wasn't intended for serious developers contributing many changes to the…

Er... but then you have (N+1) checkouts of the repository where N is the number of workdirs, no? How does this even work with submodules? Will I have a copy of the submodules tree in each workdir? Our submodules tree is like 4Gb at this point, I can't very well have 5 of them. Disks are large, but not yet infinite.

Directory hard-links?
Post reply on HN