Request re git status

Request re git status

[Ron Pero]

Hi

I almost got bit by git: I knew there were changes on the remote
server, but git status said I was uptodate with the remote.

This page explains it well.

http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream

That page also contains a good suggestion:

Why ... not design it to [optionally] DO a fetch and THEN declare
whether it is up to date? Or change the message to tell what it really
did, e.g. "Your branch was up-to-date with 'origin/master' when last
checked at {timestamp}"? Or even just say, "Do a fetch to find out
whether your branch is up to date"?

Thanks, and best wishes,

Ron

Re: Request re git status

[Phil Hord]

On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
> I almost got bit by git: I knew there were changes on the remote
> server, but git status said I was uptodate with the remote.
>

Do you mean you almost pushed some changed history with "--force"
which would have lost others' changes?  Use of this option is
discouraged on shared branches for this very reason.  But if you do
use it, the remote will tell you the hash of the old branch so you can
undo the damage.

But if you did not use --force, then you were not in danger of being
bit.  Git would have prevented the push in that case.


> Why ... not design it to [optionally] DO a fetch and THEN declare
> whether it is up to date?

It's because `git status` does not talk to the remote server, by
design.  The only Git commands that do talk to the remote are push,
pull and fetch.  All the rest work off-line and they do so
consistently.

Imagine `git status` did what you requested; that is, it first did a
fetch and then reported the status.  Suppose someone pushed a commit
to the remote immediately after your fetch completed.  Now git will
still report "up to date" but it will be wrong as soon as the remote
finishes adding the new push.  Yet the "up to date" message will
remain on your console, lying to you.  If you leave and come back in
two days, the message will remain there even if it is no longer
correct.

So you should accept that `git status` tells you the status with
respect to your most recent fetch, and that you are responsible for
the timing of the most recent fetch.  To have git try to do otherwise
would be misleading.

> Or change the message to tell what it really
> did, e.g. "Your branch was up-to-date with 'origin/master' when last
> checked at {timestamp}"? Or even just say, "Do a fetch to find out
> whether your branch is up to date"?

These are reasonable suggestions, but i don't think the extra wording
adds anything for most users.  Adding a timestamp seems generally
useful, but it could get us into other trouble since we have to depend
on outside sources for timestamps.  :-\

Re: Request re git status

[Cornelius Weig]

On 02/07/2017 01:45 AM, Phil Hord wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes?  Use of this option is
> discouraged on shared branches for this very reason.  But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
> 
> But if you did not use --force, then you were not in danger of being
> bit.  Git would have prevented the push in that case.

I totally agree with Phil. Besides, git-status should be fast. And
talking to a remote can be painfully slow. As Phil pointed out, even the
slow answer when talking to the remote can give you better guarantees
than the quick (local) answer. Therefore, I prefer the quick answer.

Since you pointed out the use of --force, I want to add the
--force-with-lease option of git-push. The idea is basically, that we
may force-push, if the remote end does indeed have the state we think it
has. This avoids those situations where somebody pushed to the remote
while you were typing 'git push --force' (which would then loose the
other contributor's work). For details have a look at 'git help push'.

>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
> 
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users.  Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps.  

The date of the last update is actually stored in the reflogs for the
remote branches. That timestamp is "internal" and could be trusted.
However, I don't quite believe that it would avoid accidents. For that
you would have to remember the time when some other (!) contributor has
pushed to the remote AND recognize that its timestamp is after the date
printed.
I prefer being warned by git when I try to do something stupid.

Re: Request re git status

[Ron Pero]

Hi Phil

Thanks very much for your reply.

I do understand why git status should not automatically fetch from the
server. The solution is that I become aware of that nuance (yes, I am
fairly new to git) and conduct myself that way.

Still, one way or another, it was easy to feel tripped up by that and
some kind of verbal cue could help.
I wonder if this kind of message would help: Latest fetch: {timestamp}

BTW, you might consider posting your answer on
http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream

Why? Because someone suggested emailing this suggestion to git@vger.kernel.org.

From the stackoverflow page:
"It would certainly be possible to add that extra text (behind a
config option so that redundant noise isn't shown if you how Git
works) but asking for it here isn't going to change it, try emailing
git@vger.kernel.org"

