Problem with git push over <hostname>:/path protocol (ssh)

Problem with git push over <hostname>:/path protocol (ssh)

[Bill Lear]

We are seeing very strange behavior with git (1.4.4.1, and 1.5.0-rc2)
that results in a push to a remote repo leaving modified files in
the remote repo.  Here is the gist (slightly edited for clarity):

On machine1:

% mkdir git_it
% git init-db
% echo lksjdflksdf > foo
% git add foo
% git commit -a -m foo
% git status
[nothing, all clear]

On machine2:

% git clone machine1:/path/to/git_it
Initialized empty Git repository in /home/blear/tst/git_it/.git/
remote: Generating pack...
remote: Done counting 3 objects.
remote: Deltifying 3 objects.
remote:  100% (3/3) done
remote: Total 3, written 3 (delta 0), reused 0 (delta 0)
Indexing 3 objects.
 100% (3/3) done
% cd git_it
% git co -b new_branch
% echo -e "\nbar fig dongle\n" >> foo
% git commit -a -m foo
Created commit 082d40b1906eecc8a26f6e6e5500c476a8e4311f
 1 files changed, 3 insertions(+), 0 deletions(-)
% git co master
% git pull . new_branch
Updating f404614..082d40b
Fast forward
 foo |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
% git push
updating 'refs/heads/master'
  from f4046144d031a779c7127b01ce6241fd66eb9f54
  to   082d40b1906eecc8a26f6e6e5500c476a8e4311f
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 0), reused 0 (delta 0)
Unpacking 3 objects
refs/heads/master: f4046144d031a779c7127b01ce6241fd66eb9f54 -> 082d40b1906eecc8a26f6e6e5500c476a8e4311f

On machine1:

% cd git_it
% git status
# Updated but not checked in:
#   (will commit)
#
#       modified:   foo
#
% cat foo
foo
% git diff --cached
diff --git a/foo b/foo
index 5b9d7b1..0155b25 100644
--- a/foo
+++ b/foo
@@ -1,4 +1 @@
 lksjdflksdf
-
-bar fig dongle
-

So, if the developer then commits on his branch on machine 1, all his
changes get undone.  This has happened to him consistently --- he is
running git 1.4.4.1 throughout.  I just reproduced it using the above,
and I am using 1.5.0-rc2 on machine 2, and 1.4.4.1 on machine 1.


Bill

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Daniel Barkalow]

On Wed, 24 Jan 2007, Bill Lear wrote:

> We are seeing very strange behavior with git (1.4.4.1, and 1.5.0-rc2)
> that results in a push to a remote repo leaving modified files in
> the remote repo.  Here is the gist (slightly edited for clarity):
> 
> On machine1:
> 
> % mkdir git_it
> % git init-db
> % echo lksjdflksdf > foo
> % git add foo
> % git commit -a -m foo
> % git status
> [nothing, all clear]
> 
> On machine2:
> 
> % git clone machine1:/path/to/git_it
> Initialized empty Git repository in /home/blear/tst/git_it/.git/
> remote: Generating pack...
> remote: Done counting 3 objects.
> remote: Deltifying 3 objects.
> remote:  100% (3/3) done
> remote: Total 3, written 3 (delta 0), reused 0 (delta 0)
> Indexing 3 objects.
>  100% (3/3) done
> % cd git_it
> % git co -b new_branch
> % echo -e "\nbar fig dongle\n" >> foo
> % git commit -a -m foo
> Created commit 082d40b1906eecc8a26f6e6e5500c476a8e4311f
>  1 files changed, 3 insertions(+), 0 deletions(-)
> % git co master
> % git pull . new_branch
> Updating f404614..082d40b
> Fast forward
>  foo |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> % git push
> updating 'refs/heads/master'
>   from f4046144d031a779c7127b01ce6241fd66eb9f54
>   to   082d40b1906eecc8a26f6e6e5500c476a8e4311f
> 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 0), reused 0 (delta 0)
> Unpacking 3 objects
> refs/heads/master: f4046144d031a779c7127b01ce6241fd66eb9f54 -> 082d40b1906eecc8a26f6e6e5500c476a8e4311f
> 
> On machine1:
> 
> % cd git_it
> % git status
> # Updated but not checked in:
> #   (will commit)
> #
> #       modified:   foo
> #
> % cat foo
> foo
> % git diff --cached
> diff --git a/foo b/foo
> index 5b9d7b1..0155b25 100644
> --- a/foo
> +++ b/foo
> @@ -1,4 +1 @@
>  lksjdflksdf
> -
> -bar fig dongle
> -
> 
> So, if the developer then commits on his branch on machine 1, all his
> changes get undone.  This has happened to him consistently --- he is
> running git 1.4.4.1 throughout.  I just reproduced it using the above,
> and I am using 1.5.0-rc2 on machine 2, and 1.4.4.1 on machine 1.

