On Tue, Feb 7, 2017 at 6:54 AM, Samuel Lijin <sxlijin@xxxxxxxxx> wrote: > 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. > 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