RE: cache status after git pull

RE: cache status after git pull

[Luck, Tony]

>To set up "linus" short-hand to be updated with "master" branch
>head from Linus, you would do one of the following:
>
>  * Using new style shorthand
>
>    $ cat >$GIT_DIR/remotes/linus \
>    URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>    Pull: master:linus
>    $ git fetch linus

This sounds like it does what I want ... so I'd like to confirm
before wiring this into my scripts and fingers.

What I want is to get the latest from kernel.org...linus...master
and update my .refs/heads/linus with the new SHA1.

I'd like to be able to do that without touching what is in my
index, and without changing the state of any checked out files.

If that is what the above does, then you are my hero for today :-)

-Tony

[PATCH] Fix pulling into the same branch.

[Junio C Hamano]

Earlier, I said:

    Subject: Re: cache status after git pull
    Date: Thu, 25 Aug 2005 13:26:07 -0700
    Message-ID: <7v4q9dvk4g.fsf@assigned-by-dhcp.cox.net>

    > 1) Updated my "linus" branch:
    >
    >   $ git checkout linus && git pull linus

    The second command, "git pull linus", would internally run "git
    fetch linus".  It depends on how your shorthand "linus" is
    defined, but if it is set to update (either overwrite or
    fast-forward) the "linus" branch head, then your HEAD pointer
    would be updated without updating the index and working tree.
    This is bad because now you are telling git that your working
    tree is based on updated "linus" branch head, and what you
    _could_ commit on top of it is the same thing as what old
    "linus" branch head commit used to have.  That's why "git
    status" output shows the minefield.

    If I keep copies of foreign brahches in $GIT_DIR/refs/heads/
    somewhere, I never checkout those branches in my working tree.
    I always stay in my branches to do my work.  I may "diff"
    against them to see where I am.  Of course I would "resolve"
    with them when I feel I am ready.

    So, assuming that "linus" short-hand is set up to update
    $GIT_DIR/refs/heads/linus with the foreign branch head, the
    above example would have been:

        $ git checkout master && git pull linus
        : examine diffs and be convinced what Linus does is always right.

This "do not pull into the branch you are on" is probably a good
advice as a workaround, but there is no fundamental reason to
forbid it.  Worse, there is no machinery to even warn about the
situation right now.

This patch is to show my current thinking.  Please let me know
what you think.

-jc

------------
When the "git pull" command updates the branch head you are
currently on, before doing anything else, first update your
index file and the working tree contents to that of the new
branch head.  Otherwise, the later resolving steps would think
your index file is attempting to revert the change between the
original head commit and the updated head commit.

It uses two-tree fast-forward form of "read-tree -m -u" to
prevent losing whatever local changes you may have in the
working tree to do this update.  I think this would at least
make things safer (a lot safer), and prevent mistakes.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-pull-script |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

10f624a7743fc1e29277de9875dbd6a882f2d3b3
diff --git a/git-pull-script b/git-pull-script
--- a/git-pull-script
+++ b/git-pull-script
@@ -5,7 +5,25 @@
 # Fetch one or more remote refs and merge it/them into the current HEAD.
 
 . git-sh-setup-script || die "Not a git archive"
+
+orig_head=$(cat "$GIT_DIR/HEAD") || die "Pulling into a black hole?"
 git-fetch-script "$@" || exit 1
+
+curr_head=$(cat "$GIT_DIR/HEAD")
+if test "$curr_head" != "$orig_head"
+then
+	# The fetch involved updating the current branch.
+
+	# The working tree and the index file is still based on the
+	# $orig_head commit, but we are merging into $curr_head.
+	# First update the working tree to match $curr_head.
+
+	echo >&2 "Warning: fetch updated the current branch head."
+	echo >&2 "Warning: fast forwarding your working tree."
+	git-read-tree -u -m "$orig_head" "$curr_head" ||
+		die "You need to first update your working tree."
+fi
+
 merge_head=$(sed -e 's/	.*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ')
 merge_name=$(sed -e 's/^[0-9a-f]*	//' "$GIT_DIR"/FETCH_HEAD |
 	 tr '\012' ' ')

Re: cache status after git pull

[Junio C Hamano]

"Luck, Tony" <tony.luck@intel.com> writes:

