Hi,

I have a repository with a working tree on a machine A, did a clone to
another machine B and commited there locally.

I want my changes to get back into the first repository, so I did a
"push". The new commit is in the history, I can see it with "git log",
but the modifications are not in the working tree.

This time, it's OK: I didn't have any uncommited modifications on A,
so I just did a "git reset --hard HEAD" there.

But if I had some uncommited changes, "git reset --hard HEAD" means
data loss, which is precisely what I want to avoid by using a VCS. It
seems a solution is to do:

$ git reset --soft <commit-id-before-the-push>
$ git merge <commit-id-after-the-push>

But it means I have to remember <commit-id-before-the-push>.


I don't understand the design choice here: git had two options to
avoid this scenario:

1) update the working tree while doing the push. That's feasible with
   good performance since git is present on the server, but leaves the
   problem of possible conflicts.

2) let git remember what the local tree points to (not just the branch
   name, but the commit id itself, stored in a place that "git push"
   won't modify). Then, provide me a way to "update" to the latest
   revision.

Fyi, bzr does this. Indeed, in bzr, a branch (let's say "repository"
in the git vocabulary) with a working tree just means a working tree
(AKA lightweight checkout) located in the same directory as a branch.
The working tree knows which revision it corresponds to, and where to
find its branch. There's a "bzr update" command to get my working tree
to the head of the branch, keeping the uncommited changes.

I believe this idea is very much linked to the "Lightweight Checkout"
idea (listed on the SoC ideas), since, in the case of multiple working
directories sharing the same .git, you don't want a commit in one tree
to affect the others.

So, did I miss something? Is there anything on the todo-list?

Thanks,

-- 
Matthieu
-

The general answer (which you've already received) is to tell folks is
to simply don't use "git push" to remote trees; basically, if you ever
have a non-bare repository, it doesn't do what you expect, and it will
leave the novice user horribly confused.  A much better answer is to
simply go back to machine A, and pull from machine B.

I was exploring though to see if there was anything we could do
better, and so I used my standard test repository of the GNU Hello,
world program, and did the following:

	git clone hello r1
	git clone r1 r2
	cd r1
	<edit hello.c's headers to be GPL v2 only>
	git commit -a -m "GPL v2 only"
	cd ../r2
	<edit hello.c so that the message printed is "Hello, world!" 
		instead of "hello, world">
	cd ..

OK, so this sets up the standard test setup of repositories r1 and r2.
r1 contains a committed change so that hello.c is GPLv2 only.  r2
contains an uncommitted change to the actual text printed by hello.c.
The changes are nicely seprated in distaince by over 100 lines, so
there should be no problems with merges.  Let's play...

Experiment #1.  Let's try pushing from r1 to r2.

	cd r1
	git push ../r2

This pushes the change GPLv2 change from r1 to r2.  However, it leaves
the working tree and the index untouched, which leads to some very
unexpected and surprising behavior:

  a) If you do a "git commit" you will commit the current contents of
     the index, which is usually the contents of the head of r2 before 
     the push.
  b) If you do a "git commit -a" you will commit the modified changes to 
     the working directory --- based off of the state of r2 before the
     push.  What will therefore show up in the revision log is something
     which appears to be based off of the more recent change in r1, but 
     which is really based off of the old history as of r2 before the push.

