git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sam Vilain <sam@vilain.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Matthias Lederhofer <matled@gmx.net>
Subject: Re: post-update script to update wc - suggestions welcome
Date: Thu, 21 Jun 2007 10:28:33 +1200	[thread overview]
Message-ID: <4679AA11.5050407@vilain.net> (raw)
In-Reply-To: <7vtzt2s5jl.fsf@assigned-by-dhcp.pobox.com>

Junio C Hamano wrote:
> I am afraid I am not following your logic.
> 
> I missed that "if git-diff-files"; it is not checking (you would
> have to ask for --exit-code or something --- traditionally we
> never used git-diff-xxxx exit code to indicate if there is any
> changes).

Oh, I expected a diff command to return an error code if differences
were found, like diff does.

> Suppose we update that "if" to see if diff-files says "no change
> in the working tree wrt the index".  But then, I think what you
> have at the end, "git reset --hard HEAD", where the HEAD is an
> arbitrary commit that does not necessarily have to do anything
> with what the index is based on, would remove what is known to
> the index but not in HEAD.

Good point.  Yes a semi-staged commit would lose information.  So we
also need to check that the index matches the previous value of what the
current branch points to.

How about this.  We call write-tree and get a tree ID.  If we can find
that tree in any of the commits reachable by the reflog or the history
of the current branch then we can be happy that no local changes have
been staged.  That will imply that if you want a non-bare repository to
update automatically and use push -f, you need reflog.

>  Which was my point about the
> "diff-index piped to perl".  I do not think that one is
> necessary.

Sure, I only did that because I didn't think reset --hard would remove
files which were previously in the index but not in the version being
reset to.

> Actually, more importantly, why is it justified to remove a file
> that is unchanged since the index, if the updated HEAD does not
> have it?  That is losing information, isn't it?

Well, not if you can confirm that the index matches some previous
version of the branch.

> Or are you assuming that this is used only for a worktree where
> there is NO actual development happens, but just kept up to date
> to whatever commit comes at HEAD?

I was aiming for something safe that people can just chmod +x to get
symmetric push/pull semantics.

Sam.

      reply	other threads:[~2007-06-20 22:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-20  6:21 post-update script to update wc - suggestions welcome Sam Vilain
2007-06-20  7:03 ` Sam Vilain
2007-06-20  8:52 ` Junio C Hamano
2007-06-20 20:14   ` Sam Vilain
2007-06-20 21:02     ` Junio C Hamano
2007-06-20 22:28       ` Sam Vilain [this message]

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=4679AA11.5050407@vilain.net \
    --to=sam@vilain.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=matled@gmx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).