On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord <phil.hord@xxxxxxxxx> wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@xxxxxxxxxxxx> 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. :-\