I am just starting to learn git. I would like to start by using git to work
remotely. My work computer and home computer both run Linux. I can log into my
work computer from home, but not vice versa. For several years, I have been
using ssh (with X forwarding) to login to my work computer from home. I have
been basically using my home computer as an X terminal. I would like to start
actually working locally on my home computer and use git to stay sync'd with my
work computer.
I created a git repository on my work machine, and I cloned it on my home
machine. As a test, I edited a file on my home machine and pushed it to my work
machine. I guess I don't understand how to use push. I got this:
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 278 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning:
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning:
warning: To squelch this message, you can set it to 'warn'.
warning:
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.
To ssh://localhost:6666/home/paielli/scala
7ea65c7..c52864c master -> master
What does this mean in English? And what is the correct way to transfer my
revisions from my home computer to my work computer? Thanks.
Russ P.
On Sun, Jan 24, 2010 at 07:04:59AM +0000, Russ Paielli wrote:
warning: updating the current branch
[...]
What does this mean in English? And what is the correct way to transfer my
revisions from my home computer to my work computer? Thanks.
It means your workflow will cause problems as the pusher magically
changes your repository's concept of "the latest commit" behind the
pushee's back. The workflow you want is described here:
http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
-Peff
On Sun, Jan 24, 2010 at 3:15 AM, Jeff King [off-list ref] wrote:
On Sun, Jan 24, 2010 at 07:04:59AM +0000, Russ Paielli wrote:
quoted
warning: updating the current branch
[...]
What does this mean in English? And what is the correct way to transfer my
revisions from my home computer to my work computer? Thanks.
It means your workflow will cause problems as the pusher magically
changes your repository's concept of "the latest commit" behind the
pushee's back. The workflow you want is described here:
http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
Aside, and I think we've discussed this before, but I wonder if it
would make sense to:
a) Add an option to clone such as "-p [<name>] | --push-as[=<name>]"
where <name> defaults to $(uname -n | cut -f1 -d.) This would setup
the cloned repo with a push refspec
"+refs/heads/*:refs/remotes/<name>/*". e.g.:
$ git clone -o host1 -p host2 ssh://host1/~/repo.git
$ cat repo/.git/config
...
[remote "host1"]
url = ssh://host1/~/repo.git
fetch = +refs/heads/*:refs/remotes/host1/*
push = +refs/heads/*:refs/remotes/host2/*
b) The controversial part: make this option the default the default
when cloning from a non-bare repo. There would need to be some way to
turn it off.
Of course, I'm not sure this would be any less confusing for users.
Would they wonder why they have to merge to see their pushed changes
reflected on the pushed-to repo?
It does nicely make push symmetric to fetch between two non-bare repos
though, and I think maybe that makes more sense.
j.
On Sun, Jan 24, 2010 at 06:59:10PM -0500, Jay Soffian wrote:
quoted
http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
Aside, and I think we've discussed this before, but I wonder if it
would make sense to:
a) Add an option to clone such as "-p [<name>] | --push-as[=<name>]"
where <name> defaults to $(uname -n | cut -f1 -d.) This would setup
the cloned repo with a push refspec
"+refs/heads/*:refs/remotes/<name>/*". e.g.:
$ git clone -o host1 -p host2 ssh://host1/~/repo.git
$ cat repo/.git/config
...
[remote "host1"]
url = ssh://host1/~/repo.git
fetch = +refs/heads/*:refs/remotes/host1/*
push = +refs/heads/*:refs/remotes/host2/*
One problem with this scheme is that it actually does two things:
1. Tells git to push into the refs/remotes/host2/ hierarchy instead of
refs/heads/.
2. Overrides matching behavior to push all heads.
Point (2) is less of a problem than it is without (1) in the sense that
you are pushing to a unique namespace, so you don't have to worry as
much about your crappy half-finished branches filling up the main branch
namespace. But you might not want them publicized at all, either because
they are embarrassingly bad or simply because it is cruft that you will
encounter later and wonder "is this branch, which is missing from my
local repositor (presumably from a long-ago deletion) but present
upstream of any value at all?"
I can't think offhand of a way to get the behavior of (1) without (2).
I know we have a shorthand refspec for "matching", but this would not
strictly be matching. It is "convert refs/heads/X into
refs/remotes/blah/X, and _then_ match".
If we had a refspec that worked in that manner, I would think it's a
pretty good idea (even to turn it on by default for non-bare repos).
b) The controversial part: make this option the default the default
when cloning from a non-bare repo. There would need to be some way to
turn it off.
Hmm. Do we reliably know from the client side whether a remote is bare
or not?
Of course, I'm not sure this would be any less confusing for users.
Would they wonder why they have to merge to see their pushed changes
reflected on the pushed-to repo?
Yes, I think we would still have the FAQ of "I pushed my changes, where
did they go?" but at least the answer would be "git merge foo" and not
"what you are doing is confusing to git and you need to figure out what
kind of workflow you want, redo your push, and then git merge foo".
Which seems like an improvement to me. ;)
-Peff