0

I often have this issue (this workflow makes sense doing python):

  1. work locally in a change (usually just a couple of lines)
  2. rsync to the staging server
  3. test it there
  4. if it doesn't work, go to step 1
  5. if it works, commit, push and go to sleep

Note: I really do not want to commit my work: it is a couple of lines, and I haven't the slightest idea if it makes any sense at all before testing it on the staging server

I do step 2, which I hate (rsync is not that easy to use - timestamps, delete files, permissions and what-not) because git does not allow me to move around non-committed work.

I know I can prepare patches, or bundles, but those are not the right solution, because that's even more complicated than doing rsync. I will stick to rsync if there is no other option than patch or bundle.

Is there a way of moving around non-committed work with git, easily, like this?

devel $ git upload # uploads non-committed work to the remote
staging $ git download # downloads non-committed work from the remote

I guess not, but I had to ask ...

Note

git stash comes close to what I want, but AFAIK it's not possible to push stashes. Otherwise I would to:

devel $ git stash
devel $ git push # push the stash stack (not really possible with git)
staging $ git pull # get the stash stack (not really possible with git)
staging $ git stash pop
blueFast
  • 41,341
  • 63
  • 198
  • 344
  • 4
    Ding dong! Git is not a deployment tool. – hek2mgl Aug 21 '15 at 12:35
  • 3
    You could commit the work to a separate branch and push & pull that. – jwodder Aug 21 '15 at 12:35
  • 1
    @hek2mgl: git is whatever it can do ... – blueFast Aug 21 '15 at 12:38
  • @jwodder: sure, but then I have to checkout the branch, push, pull, and in the server checkout a tracking branch ... I am not creating a branch because I want to track my progress, I am just creating a branch because *git can not share un-committed work* (that is, working around a git limitation). And if I want to do that, the rsync route is easier – blueFast Aug 21 '15 at 12:40
  • 3
    @jeckyll2hide you can hammer in nails with a microscope, but it would be easier to use a proper tool. But if you really want to use git, then google 'git push stash stack'. I am sure you can push stash to a remote – Konstantin Aug 21 '15 at 12:47
  • @Alik: I argue that git would be the proper tool to implement this because it is non only the tool that we use to do source control, but *also* to share code. Git has access to the repository, including the working directory, so it would be trivial to implement a "push working directory without committing" feature. Whether that would encourage sane workflows or not is another issue ... – blueFast Aug 21 '15 at 12:51
  • I use a workflow similar with yours and it works just fine. I created a short shell script that I use for sync. It started with that long `rsync` command line and later I added small pieces to it (extracted hostname and destination directory into variables to change them easily when needed) but it's still short, just several lines of "code". – axiac Aug 21 '15 at 12:51
  • 1
    The other commenters are generally focused on why Git isn't a good tool to do what you want. They're right, but IMO they're missing the bigger picture. In my experience having a fully functioning dev instance on my local machine is hugely beneficial. Is there any reason you have to test your changes on the server? Tools like [Vagrant](https://www.vagrantup.com/) and [Docker](https://www.docker.com/) are making it easier than ever to develop locally in a server-like environment. – ChrisGPT was on strike Aug 21 '15 at 12:57
  • @axiac: yeah, I have been using that workflow for a long time, but each time that I need to setup a new project, I wonder why on earth does git not have this little feature. – blueFast Aug 21 '15 at 13:01
  • @Chris: thx, sure, I have tried that in other projects and it is fine, but come on ... I am complaining about an rsync command! Do you think I am going to solve that wiring up everything via docker (all 10 components that are already working on my staging server) only so that I can avoid that rsync command? Not today! – blueFast Aug 21 '15 at 13:03
  • @jeckyll2hide, you'll note that I put my suggestion in a comment and not an answer. It certainly doesn't solve your immediate problem. – ChrisGPT was on strike Aug 21 '15 at 13:20

3 Answers3

4

Your problem seems to be a development environment which is completely useless for testing. Having to deploy every trivial code-change to the staging server even when you "haven't the slightest idea if it makes any sense at all before testing it on the staging server" then it shouldn't go to the staging server.

Try to set up your development environment in a way that you can test your code in the development environment and make sure it at least works rudimentary before you have to move it to another server (regardless if you use rsync, git, ftp, copy&paste or whatever).

The push to the staging environment should only be done with code you assume to be working so it can be tested in a new environment and make sure it is actually working there before deploying it to the production environment.

A development environment which allows you to test changes immediately is of great value in software development. It's not just the one minute you shave off with deployment time everytime you test a change (although even that alone might make up for it quite quickly). It also improves your concentration because there is less time between writing the code and testing the code. Further, it encourages you to test your code more frequently. A few hours spent on setting up a proper development environment really pays off in the long run.