All of this is bad, which is why "git push" to a non-bare repository
is extremely surprising.  (As an aside, what Bitkeeper would do is to
update...
[ message continues ]

It's not really an option in my case. A is a fixe-IP/fixe-DNS machine,
while B is my home machine, behind a NAT modem-router. So, I'd have to
figure out my home IP, port-forward the ssh port from the modem to my
machine, ...

If I understand correctly the other answers, I have two options:

* Git doesn't manage this case, and doesn't care about me loosing data
  if they're not commited, I'll have to do it myself with hooks.

* Create a bare repository on machine A, and clone it to a non-bare
  repo on which I'll work. But that means duplicating the repository
  on the same filesystem of the same machine. Not really satisfactory
  either. The "light checkout" feature would make it better, but I'm
  still worried about what will happen to my light checkout when
  someone pushes to the repository.

-- 
Matthieu
-

Doesn't update hook get pre- and post- commit object name?

-

Yes, and the same is true in the new post-receive hook.

-- 
Shawn.
-

In my comments, I was observing that *after* the push had succeeded,
there was no way to find the commit-id-before-the-push, since neither
the reflog nor ORIG_HEAD is getting updated.  Is there a good reason
why not?  Would you accept a patch which caused the reflog and
possibly ORIG_HEAD to be updated on the remote side of the push?


When I was talking about a hook to enforce the BitKeeper semantics,
the question is whether we have enough to enforce the following:

	* Only accept the push if it will result in a fast-forward
		merge (and if not, tell the user to do a git pull, merge
		locally, and then redo the git push)
	* Only accept the push if there are no locally modified files
		that would be affected when the working directory is
		updated to reflect the new HEAD

I don't think there's any easy way to determine if these two criteria
would be met besides trying to actually do the merge, and if it fails
atomically back out to the original starting point, right?  Or am I
missing something painfully obvious?

Since one of the applications where I might want to do something like
this is a push a web site being maintained by git (where I don't want
any the result of the interim attempted to merge to accidentally get
seen by the web server), probably in order to do this right I'd have
to have the hook script do a cp -rl of the repository+working tree to
some scratch space, try to do the merge and update of the working
tree, and if it succeeds, allow it to happen for real in the "live"
tree, and if not, fail the merge.  This seems awfully kludgy; is there
some other way?

						- Ted
-

The reflog does update if the log file exists during a push (err,
actually during receive-pack).  Or if core.logAllRefUpdates is set
to true.  Now this isn't the default in a bare repository, but it
should be the default in a repository with a working directory.

Yes, the update hook can detect this.  Actually receive-pack by
default rejects *all* non-fast-forward pushes, even if the client

The update hook could also perform this check; test if the ref
being updated is the current branch, and if so, verify the index and
working directory is clean.  That's a simple run of git-symbolic-ref
(to get the current branch) and git-runstatus (to check the index
and working directory), is it not?

If git-runstatus exits to indicate the tree is clean (nothing to
commit) then a simple `read-tree -m -u HEAD $new` should update
the working directory and index, right?

-- 
Shawn.
-

Ah, so that's controlled by receive.denyNonFastForwards, right?  Cool,
I missed that.  Thanks!!

Documentation/config.txt doesn't say it defaults to true, but from

What git-runstatus will allow me to do is to abort if there are any
local modifications, regardless of whether or not they would conflict
with the working tree update.  The key phrase in my criteria was no
locally modified files "THAT WOULD BE AFFECTED".

What I could do with BitKeeper is that I could modify some file like
schedule.html on my webserver, and then push a changeset from my
laptop to would update sermons.html, and it would allow the push ---
since it would change the file sermons.html, and not touch
schedule.html.

But if I modified schedule.html on my laptop and then committed it,
and *then* try to push that changeset to the webserver, it would abort
since in order to accept the changeset, it would have to update the
working tree, and that would clash with the locally modified
schedule.html file.  At thta point I'd have to login to the webserver,
revert the local modification and bring it back down my laptop and
include it in a proper changeset.

Yeah, I probably shouldn't have ever modified the file locally on the
webserver, but that would sometimes happen when I was in a rush, and
it was nice when it Just Worked.

						- Ted
-

Ah, my bad, it defaults to false:

  static int deny_non_fast_forwards = 0;

I should have known better, as I run a 1.5.x (aka 'next') server
for a workgroup and I never have that set, but use instead a complex

  git-diff $old $new | git-apply --index ?

If the patch does not apply, nothing gets updated.  If it does apply,
the index is also updated and stat data updated.

OK, it doesn't quite handle every case, as sometimes a patch will
reject but the internal 3-way merge from xdiff that is called by
merge-recursive will succeed, but this does protect your working
tree and doesn't require making a temporary copy.


Of course another possible approach is to stuff the entire working
directory into a temporary tree, and then merge.  If the merge
doesn't work, you can reset to the temporary tree.  Unfortunately the
working directory is "in flux" during that process... its not atomic.

-- 
Shawn.
-

And if you are only checking then perhaps instead of --index
use --check, so that the actual updates are deferred?

-

So I dug a little more deeply, and the problem is that the reflog for
master was getting updated, but not the reflog for HEAD, and that's
what "git reflog" was showing --- hence my confusion.

What are the rules for when HEAD's reflog should get updated, and is
this documented anywhere in the man pages?

						- Ted

Script started on Sun 18 Mar 2007 11:11:59 PM EDT
Top-level shell (parent script)
Using ssh-agent pid 7679
<tytso@candygram> {/home/tytso/talks/dscm/git}  
1% cp -r test1 test2 ; cd test2
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
2% (cd r2; git-config core.logallrefupdates)
true
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
3% cat r2/.git/refs/heads/master
f2e3cc0bb64c8c94b89ba07bfbdd1653584586f2
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
4% cat r2/.git/logs/HEAD
0000000000000000000000000000000000000000 f2e3cc0bb64c8c94b89ba07bfbdd1653584586f2 Theodore Ts'o <tytso@mit.edu> 1174266825 -0400
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
5% cat r2/.git/logs/refs/heads/master
0000000000000000000000000000000000000000 f2e3cc0bb64c8c94b89ba07bfbdd1653584586f2 Theodore Ts'o <tytso@mit.edu> 1174266825 -0400
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
6% (cd r1 ; git push ../r2)
updating 'refs/heads/master'
  from f2e3cc0bb64c8c94b89ba07bfbdd1653584586f2
  to   37508dc11dbe274d021124057fd2d027f6ce9d17
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
Total 3 (delta 2), reused 0 (delta 0)
Unpacking 3 objects
  100% (3/3) done
refs/heads/master: f2e3cc0bb64c8c94b89ba07bfbdd1653584586f2 -> 37508dc11dbe274d021124057fd2d027f6ce9d17
<tytso@candygram> {/home/tytso/talks/dscm/git/test2}  
7% cd r2
<tytso@candygram> {/home/tytso/talks/dscm/git/test2/r2}  [master]
8% cat .git/refs/heads/master
37508dc11dbe274d021124057fd2d027f6ce9d17
<tytso@candygram> {/home/tyt...
[ message continues ]

It is buried down in write_ref_sha1 (in refs.c).  The rule is if the
name of the ref given to us for update does not match the actual
ref we are about to change, we log to both the original ref name
given and the actual ref name.

This handles the case of HEAD being a symref to some actual branch;
we update the HEAD reflog and the actual branch reflog whenever
someone updates HEAD.  Which is what we are usually doing from
tools like git-checkout.

receive-pack isn't updating the HEAD reflog as its updating the
actual branch, not HEAD.  If you pushed instead to HEAD you should
see the HEAD reflog entry too.

Its a little ugly here as I'm not sure we should always update
HEAD's reflog if HEAD points at a branch we are actually updating.
Maybe we should though in receive-pack ?

-- 
Shawn.
-

What about splitting HEAD when you push to the underlying branch, and
making HEAD a non-symref?

Sam.
-

I do not think any of the complication is needed, and I think
somebody mentioned a good example, which is a firewalled host
that can only be pushed into.  In that example, even though he
knows he could fetch in reverse direction in the ideal world,
the network configuration does not let him do so, hence need for
a push.

To deal with that sanely, people who push between non bare
repositories can just forget about pushing into branch heads.

Instead, they can arrange their pushes to be a true mirror image
of their fetch that they wish could do.  To illustrate:

On repo A that can only be pushed into, if you _could_ fetch
from repo B, you would:

	$ git fetch B

with something like this:

	[remote "B"] fetch = refs/heads/*:refs/remotes/B/*

But unfortunately because you can only push into A from B, you would
run this on B instead:

	$ git push A

with:

	[remote "A"] push = refs/heads/*:refs/remotes/B/*

And after you perform your push, you come to the machine with
repo A on it, and remembering that what you did was a mirror
image of "git fetch B", you would:

	$ git merge remotes/B/master

and you are done.

In other words, don't think of refs/remotes/B as something that
is for the use of "git fetch".  Its purpose is to track the
remote repository B's heads.  You maintain that hierarchy by
issuing fetch in repository A.  You can issue push in repository
B to do so as well.

I push into a live repository almost every day.  My typical day
concludes like this:

	gitster$ git push kernel-org-private
        gitster$ ssh kernel.org
        kernel.org$ git merge origin
        kernel.org$ Meta/Doit -pedantic &
        kernel.org$ exit
        ... go drink my tea ...

where

 (1) gitster is my private development machine
 (2) kernel.org is a machine made available to me by friendly
     k.org folks
 (3) Meta is a checkout of my 'todo' branch and 
 (4) Doit is a script to build all four public branches.

I always leave 'master' checked out on my kernel.o...
[ message continues ]

-

This is indeed a corner case.  And it was never considered before as 
great care was made at the time to be sure pushes wouldn't create any 
reflogs on the remote side, which is effectively done by not 

If the meaning of HEAD changed (although indirectly) because HEAD 
happens to point to the branch that just got updated then logically the 
HEAD reflog should be updated too.  On the other hand the HEAD reflog 
should reflect operations performed on HEAD.  Since the push updates the 
branch directly it is not exactly performing some operation on HEAD 
since HEAD could point anywhere and that wouldn't change the push at 
all.

Meaning that for the discussion of pushing to a non-bare repository with 
a dirty working tree... If the branch being pushed into is not pointed 
to by HEAD then no consideration what so ever about the working tree 
should be made, and no update to the HEAD reflog made of course.


Nicolas
-

Right, but if the branch being pointed to is pointed to by HEAD I
would argue that the reflog for HEAD should be updated, since
operations that reference HEAD will see a new commit, and and it will
be confusing when "git reflog" shows no hint of the change.

Of couse, if the branch being pushed to isn't one which is pointed by
HEAD, of course HEAD's reflog shouldn't be updated.

						- Ted
-

I think we're saying the exact same thing.


Nicolas
-

If we were to do this properly, we probably would need to
restructure the reflog update code for the HEAD in a major way.
"git-update-ref refs/heads/foo $newvalue" when HEAD points at
branch 'foo' currently does not update HEAD reflog because the
current definition of HEAD reflog is (as Nico mentioned) log of
changes made through HEAD symref.  Instead, we would need a
reverse lookup every time any ref is updated to see if that ref
is pointed by any symbolics ref and update the reflogs of those
symbolic refs.  This is expensive to do in general, though,
because there is no backpointer to list of symbolic refs that
point at a non-symbolic ref.


-

But practically speaking... is there that many cases where a branch is 
updated directly instead of the operation performed through HEAD?

We identified one case which is a push to a non bare repo.

If those cases are very few (and they _should_ be very few) then we 
might simply cheat a little and update HEAD separately in those cases.


Nicolas
-

Actually, there are no such "design choices".  That's entirely
up to the repository owners to arrange post-update hook, to
allow you to do anything you want.  

The default is not to encourage people (who do not know what
they are doing anyway) to push into non-bare repository.

-

Maybe it's worth making it an error (that can be forced) if you're
pushing to the head that's checked out in a non-bare repository ?

It's pretty nasty behaviour for people used to darcs / bzr et al.

Sam.
-

We talked about that in the past on the list.  No.

-