Hacker News Reader

Comment by SEJeff | Hacker News Reader

My personal favorite two:

    jschroeder@omniscience:~$ git config alias.up
    pull --rebase
    jschroeder@omniscience:~$ git config alias.down
    push

They can be used thusly:

   git up && git down

View on HN

While these aliases are useful, I'm confused why "down" means "push".

Well, if you think of yourself of the ruler of the repo and "pushing down" to the plebs, it makes sense ;)

Well git up is a literal translation of what svn up does. git down is just funny. Being a child of the early 80s, I guess it makes me think of this awful old school rap:

https://www.youtube.com/watch?v=OwU32Fa_Mko

"The enemy gate is down."

I love the implication that the upstream repo is the enemy, so you mentally put it down. Way to go Ender.

I like where your head's at and added a little something to help me here at work:

    void:~% git config alias.funky
    ! git up && git submodule update

And speaking of lesser known commands, I've been using 'git worktree' recently at work and I'm a big fan. Admittedly, it's probably mostly unknown because it's a new feature.

It's a little rough around the edges, but it has made things like customer support context switching much easier since I can leave my current development tree alone and just create a new worktree for the current escalation.

Could you share your workflow with worktree a little? What kind of development do you do and where does it fit in with your workflow?

I tried using it in a JS project for those times when I'm in the middle of work but someone asks "hey is master working fine on your system?" - eventually though, having to install all the node and bower modules and rebuild everything on the worktree didn't seem much smoother than just stashing my local changes.

Well, admittedly my current situation lends itself well to 'worktree' where normally a stash is probably just fine.

At the moment I'm doing a big rework (porting our software from a 10 year-old OS to CentOS 7), so I have many, many modified files (all tiny mods to fix new compiler warnings from new toolchains) and untracked and obsoleted files.

Basically, it's too much for me to keep track of if I change anything, so it's a case of "whatever you do, don't touch" that pushes me toward the worktree solution.

I've been pulled in to work on customer escalations on released code (one instance from 2 releases ago), so it's just easier for me to create a whole new worktree.

I imagine that once I'm back into a normal dev cycle that I'll be back to stashing.

"Here let me UPload the local repo to our git server" git down

"Great now let me DOWNload the changes to another branch" git up

What?

I think the 'up' is as in 'update' rather than 'upload', but I agree that the use of 'down' makes that confusing.

Years ago... I was a pretty prolific svn user. Coming from svn, I knew that it would fetch changes from the central server (remote in git parlance) and then rebase them with whatever you had in your local tree. This is where git up came from, literally an equivalent of svn up.

I would name them "down" and "up" instead.

I always do this together, so I just use `git push-pull`

  $ git help push-pull
  `git push-pull' is aliased to `!git pull --rebase && git push'

same functionality, my alias is "rush"

$ git rush

I have up aliased to

  pull --rebase --stat

That gives me an idea of what has changed, Though I often follow with:

  git log @\{1\}..

I would name them the other way around since I'm pulling "down" and pushing "up" ....

Reply on news.ycombinator.com