Git gets unhappy if you push into a branch that's checked out. It doesn't 
update the index or working directory, so the state after the push looks 
like the user reverted the patch in the working directory and updated the 
index.

It should probably give an error message and stop the push; dealing with a 
checked out version conceptually requires a merge, which push doesn't do. 
Most likely, you want a clone of the upstream repository, and a 
post-update hook in the upstream repository that goes into the clone and 
pulls the changes. (And possibly does more stuff after that)

	-Daniel
*This .sig left intentionally blank*

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Bill Lear]

On Wednesday, January 24, 2007 at 15:04:54 (-0500) Daniel Barkalow writes:
>...
>Git gets unhappy if you push into a branch that's checked out. It doesn't 
>update the index or working directory, so the state after the push looks 
>like the user reverted the patch in the working directory and updated the 
>index.
>
>It should probably give an error message and stop the push; dealing with a 
>checked out version conceptually requires a merge, which push doesn't do. 
>Most likely, you want a clone of the upstream repository, and a 
>post-update hook in the upstream repository that goes into the clone and 
>pulls the changes. (And possibly does more stuff after that)

Wow, this is a pain.

We actually would prefer that our public (collaborative) repositories
be bare, but we could not find a way to pull into them without
getting all the files checked out into the working tree.

Is there a way to do a pull and leave a repo bare, perchance?


Bill

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Jakub Narebski]

Bill Lear wrote:

> Is there a way to do a pull and leave a repo bare, perchance?

fetch
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Bill Lear]

On Wednesday, January 24, 2007 at 21:44:24 (+0100) Jakub Narebski writes:
>Bill Lear wrote:
>
>> Is there a way to do a pull and leave a repo bare, perchance?
>
>fetch

No way, you mean I'm really that dumb!?  Geez, sometimes it doesn't
pay to stay up until 6am coding...

Thanks for what should have been obvious.


Bill

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Jakub Narebski]

Daniel Barkalow wrote:

>> So, if the developer then commits on his branch on machine 1, all his
>> changes get undone.  This has happened to him consistently --- he is
>> running git 1.4.4.1 throughout.  I just reproduced it using the above,
>> and I am using 1.5.0-rc2 on machine 2, and 1.4.4.1 on machine 1.
> 
> Git gets unhappy if you push into a branch that's checked out. It doesn't 
> update the index or working directory, so the state after the push looks 
> like the user reverted the patch in the working directory and updated the 
> index.

So you usually push into _bare_ repository, or use fetch / pull instead.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Problem with git push over <hostname>:/path protocol (ssh)

[Bill Lear]

On Wednesday, January 24, 2007 at 21:35:36 (+0100) Jakub Narebski writes:
>Daniel Barkalow wrote:
>
>>> So, if the developer then commits on his branch on machine 1, all his
>>> changes get undone.  This has happened to him consistently --- he is
>>> running git 1.4.4.1 throughout.  I just reproduced it using the above,
>>> and I am using 1.5.0-rc2 on machine 2, and 1.4.4.1 on machine 1.
>> 
>> Git gets unhappy if you push into a branch that's checked out. It doesn't 
>> update the index or working directory, so the state after the push looks 
>> like the user reverted the patch in the working directory and updated the 
>> index.
>
>So you usually push into _bare_ repository, or use fetch / pull instead.

Well, what we want to do is have a public repo as a collaborative hub.
We would prefer this be bare.  However, there are problems with that,
at least with how we are doing things.

For example, if I collaborate with a peer and make a few changes,
I want to push my changes to my public repo and have an email sent
to him, and any other interested persons, when the update hook runs.

However, if I keep my private repo up-to-date with our company repo by
doing periodic pulls into it, and then push into my public repo, ALL
of the changes get noticed on the public repo side, and he gets a
flood of mail.  This also happens if I pull from my peer's repo into
my private repo, make changes, and then push to my public repo --- all
of his changes then get sent out to him again, and mine get mixed in
with his.

So, we resorted to using a non-bare public repo into which we could
pull, to avoid this mess, and it appears, actually, that we have
created a worse one.


Bill