In answer to a couple of your points, I was not using force. And I do
understand that if I pushed to origin master it would have stopped the
merge, alerting me to the conflict. Thanks for that.

Thanks again,

Ron

On Mon, Feb 6, 2017 at 4:45 PM, Phil Hord <phil.hord@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
>> I almost got bit by git: I knew there were changes on the remote
>> server, but git status said I was uptodate with the remote.
>>
>
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes?  Use of this option is
> discouraged on shared branches for this very reason.  But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
>
> But if you did not use --force, then you were not in danger of being
> bit.  Git would have prevented the push in that case.
>
>
>> Why ... not design it to [optionally] DO a fetch and THEN declare
>> whether it is up to date?
>
> It's because `git status` does not talk to the remote server, by
> design.  The only Git commands that do talk to the remote are push,
> pull and fetch.  All the rest work off-line and they do so
> consistently.
>
> Imagine `git status` did what you requested; that is, it first did a
> fetch and then reported the status.  Suppose someone pushed a commit
> to the remote immediately after your fetch completed.  Now git will
> still report "up to date" but it will be wrong as soon as the remote
> finishes adding the new push.  Yet the "up to date" message will
> remain on your console, lying to you.  If you leave and come back in
> two days, the message will remain there even if it is no longer
> correct.
>
> So you should accept that `git status` tells you the status with
> respect to your most recent fetch, and that you are responsible for
> the timing of the most recent fetch.  To have git try to do otherwise
> would be misleading.
>
>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
>
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users.  Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps.  :-\

Re: Request re git status

[Konstantin Khomoutov]

On Mon, 6 Feb 2017 22:46:53 -0800
Ron Pero <rpero@magnadev.com> wrote:

[...]
> Still, one way or another, it was easy to feel tripped up by that and
> some kind of verbal cue could help.
> I wonder if this kind of message would help: Latest fetch: {timestamp}
[...]

Timestamps have little to no sense with regard to histories.

What you should make use of is the concept of "tracking branches".
The basic idea is outlined below.

When you fetch from a named remote, like with

  git fetch origin

Git creates/updates the so-called "remote" branches for that named
remote in your local repository.  They live in a special hierarchy of
branches distinct from your "normal" branches, and you typically refer
to them using short (incomplete in fact) names which include the name
of the remote they came from.

For instance, if the repo known as "origin" to your local one
contains the branches "master", "foo" and "devel" at the time the
command above was run, Git would create remote branches "origin/master",
"origin/foo" and "origin/devel".

The whole "remote branches" thing serves to provide you with sort of
bookmarks to the state of a remote repository it was last seen.

You can't commit your own work on remote branches, and can't push them
either (I'm oversimplifying things now but let's not digress).
That's because they are, well, bookmarks, and they are not "yours" --
as opposed to normal local branches.

Now another thing Git offers is the possibility to "link" any local
branch to any remote branch.  This mechanism is called "tracking".
The remote branch linked to a local branch is then called "an upstream"
for that local branch, and that local branch is said to be tracking
that upstream branch.

Say, if you've just fetched from a remote repository and want to work
on a branch "foo" someone created there, you can do

  git checkout -b foo --track origin/foo

if you have existing local branch which doesn't track any remote branch,
you can call

  git branch --set-upstream-to origin/whatever

when it's checked out to make it track the origin/whatever remote
branch.

Tracking makes many Git commands be extra chatty about the state of the
tracking local branch compared to the state of its upstream branch.
Say, `git status` will tell you how many different commits your local
and its upstream branch have compared to each other -- a clear sign
that you should consider merging or rebasing your local work if you're
about to push it to the upstream branch.

While tracking helps in this case, you must understand that Git is a
DVCS, and "D" in it means "distributed" which, in turn, implies
"disconnected".  You should very well understand, that pushing to a
remote repository is inherently racy in this model.  That is, by the
time your `git fetch origin` completed, the state of the branches it
just fetched might have already changed by someone else's push.
So unless your organization / team employs some policy on pushing (that
is, each push to certain "shared" branches must be discussed first and
receive a go-ahead from everyone) you have to be prepared for your
push being rejected because someone else will have managed to push
faster than you.

