On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
> On Thu, 15 Oct 2009, Daniel Barkalow wrote:
>
> >On Thu, 15 Oct 2009, James Pickens wrote:
> >
> >>How about not detaching the head at all if the user checks out any ref, and
> >>reject commits if he checked out a tag or remote branch. For example:
> >>
> >>$ git checkout origin/master
> >>$ git status
> >># On branch origin/master
> >>$ git commit ;# complain
> >
> >$ git checkout origin/master
> >$ git fetch
> >$ git checkout origin/next
> >Uncommited file '...' would be overwritten.
>
> How about:
>
> $ git checkout origin/master
> $ git fetch
> Refusing to fetch, as it would update a checkedout branch
> "git fetch -f" will force the update, but you will need to run "git
> reset --hard HEAD" to update your checkout to match.
That would redefine -f (currently means "allow non-fast-forward
updates"), the flag that allows the checked out branch head to be
updated is -u, --update-head-ok, and is for internal use only.
And suggesting "reset --hard" seems wrong, that just kills any
uncommitted changes.
And such uncommitted changes would be lost in the big "undo the fetch
update" diff. So you'd have to do:
git reset --soft HEAD@{1}
git checkout --merge HEAD@{1}
to keep them, while updating to the new state of the remote tracking
branch. Not quite intuitive, is it?
Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html