> What I want is to get the latest from kernel.org...linus...master
> and update my .refs/heads/linus with the new SHA1.
>
> I'd like to be able to do that without touching what is in my
> index, and without changing the state of any checked out files.
>
> If that is what the above does,...

At least that is how "git fetch <repo> <src>:<dst>" is designed
to work, and "Pull: <src>:<dst>" in a remotes/ shorthand is
designed to reduce typing while doing so.  Please bug me if
things do not work as advertised.

Re: [PATCH] Fix pulling into the same branch.

[Johannes Schindelin]

Hi,

On Thu, 25 Aug 2005, Junio C Hamano wrote:

> This patch is to show my current thinking.  Please let me know
> what you think.

I like it. As Linus stated, the index originally had a different role from 
what it has now, so it really should be an internal git thing, i.e. the 
git user should not expect the index not to change when pulling.

Ciao,
Dscho

Re: [PATCH] Fix pulling into the same branch.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I like it. As Linus stated, the index originally had a different role from 
> what it has now, so it really should be an internal git thing, i.e. the 
> git user should not expect the index not to change when pulling.

Actually the issue and the way patch addresses it is not limited
to the index file.  The problem is that the relashionship
between your working tree and the $GIT_DIR/HEAD commit changes
unexpectedly (from the POV of the working tree) when the ref
being updated by the "push in reverse" machinery happens to be
the head of the branch you are currently on.  The working tree
is supposed to be based on $GIT_DIR/HEAD, but after the "push in
reverse".  This fix is about fast forwarding the working tree,
including the checked out files on the filesystem, to the
updated head when it happens.

I am tempted to move this logic to "git fetch" instead, because
it has the same issue.  Tony's "linus" branch example has been
updated to do a "git fetch" instead of "git pull" from the
earlier description in his howto, but if he happens to be on the
"linus" branch, he would still have this same problem.

Of course, doing this in "git fetch" needs to be done a bit more
carefully than in "git pull", because by definition "pull" is a
fetch followed by merging into the working tree, implying that
the repository has an associated working tree.  But "fetch" by
itself can be used for a naked repository [*1*], and we should
not unconditionally attempt to update the working tree that may
not exist.

I am planning to use the lack of index file for this detection,
but I've seen some people made an rsync copy of their private
repository as a whole to publish, so this heuristic may
probabaly break.  Maybe the lack of "$GIT_DIR/index" and
$GIT_DIR not ending with "/.git" and not being ".git"?  I am
undecided.

In the meantime, warning the user about the issue and suggesting
how to do the fast-forwarding of the working tree himself in the
warning message might be the safest and the most sensible thing
to do.


[Footnote]

*1* Do we want a term in the glossary to mean repositories like
linux-2.6.git and git.git that do not have associated working
trees?

RE: [PATCH] Fix pulling into the same branch.

[Luck, Tony]

>I am tempted to move this logic to "git fetch" instead, because
>it has the same issue.  Tony's "linus" branch example has been
>updated to do a "git fetch" instead of "git pull" from the
>earlier description in his howto, but if he happens to be on the
>"linus" branch, he would still have this same problem.

I don't spend much time on the linus branch (just to build an
updated cscope database, etc.).  I never want to check anything
in on that branch [sometime I should figure out how use the "hooks"
to keep me from shooting myself in the foot here].

>In the meantime, warning the user about the issue and suggesting
>how to do the fast-forwarding of the working tree himself in the
>warning message might be the safest and the most sensible thing
>to do.

Yes please ... a big fat warning with coloured flashing lights
and explosions from the sound card.

-Tony

Re: [PATCH] Fix pulling into the same branch.

[Junio C Hamano]

"Luck, Tony" <tony.luck@intel.com> writes:

>>In the meantime, warning the user about the issue and suggesting
>>how to do the fast-forwarding of the working tree himself in the
>>warning message might be the safest and the most sensible thing
>>to do.
>
> Yes please ... a big fat warning with coloured flashing lights
> and explosions from the sound card.

Yeah, but what to do afterwards?  I can see this as an
compromise:

 * "git fetch", just like the updated "git pull", reads
   $GIT_DIR/HEAD before it starts its work, and compares it with
   $GIT_DIR/HEAD after it is done.  If the --update-head-ok flag
   is not given on the command line, and if the HEAD changed,
   then barf and exit with non-zero status after reverting
   $GIT_DIR/HEAD to its original value.  If --update-head-ok is
   given, none of the above check and revert happens.

 * "git pull" calls "git fetch" with the extra flag, and does
   its thing the current way.