What I'm leading you to, is that showing you any sort of "last fetch
time" won't really help anyway.  You just should know the drill:

* Make use of the tracking feature.
* Never use --force with `git push` unless you absolutely positively
  understand what happens and you have discussed this with everyone
  else in the team or whoever is in charge for the project.
* If pushing fails, run `git fetch` and reconcile your local changes
  with whatever changes crept in there into the "upstream" branch,
  re-attempt pushing.  Rinse, repeat, if needed.

You're advised to read at least [1], or -- better -- the whole chapter
on branching (even better just read the whole book).

1. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

Re: Request re git status

[Samuel Lijin]

On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord <phil.hord@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
>> I almost got bit by git: I knew there were changes on the remote
>> server, but git status said I was uptodate with the remote.
>>
>
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes?  Use of this option is
> discouraged on shared branches for this very reason.  But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
>
> But if you did not use --force, then you were not in danger of being
> bit.  Git would have prevented the push in that case.
>
>
>> Why ... not design it to [optionally] DO a fetch and THEN declare
>> whether it is up to date?
>
> It's because `git status` does not talk to the remote server, by
> design.  The only Git commands that do talk to the remote are push,
> pull and fetch.  All the rest work off-line and they do so
> consistently.
>
> Imagine `git status` did what you requested; that is, it first did a
> fetch and then reported the status.  Suppose someone pushed a commit
> to the remote immediately after your fetch completed.  Now git will
> still report "up to date" but it will be wrong as soon as the remote
> finishes adding the new push.  Yet the "up to date" message will
> remain on your console, lying to you.  If you leave and come back in
> two days, the message will remain there even if it is no longer
> correct.
>
> So you should accept that `git status` tells you the status with
> respect to your most recent fetch, and that you are responsible for
> the timing of the most recent fetch.  To have git try to do otherwise
> would be misleading.

This argument doesn't work for me. Race conditions in *any*
asynchronous work flow are inevitable; in commits, particularly to a
shared branch, I also can't imagine them being common. It's like
saying because there's lag between the remote's response and the
output on the local, `git fetch` shouldn't bother saying that the
local remote has been updated.

It wouldn't be hard, though, to define an alias that fetches the
remote-tracking branch and then reports the status.

Nevertheless, this is one of those cases where I think Git suffers
from a poor UI/UX - it's letting the underlying model define the
behavior, rather than using the underlying model to drive the
behavior.

>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
>
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users.  Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps.  :-\

Re: Request re git status

[Jacob Keller]

On Tue, Feb 7, 2017 at 6:54 AM, Samuel Lijin <sxlijin@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord <phil.hord@gmail.com> wrote:
>> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
>>> I almost got bit by git: I knew there were changes on the remote
>>> server, but git status said I was uptodate with the remote.
>>>
>>
>> Do you mean you almost pushed some changed history with "--force"
>> which would have lost others' changes?  Use of this option is
>> discouraged on shared branches for this very reason.  But if you do
>> use it, the remote will tell you the hash of the old branch so you can
>> undo the damage.
>>
>> But if you did not use --force, then you were not in danger of being
>> bit.  Git would have prevented the push in that case.
>>
>>
>>> Why ... not design it to [optionally] DO a fetch and THEN declare
>>> whether it is up to date?
>>
>> It's because `git status` does not talk to the remote server, by
>> design.  The only Git commands that do talk to the remote are push,
>> pull and fetch.  All the rest work off-line and they do so
>> consistently.
>>
>> Imagine `git status` did what you requested; that is, it first did a
>> fetch and then reported the status.  Suppose someone pushed a commit
>> to the remote immediately after your fetch completed.  Now git will
>> still report "up to date" but it will be wrong as soon as the remote
>> finishes adding the new push.  Yet the "up to date" message will
>> remain on your console, lying to you.  If you leave and come back in
>> two days, the message will remain there even if it is no longer
>> correct.
>>
>> So you should accept that `git status` tells you the status with
>> respect to your most recent fetch, and that you are responsible for
>> the timing of the most recent fetch.  To have git try to do otherwise
>> would be misleading.
>
> This argument doesn't work for me. Race conditions in *any*
> asynchronous work flow are inevitable; in commits, particularly to a
> shared branch, I also can't imagine them being common. It's like
> saying because there's lag between the remote's response and the
> output on the local, `git fetch` shouldn't bother saying that the
> local remote has been updated.
>
> It wouldn't be hard, though, to define an alias that fetches the
> remote-tracking branch and then reports the status.
>
> Nevertheless, this is one of those cases where I think Git suffers
> from a poor UI/UX - it's letting the underlying model define the
> behavior, rather than using the underlying model to drive the
> behavior.
>

