Pushing into a repository with working directory?

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 O. Pearce wrote:

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

Andy Whitcroft <apw@shadowen.org> writes:

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

Junio C Hamano wrote:

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

Andy Whitcroft <apw@shadowen.org> writes:

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.

Junio C Hamano <junkio@cox.net> wrote:

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 O. Pearce wrote:

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

Andy Whitcroft <apw@shadowen.org> writes:

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.

Junio C Hamano <junkio@cox.net> wrote:

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 O. Pearce wrote:

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).

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.

Hi,

On Tue, 9 Jan 2007, Andreas Ericsson wrote:

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

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

The behaviour is safe as is.

Ciao, Dscho