2

I run two VM's on my host where I copy code over from the host OS to each guest OS so I can compile modules and load/test in the kernel.

The host OS is loaded with tools/utils/desktop, but each VM is minimal plain, not much other than a compiler, few tools and scripts. So my process is change code on the host, and copy to each guest to compile, load, test. If I made changes to a guest, I'd just have to copy to the host and other guest.

So now I've just converted to using git where I put same code on the host, and wondering if there's a way to do pulls from changes I've just made on the host (w/o commits), and then all I have to do is let git pull them over, and then I can push them back. Lots of push and pull between guest and hosts before I'm ready to commit on the host.

If git can do that, that would work great for me. Possible?

Ender
  • 1,652
  • 2
  • 25
  • 50
  • pushes and pulls sync commits. If you don't capture your work in commits, then pulls and pushes won't do anything. Perhaps you want branches? Commit your work to a branch, then you can push/pull that branch as many times as you like before merging it to master. – Paul Hicks Nov 06 '15 at 02:11

1 Answers1

1

As Paul Hicks already noted in a comment, push works on commits, so if you don't have actual commits, there's nothing new to push.

It's also worth noting that pull isn't really a thing. Or perhaps more precisely, it's two things. The pull script is just a convenience shortcut for doing git fetch followed by git merge. It's the git fetch step that talks with another (remote) git, and that too works based on commits. (You can configure git pull to use git rebase instead of git merge, and usually you should do that—or simply do the two steps yourself: git fetch, then after checking the result if desired, git rebase or git merge as appropriate. Separating the two steps lets you see what you'll rebase or merge with. Often there's no need to look first, but if you want to, it's noticeably easier to look before, than after.)

There's nothing wrong with making lots of commits on lots of temporary branches and then using the final version(s) to make the "real" commit on the "real" branch. Git supports this directly using squash merges. Once you've done the squash-merge you can delete the temporary branches. Or, if you'd like to save all the intermediate work, do a regular (non-squash) merge, and again afterward you can delete the temporary branches.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775