Pushing into a repository with working directory?

Pushing into a repository with working directory?

[Shawn O. Pearce]

So tonight on #git I think I answered for the 10th time why the
working directory doesn't update after a push to its associated
repository.

We all know its somewhat dangerous to push into the current branch
of a working directory, especially if that working directory contains
uncommitted changes, as HEAD no longer matches the index.

But we all also know its incredibly useful to be able to push into
a repository with a working directory, so we certainly don't want
to disallow it entirely.

What about refusing a push to the current branch (branch listed in
$GIT_DIR/HEAD) and the repository appears to have a working directory
(is_bare_git_dir is false)?

-- 
Shawn.

Re: Pushing into a repository with working directory?

[Andy Whitcroft]

Shawn O. Pearce wrote:
> So tonight on #git I think I answered for the 10th time why the
> working directory doesn't update after a push to its associated
> repository.
> 
> We all know its somewhat dangerous to push into the current branch
> of a working directory, especially if that working directory contains
> uncommitted changes, as HEAD no longer matches the index.
> 
> But we all also know its incredibly useful to be able to push into
> a repository with a working directory, so we certainly don't want
> to disallow it entirely.
> 
> What about refusing a push to the current branch (branch listed in
> $GIT_DIR/HEAD) and the repository appears to have a working directory
> (is_bare_git_dir is false)?

Special casing the 'current' branch makes any sort of automated push
setup unreliable.  Indeed the special case preventing a fetch into the
current branch is pretty annoying for the same reason.  I would almost
prefer to relax that than add the same for push.

-apw

Re: Pushing into a repository with working directory?

[Junio C Hamano]

Andy Whitcroft <apw@shadowen.org> writes:

> Special casing the 'current' branch makes any sort of automated push
> setup unreliable.  Indeed the special case preventing a fetch into the
> current branch is pretty annoying for the same reason.  I would almost
> prefer to relax that than add the same for push.

How would you relax the fetch case?  Fetching into the current
branch, unless the repository is bare, is always a fishy
operation.

Re: Pushing into a repository with working directory?

[Andy Whitcroft]

Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
> 
>> Special casing the 'current' branch makes any sort of automated push
>> setup unreliable.  Indeed the special case preventing a fetch into the
>> current branch is pretty annoying for the same reason.  I would almost
>> prefer to relax that than add the same for push.
> 
> How would you relax the fetch case?  Fetching into the current
> branch, unless the repository is bare, is always a fishy
> operation.

Is it fishy if the working directory and index match HEAD?  If not, then
we could detect that and allow update in that case?

Also, if we had dangling head support we could "leave" HEAD pointing to
the starting commit, and emit a nice fat warning.

-apw

Re: Pushing into a repository with working directory?

[Junio C Hamano]

Andy Whitcroft <apw@shadowen.org> writes:

> Is it fishy if the working directory and index match HEAD?  If not, then
> we could detect that and allow update in that case?

That actually is what 'git-pull' does when you misconfigure and
use your current branch as the tracking branch (which is the
only reason 'git-fetch' has the --update-head-ok option that
should never be used by the end user).

We really should disallow this.

Re: Pushing into a repository with working directory?

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
> 
> > Special casing the 'current' branch makes any sort of automated push
> > setup unreliable.  Indeed the special case preventing a fetch into the
> > current branch is pretty annoying for the same reason.  I would almost
> > prefer to relax that than add the same for push.
> 
> How would you relax the fetch case?  Fetching into the current
> branch, unless the repository is bare, is always a fishy
> operation.

And so is pushing into the current branch, so long as the current
branch has a working directory attached to it.

Most new users to Git expect to be able to push into the current
branch of a repository and `just have it work`.  Only they don't
really seem to have an idea of _how_ that operation should behave,
which means they really don't want it to work at all.  I certainly
don't want an operation to succeed if I can't reason about what
its success means!

Right now pushing into the current branch makes the index become
way out of sync from HEAD.  This causes git-runstatus to display a
large number of differences, basically undoing any of the changes
introduced by HEAD@{1}..HEAD.  The user is left with a dirty
working tree that they can commit - and committing it will just
revert the prior commits.  The user will later cuss at Git for
losing their changes.  Not pretty.

-- 
Shawn.

Re: Pushing into a repository with working directory?

[Andy Whitcroft]

Shawn O. Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> Andy Whitcroft <apw@shadowen.org> writes:
>>
>>> Special casing the 'current' branch makes any sort of automated push
>>> setup unreliable.  Indeed the special case preventing a fetch into the
>>> current branch is pretty annoying for the same reason.  I would almost
>>> prefer to relax that than add the same for push.
>> How would you relax the fetch case?  Fetching into the current
>> branch, unless the repository is bare, is always a fishy
>> operation.
> 
> And so is pushing into the current branch, so long as the current
> branch has a working directory attached to it.
> 
> Most new users to Git expect to be able to push into the current
> branch of a repository and `just have it work`.  Only they don't
> really seem to have an idea of _how_ that operation should behave,
> which means they really don't want it to work at all.  I certainly
> don't want an operation to succeed if I can't reason about what
> its success means!
> 
> Right now pushing into the current branch makes the index become
> way out of sync from HEAD.  This causes git-runstatus to display a
> large number of differences, basically undoing any of the changes
> introduced by HEAD@{1}..HEAD.  The user is left with a dirty
> working tree that they can commit - and committing it will just
> revert the prior commits.  The user will later cuss at Git for
> losing their changes.  Not pretty.

