git and commiting

git and commiting

[Mateusz Berezecki]

Hi list readers,

How to commit and check-in changes done to the checked-out source code?
The "git commit" command seems to only commit the changes locally
without pushing them via rsync.
Is there any way I can push commits via rsync? Am I missing the point
and git commit is not enough?

please CC me with the answer as I am not subscribed to the list.


regards
/mb

Re: git and commiting

[Linus Torvalds]

On Fri, 8 Jul 2005, Mateusz Berezecki wrote:
> 
> How to commit and check-in changes done to the checked-out source code?
> The "git commit" command seems to only commit the changes locally
> without pushing them via rsync.
> Is there any way I can push commits via rsync? Am I missing the point
> and git commit is not enough?

"git commit" is "enough" in the sense that it does indeed commit 
everything to the local tree, and often that is enough.

But what you're asking for is to _export_ the changes to others. And 
that's a different issue.

There's actually two different parts to exporting your changes:

 - making your existing tree (or branch) available as-is on some public 
   place.

   This is done with

	git-send-pack <destination> [branches]

   where the destination can either be a locally writable tree, or it's a 
   ssh-format remote tree (ie you need to have some place where you can 
   log into with ssh).

   For example, when I export my kernel changes, I do so with

	git-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6

   which I have in a "push-all" script in my kernel directory (so that 
   regardless of what project I'm working on, I can just do "./push-all" 
   to push it to the repositories I have as the public destinations).

 - other people will _pull_ the changes (ie you don't push them to others: 
   you publicize, and then it's up to others to decide whether they want 
   to pull your tree).

Now, there's one special case, namely when you use a shared "CVS-line" 
repository that multiple people push to. If you do that, then you are both 
pusher and puller, and exactly like with CVS, you'll have to be up-to-date 
in order to push. So before you do the git-send-pack, you should first see 
if you need to update with work that other people have done in the shared 
repository, ie it might look something like this:

	git pull repo.work.com:/project/work.git branch
	git-send-pack repo.work.com:/project/work.git branch

where the first command makes sure that you're up-to-date (and as with 
"cvs update", you may need to fix up any merge issues), and the second 
command then pushes back the merge results.

NOTE NOTE NOTE! As it stands, git-send-pack is really geared towards _my_
kind of usage, ie it is geared towards sending to a public repository that
doesn't have other people pushing to it (ie it's "public for reading", but
it's "private for writing"). That's the way _I_ work, but it's not the 
way you'd work in a more CVS-like environment with multiple people that 
push to a common repository.

What this means is that "git-send-pack" is a bit too eager to try to make
the other end look exactly like _your_ end. It's a bit too easy to re-set
a branch that somebody else may have changed to what _you_ happen to have
in your tree, so be careful. The data doesn't go away, of course, but if
you reset a branch the old contents aren't reachable any more, so it might
as well be considered gone (you can use "git-fsck-cache" to find the
non-reachable commits and re-name them to some new branch, but the point
is that it's real work).

I'll try to make git-send-pack much more careful about setting branches to 
new values.

		Linus