Personally, I think that the fact that Git forces the user to think
about it in terms of "oh I have to fetch" instead of that happening
automatically, it helps teach the model to the user. If it happened in
the background then the user might not be confronted with the
distributed nature of the tool.

An alias to fetch and then show status is very straight forward, and
you can do so locally if you want.

Thanks,
Jake

Re: Request re git status

[Duy Nguyen]

On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> Personally, I think that the fact that Git forces the user to think
> about it in terms of "oh I have to fetch" instead of that happening
> automatically, it helps teach the model to the user. If it happened in
> the background then the user might not be confronted with the
> distributed nature of the tool.

I agree. But I think there is some room for improvement. Do we know
when the last fetch of the relevant upstream is? If we do, and if it's
been "a while" (configurable), then we should make a note suggesting
fetching again in git-status.

This is not exactly my own idea. Gentoo's portage (i.e. friends with
apt-get, yum... if you're not familiar) also has this explicit "fetch"
operation, which is called sync. If you haven't sync'd in a while and
try to install new package, you get a friendly message (that helps me
a couple times).
-- 
Duy

Re: Request re git status

[Jacob Keller]

On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> Personally, I think that the fact that Git forces the user to think
>> about it in terms of "oh I have to fetch" instead of that happening
>> automatically, it helps teach the model to the user. If it happened in
>> the background then the user might not be confronted with the
>> distributed nature of the tool.
>
> I agree. But I think there is some room for improvement. Do we know
> when the last fetch of the relevant upstream is? If we do, and if it's
> been "a while" (configurable), then we should make a note suggesting
> fetching again in git-status.
>
> This is not exactly my own idea. Gentoo's portage (i.e. friends with
> apt-get, yum... if you're not familiar) also has this explicit "fetch"
> operation, which is called sync. If you haven't sync'd in a while and
> try to install new package, you get a friendly message (that helps me
> a couple times).
> --
> Duy

That seems reasonable.

Thanks,
Jake

Re: Request re git status

[Samuel Lijin]

On Wed, Feb 8, 2017 at 12:30 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> Personally, I think that the fact that Git forces the user to think
>>> about it in terms of "oh I have to fetch" instead of that happening
>>> automatically, it helps teach the model to the user. If it happened in
>>> the background then the user might not be confronted with the
>>> distributed nature of the tool.
>>
>> I agree. But I think there is some room for improvement. Do we know
>> when the last fetch of the relevant upstream is? If we do, and if it's
>> been "a while" (configurable), then we should make a note suggesting
>> fetching again in git-status.
>>
>> This is not exactly my own idea. Gentoo's portage (i.e. friends with
>> apt-get, yum... if you're not familiar) also has this explicit "fetch"
>> operation, which is called sync. If you haven't sync'd in a while and
>> try to install new package, you get a friendly message (that helps me
>> a couple times).
>> --
>> Duy

Arch's pacman -S sync operation also has the -y flag, which updates
the local package databases, and can be used in conjunction with the
-u upgrade flag to upgrade repositories.

> That seems reasonable.
>
> Thanks,
> Jake

To be clear, I'm not advocating changing the *default* behavior of git
status; I agree that it wouldn't make sense. And although personally I
constantly update remotes manually (to the point where I abhor using
pull), I do think there's room to add an option to "fetch the
remote-tracking branch" to git status.