So if you are calling from the command line, "git fetch linus",
when you were still on "linus" branch (which you do not normally
do but just to prevent mistakes), it would trigger the check and
your $GIT_DIR/HEAD would stay intact.  If you stayed on your own
branch, "git fetch linus" would continue to just fast forward
"linus" head without touching the working tree.

Come to think of it, it may be cleaner to simply forbid
fast-forward fetching into the current repository (whether it is
"git fetch" or "git pull").  At least in your workflow you do
not do that ever anyway.

Johannes, what do you think, as the original advocate of "push in
reverse"?

Re: [PATCH] Fix pulling into the same branch.

[Johannes Schindelin]

Hi,

On Fri, 26 Aug 2005, Junio C Hamano wrote:

> Come to think of it, it may be cleaner to simply forbid
> fast-forward fetching into the current repository (whether it is
> "git fetch" or "git pull").  At least in your workflow you do
> not do that ever anyway.
> 
> Johannes, what do you think, as the original advocate of "push in
> reverse"?

I'm fine with it.

Although it might make more sense to check for dirty state, and 
fast-forward only for a clean state (together with a checkout of the new 
HEAD).

Ciao,
Dscho

Re: [PATCH] Fix pulling into the same branch.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 26 Aug 2005, Junio C Hamano wrote:
>
>> Johannes, what do you think, as the original advocate of "push in
>> reverse"?
>
> I'm fine with it.

Wow, blast from the past ;-).

> Although it might make more sense to check for dirty state, and 
> fast-forward only for a clean state (together with a checkout of the new 
> HEAD).

Yes, but the issue becomes how we can reliably tell if a
repository is naked or has an associated working tree.  I've
seen people rsync only .git subdirectory of their live working
tree to publish to a public repository, which means their pulic
repository has <project>.git/index file, so it is kind of
tricky.

Re: [PATCH] Fix pulling into the same branch.

[Linus Torvalds]

On Sun, 11 Sep 2005, Junio C Hamano wrote:
> 
> Yes, but the issue becomes how we can reliably tell if a
> repository is naked or has an associated working tree.

You can't "git pull" into a naked thing anyway. And

	git-read-tree -m -u <old-head> <new-head>

should always do the right thing (ie if there is dirty state that would be
updated, it will fail gracefully).

Or did I miss something?

		Linus

Re: [PATCH] Fix pulling into the same branch.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 11 Sep 2005, Junio C Hamano wrote:
>> 
>> Yes, but the issue becomes how we can reliably tell if a
>> repository is naked or has an associated working tree.
>
> You can't "git pull" into a naked thing anyway. And
>
> 	git-read-tree -m -u <old-head> <new-head>
>
> should always do the right thing (ie if there is dirty state that would be
> updated, it will fail gracefully).
>
> Or did I miss something?

No, I just stated my view poorly.

You cannot do pull into a naked one, but you can still fetch
into it.  My comment Johannes was responding to was what to do
when you do 'git fetch' into the repository associated with your
working tree and your branch is fast forwarded.  We obviously
want to prevent it from happening.  However, it is OK to do so
if the fetch is happening into a naked one and I was wondering
if there is a reliable way to tell that situation and allowing
that.

Re: [PATCH] Fix pulling into the same branch.

[Johannes Schindelin]

Hi,

On Sun, 11 Sep 2005, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 26 Aug 2005, Junio C Hamano wrote:
> >
> >> Johannes, what do you think, as the original advocate of "push in
> >> reverse"?
> >
> > I'm fine with it.
> 
> Wow, blast from the past ;-).

Sorry, I tried to relax for two weeks. That didn't work, though (pun 
intended).

> > Although it might make more sense to check for dirty state, and 
> > fast-forward only for a clean state (together with a checkout of the new 
> > HEAD).
> 
> Yes, but the issue becomes how we can reliably tell if a
> repository is naked or has an associated working tree.  I've
> seen people rsync only .git subdirectory of their live working
> tree to publish to a public repository, which means their pulic
> repository has <project>.git/index file, so it is kind of
> tricky.

I think it is easy to discern the two states "up to date checkout" and 
"dirty checkout or no checkout at all". But then, you're right: git fetch 
should not touch the working copy.

Ciao,
Dscho