4 ms·

My personal favorite two: jschroeder@omniscience:~$ git config alias.up pull --rebase jschroeder@omniscience:~$ git config alias.down push The

by SEJeff 10y ago

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

michaelmior 10y ago
While these aliases are useful, I'm confused why "down" means "push".
- k__ 10y ago
  Well, if you think of yourself of the ruler of the repo and "pushing down" to the plebs, it makes sense ;)
- pkamb 10y ago
  "The enemy gate is down."
  - sqeaky 10y ago
    I love the implication that the upstream repo is the enemy, so you mentally put it down. Way to go Ender.
- SEJeff 10y ago
  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 https://www.youtube.com/watch?v=OwU32Fa_Mko
etqwzutewzu 10y ago
I would name them "down" and "up" instead.
komali2 10y ago
"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?
- JadeNB 10y ago
  I think the 'up' is as in 'update' rather than 'upload', but I agree that the use of 'down' makes that confusing.
  - SEJeff 10y ago
    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.
smazga 10y ago
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.
- spinningarrow 10y ago
  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.
  - smazga 10y ago
    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.
kentosi 10y ago
I would name them the other way around since I'm pulling "down" and pushing "up" ....
CGamesPlay 10y ago
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'
- andreineculau 10y ago
  same functionality, my alias is "rush" $ git rush
opk 10y ago
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\}..

by SEJeff 10y ago

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

michaelmior 10y ago

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

k__ 10y ago
Well, if you think of yourself of the ruler of the repo and "pushing down" to the plebs, it makes sense ;)
pkamb 10y ago
"The enemy gate is down."
- sqeaky 10y ago
  I love the implication that the upstream repo is the enemy, so you mentally put it down. Way to go Ender.
SEJeff 10y ago
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 https://www.youtube.com/watch?v=OwU32Fa_Mko

etqwzutewzu 10y ago

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

komali2 10y ago

"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?

JadeNB 10y ago
I think the 'up' is as in 'update' rather than 'upload', but I agree that the use of 'down' makes that confusing.
- SEJeff 10y ago
  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.

smazga 10y ago

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.

spinningarrow 10y ago
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.
- smazga 10y ago
  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.

kentosi 10y ago

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

CGamesPlay 10y ago

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'

andreineculau 10y ago
same functionality, my alias is "rush" $ git rush

opk 10y ago

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