Philipp
  • 67,764
  • 9
  • 118
  • 153
  • I am going to give you a real reason why this does not always apply. I am setting up a jenkins CI in the server. For that, I have a shell script, which I have written on my local machine, of course. I am quite confident the script is correct, but haven't run it in my local machine (I do not want jenkins installed in my local machine!). So I want to run it in the jenkins server: I can rsync to it, or I can `git upload` to it (which I would prefer but doesn't exist). I can not test the script in my local machine, because I *do not want* this to ever be run on my local machine. – blueFast Aug 21 '15 at 13:10
  • 1
    Have you heard about `Vagrant`? – hek2mgl Aug 21 '15 at 13:14
  • 4
    @jeckyll2hide You *do* want this to run on your local machine. When you are afraid of damage, consider setting up Jenkins in a virtual machine and share the directory with your scripts between the VM and your host OS. – Philipp Aug 21 '15 at 13:15
  • 1) my local machine and the CI server are different. 2) I'll be the judge if I want it or not! And I tell you: I do not want it. What I want (really, I know what I want): a quick and dirty way of pushing the working dir. If git does not give it to me, I stick to rsync. – blueFast Aug 21 '15 at 13:18
  • @hek2mgl: sure, and docker, and virtualbox, and xen, and and and. But that's not what I am asking. I want a quick and dirty way of pushing a working dir, ala rsync. – blueFast Aug 21 '15 at 13:25
2

No, you can't with Git. But probably makes more sense to create a new branch when you are just exploring a new solution rather than trying to work outside the control version system. Then I ask you: why someone would work outside such a control system? Isn't it tough to track you errors and/or successes?

pietro909
  • 1,811
  • 1
  • 19
  • 26
  • As it is, there are enough errors that make it to the repo without realizing it. I do not really need to keep track of every little thing that I am trying. To push it to the extreme: why would I even commit a one-line change which is actually a syntax error? I need to check it on the server. I can keep track of interesting pitfalls somewhere else (maybe in a "lessons learnt" org-file) – blueFast Aug 21 '15 at 12:58
  • 1
    @jeckyll2hide As long as you are working on a separate branch, meant for *your* development only, you can commit, push whatever broken, unfinished state you like and rebase if you want to change the commit afterwards. This is how I'm using git during development phase of a feature: commit some weird state, message: "foobar, I'm tired for today". push! .. The next day I go on and rebase the unfinished commit from yesterday, or simpler: git comit --amend. – hek2mgl Aug 21 '15 at 13:06
  • @hek2mgl: branch + checkout + push + pull + remove branch vs rsync. Just guess what I choose! – blueFast Aug 21 '15 at 13:12
  • I don't get that comment. – hek2mgl Aug 21 '15 at 13:13
  • @hek2mgl: that workflow is too complex for that I want to do. I just want to have my latest changes on the server, for a quick and dirty test. `rsync` is easier to type. – blueFast Aug 21 '15 at 13:16
  • @Trengot :) Hihi! Of course once I'm finished I'll rebase them and create a proper crafted commit message. I really, really like that git is allowing me to do so. – hek2mgl Aug 21 '15 at 13:34
  • @hek2mgl: it is great that you are allowed to work like that! It is not so great that you are *forced* to work like that! We need a `git push-wd` / `git pull-wd`! – blueFast Aug 21 '15 at 13:36
  • 1
    @jeckyll2hide We also need a `git tetris` for situations when we are bored. What I want to say is that following the principles of UNIX programming a tool should solve a certain purpose. Since you can use `rsync`, a powerful file transfer tool, why `git` should attempt to duplicate this feature? It is a version control system. Btw, the funny fact is that `git` can use rsync (beside others) for the file tranfer, meaning it is able to do the job for you. You simply need to use git's features - and branch like we've suggested. – hek2mgl Aug 21 '15 at 13:41
  • This is no `git tetris`! `git` is able to share code in the repo *except* for non-committed work. That design decission ("non-committed work is not pushable") is counterintuitive and arbitrary: it would be easy to have a `push-wd` command which is able to create a "temporary throw away commit" which can be pushed and pulled as any commit. Having it as a separate command (`push-wd` vs plain `push`) would discourage misuse. – blueFast Aug 21 '15 at 13:51
  • By its own nature and intended use (quick sharing of current work), the temporary throw away commit would have no commit message. It could work similarly to the stash area. – blueFast Aug 21 '15 at 13:54
1

I can see 2 different approaches if you want to do this with git:

  • Stashing your "uncommited" (when you stash something git actually creates a commit) changes and pushing stash to a remote. See this answer for details
  • Making a patch and applying it on a server. See this answer

But I highly recommend you to use other tools or even consider Vagrant to set up a development environment on your machine.

Community
  • 1
  • 1
Konstantin
  • 24,271
  • 5
  • 48
  • 65
  • stashing comes close, as said, but is too cumbersome a workflow. Sharing stashes looks even more complex than sharing patches or bundles. rsync is easier. – blueFast Aug 21 '15 at 13:23
  • @jeckyll2hide make a simple bash script so it will be as easy as typing `rsync` into shell – Konstantin Aug 21 '15 at 13:58
  • Yep, I already have that. Would still love to have that feature available in git though. – blueFast Aug 21 '15 at 14:03