Re: post-update script to update wc - suggestions welcome

Sam Vilain [off-list ref] writes:

quoted

quoted

  cd ..
  success=
  if git-diff-files
  then
    

...

quoted

    git-reset --hard HEAD && success=1
  fi
    

Wouldn't "reset --hard HEAD" pretty much unconditionally nuke
your local changes, including added files to the index?  For
example, if I do this:

	$ >foo && git add foo && git reset --hard HEAD

it would remove the newly added 'foo' from both the index and
the working tree.  So I am not quite sure what you are trying to
achieve with "diff-index | perl" magic.

Right, but we've already checked using diff-files that there weren't any
local changes. So all we're saying is "remove all files which won't be
written by git reset --hard, then checkout new versions of files".

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

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.  Which was my point about the
"diff-index piped to perl".  I do not think that one is
necessary.

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?

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?

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.