Ok, both seem to be bad.  Can I re-ask if this would be solved by having
the 'dangling head' support we talked about.  Such that pulling into or
pushing into the current head could break the link and make the current
head a dangling head?  In my mind thats very similar to creating a
temporary branch for the user before updating the head they were on, but
without having to actually make one.

-apw

Re: Pushing into a repository with working directory?

[Junio C Hamano]

Andy Whitcroft <apw@shadowen.org> writes:

>> Right now pushing into the current branch makes the index become
>> way out of sync from HEAD.  This causes git-runstatus to display a
>> large number of differences, basically undoing any of the changes
>> introduced by HEAD@{1}..HEAD.  The user is left with a dirty
>> working tree that they can commit - and committing it will just
>> revert the prior commits.  The user will later cuss at Git for
>> losing their changes.  Not pretty.
>
> Ok, both seem to be bad.  Can I re-ask if this would be solved by having
> the 'dangling head' support we talked about.  Such that pulling into or
> pushing into the current head could break the link and make the current
> head a dangling head?

Push does not do any working tree operation, so you _could_
detach the HEAD to point at the commit that used to be at the
tip of the branch and advance the tip of the branch as the push
instructs.  The user could start a new branch out of the
detached HEAD (which is behind the tip of the original branch),
make necessary commits and then merge that branch locally to the
branch the push advanced if s/he wants to.

However, I am not sure if that is easy to understand for the
users.  It would be sane to deny pushing into the current branch
for a non-bare repositories by default, and if we do allow it
(perhaps with 'git-push --force'), then detach the HEAD as you
suggest.  On the other hand, pushing into the current branch of
a bare repository should just work; the HEAD pointer in a bare
repository is not about the commit the index and the working
tree are based on, but which branch is the primary branch of the
repository.

I haven't thought things through, but I think the fetch side
could be handled in a similar way.

Re: Pushing into a repository with working directory?

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> However, I am not sure if that is easy to understand for the
> users.  It would be sane to deny pushing into the current branch
> for a non-bare repositories by default, and if we do allow it
> (perhaps with 'git-push --force'), then detach the HEAD as you
> suggest.  On the other hand, pushing into the current branch of
> a bare repository should just work; the HEAD pointer in a bare
> repository is not about the commit the index and the working
> tree are based on, but which branch is the primary branch of the
> repository.

But from the working directory management tools' perspective HEAD
*is* about the current index and the current working directory.
If HEAD doesn't match the index and working directory closely
enough then the user is going to do something stupid, like commit
a negative delta by accident.

Pushing into the current branch of a repository with a working
directory probably shouldn't be allowed by default as users probably
don't want to do that.  But if --force is used then detaching the
HEAD is probably the best idea.  The user could easily recover by
doing `git checkout origbranch` (though they may need `git checkout
-m origbranch` if their working directory was dirty).

-- 
Shawn.

Re: Pushing into a repository with working directory?

[Andreas Ericsson]

Shawn O. Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> However, I am not sure if that is easy to understand for the
>> users.  It would be sane to deny pushing into the current branch
>> for a non-bare repositories by default, and if we do allow it
>> (perhaps with 'git-push --force'), then detach the HEAD as you
>> suggest.  On the other hand, pushing into the current branch of
>> a bare repository should just work; the HEAD pointer in a bare
>> repository is not about the commit the index and the working
>> tree are based on, but which branch is the primary branch of the
>> repository.
> 
> But from the working directory management tools' perspective HEAD
> *is* about the current index and the current working directory.
> If HEAD doesn't match the index and working directory closely
> enough then the user is going to do something stupid, like commit
> a negative delta by accident.
> 
> Pushing into the current branch of a repository with a working
> directory probably shouldn't be allowed by default as users probably
> don't want to do that.


I do this all the time. I develop on my laptop and send changes to a 
testserver where I check out the revision I just pushed to the working 
directory attached to it. Doing it the other way around is cumbersome, 
as I've got ssh-authentication installed on the server but don't wish to 
have that on my laptop. I could ofcourse do this with the alternates 
mechanism and pull things from the alternate repo to the one I really 
use, but that seems like I have to work around a limitation in git that 
isn't really there (or at least shouldn't be there for any logical or 
technical reason).

>  But if --force is used then detaching the
> HEAD is probably the best idea.  The user could easily recover by
> doing `git checkout origbranch` (though they may need `git checkout
> -m origbranch` if their working directory was dirty).
> 

Since we can determine if there's a working directory or not, why not 
just allow the fast-forward case if the working directory is clean and 
update the working directory for the user? This can't lose any data and 
would also make it very easy to, fe, keep a website in git and just push 
it straight to the webserver  when there's been modifications in the 
users repo. --force should behave the same way, possibly with an extra 
check to see if the working directory is clean before checking it out.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Pushing into a repository with working directory?

[Johannes Schindelin]

Hi,

On Tue, 9 Jan 2007, Andreas Ericsson wrote:

> Shawn O. Pearce wrote:
> > 
> > Pushing into the current branch of a repository with a working 
> > directory probably shouldn't be allowed by default as users probably 
> > don't want to do that.
> 
> 
> I do this all the time. I develop on my laptop and send changes to a 
> testserver where I check out the revision I just pushed to the working 
> directory attached to it.

This is still possible. I also do it all the time. Only I do not update 
the _current_ branch, but a throwaway one.

> Since we can determine if there's a working directory or not, why not 
> just allow the fast-forward case if the working directory is clean and 
> update the working directory for the user?

Because maybe that user could be working on them right now?

The behaviour is safe as is.

Ciao,
Dscho