All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Andy Whitcroft <apw@shadowen.org>, git@vger.kernel.org
Subject: Re: Pushing into a repository with working directory?
Date: Fri, 5 Jan 2007 14:36:46 -0500	[thread overview]
Message-ID: <20070105193646.GC8753@spearce.org> (raw)
In-Reply-To: <7vwt41j1le.fsf@assigned-by-dhcp.cox.net>

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.

  parent reply	other threads:[~2007-01-05 19:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-02  4:51 Pushing into a repository with working directory? Shawn O. Pearce
2007-01-05  8:51 ` Andy Whitcroft
2007-01-05  8:54   ` Junio C Hamano
2007-01-05  9:32     ` Andy Whitcroft
2007-01-05  9:50       ` Junio C Hamano
2007-01-05 19:36     ` Shawn O. Pearce [this message]
2007-01-08 13:53       ` Andy Whitcroft
2007-01-09  0:57         ` Junio C Hamano
2007-01-09  3:32           ` Shawn O. Pearce
2007-01-09  9:15             ` Andreas Ericsson
2007-01-09 13:51               ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070105193646.GC8753@spearce.org \
    --to=spearce@spearce.org \
    --cc=apw@shadowen.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.