Re: Request re git status
On 02/07/2017 01:45 AM, Phil Hord wrote: > On Mon, Feb 6, 2017 at 3:36 PM Ron Pero 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
On Wed, Feb 8, 2017 at 12:30 AM, Jacob Keller wrote: > On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote: >> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller 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.
Re: Request re git status
On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote: > On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller 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
On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller 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
On Tue, Feb 7, 2017 at 6:54 AM, Samuel Lijin wrote: > On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote: >> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero 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
On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote: > On Mon, Feb 6, 2017 at 3:36 PM Ron Pero 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
On Mon, 6 Feb 2017 22:46:53 -0800 Ron Pero 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
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 wrote: > On Mon, Feb 6, 2017 at 3:36 PM Ron Pero 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
On Mon, Feb 6, 2017 at 3:36 PM Ron Pero 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. :-\