{"thread":{"id":"45064","subject":"Request re git status","startedAt":"2017-02-06T23:35:40Z","lastAt":"2017-02-09T14:11:45Z","messageCount":10,"participants":["Ron Pero","Phil Hord","Konstantin Khomoutov","Samuel Lijin","Jacob Keller","Duy Nguyen","Cornelius Weig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310954","messageId":"CANOj2JG5VuDtS30PfOrZ=4q8pTv_frY7=p+0g=UW3yV6ev+1KQ@mail.gmail.com","threadId":"45064","inReplyTo":null,"subject":"Request re git status","fromName":"Ron Pero","fromEmail":"rpero@magnadev.com","sentAt":"2017-02-06T23:35:33Z","receivedAt":"2017-02-06T23:35:40Z","isPatch":false,"sender":{"key":"rpero@magnadev.com","avatar":null},"body":"Hi\n\nI almost got bit by git: I knew there were changes on the remote\nserver, but git status said I was uptodate with the remote.\n\nThis page explains it well.\n\nhttp://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream\n\nThat page also contains a good suggestion:\n\nWhy ... not design it to [optionally] DO a fetch and THEN declare\nwhether it is up to date? Or change the message to tell what it really\ndid, e.g. \"Your branch was up-to-date with 'origin/master' when last\nchecked at {timestamp}\"? Or even just say, \"Do a fetch to find out\nwhether your branch is up to date\"?\n\nThanks, and best wishes,\n\nRon\n"},{"id":"310960","messageId":"CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com","threadId":"45064","inReplyTo":"CANOj2JG5VuDtS30PfOrZ=4q8pTv_frY7=p+0g=UW3yV6ev+1KQ@mail.gmail.com","subject":"Re: Request re git status","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2017-02-07T00:45:10Z","receivedAt":"2017-02-07T00:45:39Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:\n> I almost got bit by git: I knew there were changes on the remote\n> server, but git status said I was uptodate with the remote.\n>\n\nDo you mean you almost pushed some changed history with \"--force\"\nwhich would have lost others' changes? Use of this option is\ndiscouraged on shared branches for this very reason. But if you do\nuse it, the remote will tell you the hash of the old branch so you can\nundo the damage.\n\nBut if you did not use --force, then you were not in danger of being\nbit. Git would have prevented the push in that case.\n\n\n> Why ... not design it to [optionally] DO a fetch and THEN declare\n> whether it is up to date?\n\nIt's because `git status` does not talk to the remote server, by\ndesign. The only Git commands that do talk to the remote are push,\npull and fetch. All the rest work off-line and they do so\nconsistently.\n\nImagine `git status` did what you requested; that is, it first did a\nfetch and then reported the status. Suppose someone pushed a commit\nto the remote immediately after your fetch completed. Now git will\nstill report \"up to date\" but it will be wrong as soon as the remote\nfinishes adding the new push. Yet the \"up to date\" message will\nremain on your console, lying to you. If you leave and come back in\ntwo days, the message will remain there even if it is no longer\ncorrect.\n\nSo you should accept that `git status` tells you the status with\nrespect to your most recent fetch, and that you are responsible for\nthe timing of the most recent fetch. To have git try to do otherwise\nwould be misleading.\n\n> Or change the message to tell what it really\n> did, e.g. \"Your branch was up-to-date with 'origin/master' when last\n> checked at {timestamp}\"? Or even just say, \"Do a fetch to find out\n> whether your branch is up to date\"?\n\nThese are reasonable suggestions, but i don't think the extra wording\nadds anything for most users. Adding a timestamp seems generally\nuseful, but it could get us into other trouble since we have to depend\non outside sources for timestamps. :-\\\n"},{"id":"310969","messageId":"CANOj2JGAaLLEHMs6KBf2PmCipqu-eYSGADzGGBzNVKwP0DTCtg@mail.gmail.com","threadId":"45064","inReplyTo":"CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Ron Pero","fromEmail":"rpero@magnadev.com","sentAt":"2017-02-07T06:46:53Z","receivedAt":"2017-02-07T06:46:59Z","isPatch":false,"sender":{"key":"rpero@magnadev.com","avatar":null},"body":"Hi Phil\n\nThanks very much for your reply.\n\nI do understand why git status should not automatically fetch from the\nserver. The solution is that I become aware of that nuance (yes, I am\nfairly new to git) and conduct myself that way.\n\nStill, one way or another, it was easy to feel tripped up by that and\nsome kind of verbal cue could help.\nI wonder if this kind of message would help: Latest fetch: {timestamp}\n\nBTW, you might consider posting your answer on\nhttp://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream\n\nWhy? Because someone suggested emailing this suggestion to git@vger.kernel.org.\n\nFrom the stackoverflow page:\n\"It would certainly be possible to add that extra text (behind a\nconfig option so that redundant noise isn't shown if you how Git\nworks) but asking for it here isn't going to change it, try emailing\ngit@vger.kernel.org\"\n\nIn answer to a couple of your points, I was not using force. And I do\nunderstand that if I pushed to origin master it would have stopped the\nmerge, alerting me to the conflict. Thanks for that.\n\nThanks again,\n\nRon\n\nOn Mon, Feb 6, 2017 at 4:45 PM, Phil Hord wrote:\n> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:\n>> I almost got bit by git: I knew there were changes on the remote\n>> server, but git status said I was uptodate with the remote.\n>>\n>\n> Do you mean you almost pushed some changed history with \"--force\"\n> which would have lost others' changes? Use of this option is\n> discouraged on shared branches for this very reason. But if you do\n> use it, the remote will tell you the hash of the old branch so you can\n> undo the damage.\n>\n> But if you did not use --force, then you were not in danger of being\n> bit. Git would have prevented the push in that case.\n>\n>\n>> Why ... not design it to [optionally] DO a fetch and THEN declare\n>> whether it is up to date?\n>\n> It's because `git status` does not talk to the remote server, by\n> design. The only Git commands that do talk to the remote are push,\n> pull and fetch. All the rest work off-line and they do so\n> consistently.\n>\n> Imagine `git status` did what you requested; that is, it first did a\n> fetch and then reported the status. Suppose someone pushed a commit\n> to the remote immediately after your fetch completed. Now git will\n> still report \"up to date\" but it will be wrong as soon as the remote\n> finishes adding the new push. Yet the \"up to date\" message will\n> remain on your console, lying to you. If you leave and come back in\n> two days, the message will remain there even if it is no longer\n> correct.\n>\n> So you should accept that `git status` tells you the status with\n> respect to your most recent fetch, and that you are responsible for\n> the timing of the most recent fetch. To have git try to do otherwise\n> would be misleading.\n>\n>> Or change the message to tell what it really\n>> did, e.g. \"Your branch was up-to-date with 'origin/master' when last\n>> checked at {timestamp}\"? Or even just say, \"Do a fetch to find out\n>> whether your branch is up to date\"?\n>\n> These are reasonable suggestions, but i don't think the extra wording\n> adds anything for most users. Adding a timestamp seems generally\n> useful, but it could get us into other trouble since we have to depend\n> on outside sources for timestamps. :-\\\n"},{"id":"310970","messageId":"20170207103052.d81f8546e6071dced2491f39@domain007.com","threadId":"45064","inReplyTo":"CANOj2JGAaLLEHMs6KBf2PmCipqu-eYSGADzGGBzNVKwP0DTCtg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2017-02-07T07:30:52Z","receivedAt":"2017-02-07T07:31:02Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Mon, 6 Feb 2017 22:46:53 -0800\nRon Pero wrote:\n\n[...]\n> Still, one way or another, it was easy to feel tripped up by that and\n> some kind of verbal cue could help.\n> I wonder if this kind of message would help: Latest fetch: {timestamp}\n[...]\n\nTimestamps have little to no sense with regard to histories.\n\nWhat you should make use of is the concept of \"tracking branches\".\nThe basic idea is outlined below.\n\nWhen you fetch from a named remote, like with\n\n git fetch origin\n\nGit creates/updates the so-called \"remote\" branches for that named\nremote in your local repository. They live in a special hierarchy of\nbranches distinct from your \"normal\" branches, and you typically refer\nto them using short (incomplete in fact) names which include the name\nof the remote they came from.\n\nFor instance, if the repo known as \"origin\" to your local one\ncontains the branches \"master\", \"foo\" and \"devel\" at the time the\ncommand above was run, Git would create remote branches \"origin/master\",\n\"origin/foo\" and \"origin/devel\".\n\nThe whole \"remote branches\" thing serves to provide you with sort of\nbookmarks to the state of a remote repository it was last seen.\n\nYou can't commit your own work on remote branches, and can't push them\neither (I'm oversimplifying things now but let's not digress).\nThat's because they are, well, bookmarks, and they are not \"yours\" --\nas opposed to normal local branches.\n\nNow another thing Git offers is the possibility to \"link\" any local\nbranch to any remote branch. This mechanism is called \"tracking\".\nThe remote branch linked to a local branch is then called \"an upstream\"\nfor that local branch, and that local branch is said to be tracking\nthat upstream branch.\n\nSay, if you've just fetched from a remote repository and want to work\non a branch \"foo\" someone created there, you can do\n\n git checkout -b foo --track origin/foo\n\nif you have existing local branch which doesn't track any remote branch,\nyou can call\n\n git branch --set-upstream-to origin/whatever\n\nwhen it's checked out to make it track the origin/whatever remote\nbranch.\n\nTracking makes many Git commands be extra chatty about the state of the\ntracking local branch compared to the state of its upstream branch.\nSay, `git status` will tell you how many different commits your local\nand its upstream branch have compared to each other -- a clear sign\nthat you should consider merging or rebasing your local work if you're\nabout to push it to the upstream branch.\n\nWhile tracking helps in this case, you must understand that Git is a\nDVCS, and \"D\" in it means \"distributed\" which, in turn, implies\n\"disconnected\". You should very well understand, that pushing to a\nremote repository is inherently racy in this model. That is, by the\ntime your `git fetch origin` completed, the state of the branches it\njust fetched might have already changed by someone else's push.\nSo unless your organization / team employs some policy on pushing (that\nis, each push to certain \"shared\" branches must be discussed first and\nreceive a go-ahead from everyone) you have to be prepared for your\npush being rejected because someone else will have managed to push\nfaster than you.\n\nWhat I'm leading you to, is that showing you any sort of \"last fetch\ntime\" won't really help anyway. You just should know the drill:\n\n* Make use of the tracking feature.\n* Never use --force with `git push` unless you absolutely positively\n understand what happens and you have discussed this with everyone\n else in the team or whoever is in charge for the project.\n* If pushing fails, run `git fetch` and reconcile your local changes\n with whatever changes crept in there into the \"upstream\" branch,\n re-attempt pushing. Rinse, repeat, if needed.\n\nYou're advised to read at least [1], or -- better -- the whole chapter\non branching (even better just read the whole book).\n\n1. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches\n"},{"id":"310985","messageId":"CAJZjrdWbqvBRtyyfhgAt1E9ZdTUaz+Zpk7iGasNoeSuFJbsKog@mail.gmail.com","threadId":"45064","inReplyTo":"CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-07T14:54:07Z","receivedAt":"2017-02-07T14:54:53Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote:\n> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:\n>> I almost got bit by git: I knew there were changes on the remote\n>> server, but git status said I was uptodate with the remote.\n>>\n>\n> Do you mean you almost pushed some changed history with \"--force\"\n> which would have lost others' changes? Use of this option is\n> discouraged on shared branches for this very reason. But if you do\n> use it, the remote will tell you the hash of the old branch so you can\n> undo the damage.\n>\n> But if you did not use --force, then you were not in danger of being\n> bit. Git would have prevented the push in that case.\n>\n>\n>> Why ... not design it to [optionally] DO a fetch and THEN declare\n>> whether it is up to date?\n>\n> It's because `git status` does not talk to the remote server, by\n> design. The only Git commands that do talk to the remote are push,\n> pull and fetch. All the rest work off-line and they do so\n> consistently.\n>\n> Imagine `git status` did what you requested; that is, it first did a\n> fetch and then reported the status. Suppose someone pushed a commit\n> to the remote immediately after your fetch completed. Now git will\n> still report \"up to date\" but it will be wrong as soon as the remote\n> finishes adding the new push. Yet the \"up to date\" message will\n> remain on your console, lying to you. If you leave and come back in\n> two days, the message will remain there even if it is no longer\n> correct.\n>\n> So you should accept that `git status` tells you the status with\n> respect to your most recent fetch, and that you are responsible for\n> the timing of the most recent fetch. To have git try to do otherwise\n> would be misleading.\n\nThis argument doesn't work for me. Race conditions in *any*\nasynchronous work flow are inevitable; in commits, particularly to a\nshared branch, I also can't imagine them being common. It's like\nsaying because there's lag between the remote's response and the\noutput on the local, `git fetch` shouldn't bother saying that the\nlocal remote has been updated.\n\nIt wouldn't be hard, though, to define an alias that fetches the\nremote-tracking branch and then reports the status.\n\nNevertheless, this is one of those cases where I think Git suffers\nfrom a poor UI/UX - it's letting the underlying model define the\nbehavior, rather than using the underlying model to drive the\nbehavior.\n\n>> Or change the message to tell what it really\n>> did, e.g. \"Your branch was up-to-date with 'origin/master' when last\n>> checked at {timestamp}\"? Or even just say, \"Do a fetch to find out\n>> whether your branch is up to date\"?\n>\n> These are reasonable suggestions, but i don't think the extra wording\n> adds anything for most users. Adding a timestamp seems generally\n> useful, but it could get us into other trouble since we have to depend\n> on outside sources for timestamps. :-\\\n"},{"id":"310994","messageId":"CA+P7+xoZHOtURfbBbHHTpC3DsGxaGOVToqmW5wTg2EniRpL-Cg@mail.gmail.com","threadId":"45064","inReplyTo":"CAJZjrdWbqvBRtyyfhgAt1E9ZdTUaz+Zpk7iGasNoeSuFJbsKog@mail.gmail.com","subject":"Re: Request re git status","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-02-07T19:18:21Z","receivedAt":"2017-02-07T19:18:54Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Feb 7, 2017 at 6:54 AM, Samuel Lijin wrote:\n> On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote:\n>> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:\n>>> I almost got bit by git: I knew there were changes on the remote\n>>> server, but git status said I was uptodate with the remote.\n>>>\n>>\n>> Do you mean you almost pushed some changed history with \"--force\"\n>> which would have lost others' changes? Use of this option is\n>> discouraged on shared branches for this very reason. But if you do\n>> use it, the remote will tell you the hash of the old branch so you can\n>> undo the damage.\n>>\n>> But if you did not use --force, then you were not in danger of being\n>> bit. Git would have prevented the push in that case.\n>>\n>>\n>>> Why ... not design it to [optionally] DO a fetch and THEN declare\n>>> whether it is up to date?\n>>\n>> It's because `git status` does not talk to the remote server, by\n>> design. The only Git commands that do talk to the remote are push,\n>> pull and fetch. All the rest work off-line and they do so\n>> consistently.\n>>\n>> Imagine `git status` did what you requested; that is, it first did a\n>> fetch and then reported the status. Suppose someone pushed a commit\n>> to the remote immediately after your fetch completed. Now git will\n>> still report \"up to date\" but it will be wrong as soon as the remote\n>> finishes adding the new push. Yet the \"up to date\" message will\n>> remain on your console, lying to you. If you leave and come back in\n>> two days, the message will remain there even if it is no longer\n>> correct.\n>>\n>> So you should accept that `git status` tells you the status with\n>> respect to your most recent fetch, and that you are responsible for\n>> the timing of the most recent fetch. To have git try to do otherwise\n>> would be misleading.\n>\n> This argument doesn't work for me. Race conditions in *any*\n> asynchronous work flow are inevitable; in commits, particularly to a\n> shared branch, I also can't imagine them being common. It's like\n> saying because there's lag between the remote's response and the\n> output on the local, `git fetch` shouldn't bother saying that the\n> local remote has been updated.\n>\n> It wouldn't be hard, though, to define an alias that fetches the\n> remote-tracking branch and then reports the status.\n>\n> Nevertheless, this is one of those cases where I think Git suffers\n> from a poor UI/UX - it's letting the underlying model define the\n> behavior, rather than using the underlying model to drive the\n> behavior.\n>\n\nPersonally, I think that the fact that Git forces the user to think\nabout it in terms of \"oh I have to fetch\" instead of that happening\nautomatically, it helps teach the model to the user. If it happened in\nthe background then the user might not be confronted with the\ndistributed nature of the tool.\n\nAn alias to fetch and then show status is very straight forward, and\nyou can do so locally if you want.\n\nThanks,\nJake\n"},{"id":"311038","messageId":"CACsJy8CWJvwSnmdpMg=atu+M8=4ksrTAYTgZyF5U7JnOCnPAkg@mail.gmail.com","threadId":"45064","inReplyTo":"CA+P7+xoZHOtURfbBbHHTpC3DsGxaGOVToqmW5wTg2EniRpL-Cg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-02-08T06:13:11Z","receivedAt":"2017-02-08T06:24:31Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote:\n> Personally, I think that the fact that Git forces the user to think\n> about it in terms of \"oh I have to fetch\" instead of that happening\n> automatically, it helps teach the model to the user. If it happened in\n> the background then the user might not be confronted with the\n> distributed nature of the tool.\n\nI agree. But I think there is some room for improvement. Do we know\nwhen the last fetch of the relevant upstream is? If we do, and if it's\nbeen \"a while\" (configurable), then we should make a note suggesting\nfetching again in git-status.\n\nThis is not exactly my own idea. Gentoo's portage (i.e. friends with\napt-get, yum... if you're not familiar) also has this explicit \"fetch\"\noperation, which is called sync. If you haven't sync'd in a while and\ntry to install new package, you get a friendly message (that helps me\na couple times).\n-- \nDuy\n"},{"id":"311041","messageId":"CA+P7+xqg9b+49P6bO65E0q4a87BkNL76XGiUjcMg+UmDcU=WPg@mail.gmail.com","threadId":"45064","inReplyTo":"CACsJy8CWJvwSnmdpMg=atu+M8=4ksrTAYTgZyF5U7JnOCnPAkg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-02-08T06:30:33Z","receivedAt":"2017-02-08T06:40:17Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote:\n> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote:\n>> Personally, I think that the fact that Git forces the user to think\n>> about it in terms of \"oh I have to fetch\" instead of that happening\n>> automatically, it helps teach the model to the user. If it happened in\n>> the background then the user might not be confronted with the\n>> distributed nature of the tool.\n>\n> I agree. But I think there is some room for improvement. Do we know\n> when the last fetch of the relevant upstream is? If we do, and if it's\n> been \"a while\" (configurable), then we should make a note suggesting\n> fetching again in git-status.\n>\n> This is not exactly my own idea. Gentoo's portage (i.e. friends with\n> apt-get, yum... if you're not familiar) also has this explicit \"fetch\"\n> operation, which is called sync. If you haven't sync'd in a while and\n> try to install new package, you get a friendly message (that helps me\n> a couple times).\n> --\n> Duy\n\nThat seems reasonable.\n\nThanks,\nJake\n"},{"id":"311043","messageId":"CAJZjrdU1qz9H5P0uB-PnpN_WoEtRVA9SQN_5pBPJzvzsYVby_A@mail.gmail.com","threadId":"45064","inReplyTo":"CA+P7+xqg9b+49P6bO65E0q4a87BkNL76XGiUjcMg+UmDcU=WPg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-08T07:44:20Z","receivedAt":"2017-02-08T07:45:31Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Wed, Feb 8, 2017 at 12:30 AM, Jacob Keller wrote:\n> On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote:\n>> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote:\n>>> Personally, I think that the fact that Git forces the user to think\n>>> about it in terms of \"oh I have to fetch\" instead of that happening\n>>> automatically, it helps teach the model to the user. If it happened in\n>>> the background then the user might not be confronted with the\n>>> distributed nature of the tool.\n>>\n>> I agree. But I think there is some room for improvement. Do we know\n>> when the last fetch of the relevant upstream is? If we do, and if it's\n>> been \"a while\" (configurable), then we should make a note suggesting\n>> fetching again in git-status.\n>>\n>> This is not exactly my own idea. Gentoo's portage (i.e. friends with\n>> apt-get, yum... if you're not familiar) also has this explicit \"fetch\"\n>> operation, which is called sync. If you haven't sync'd in a while and\n>> try to install new package, you get a friendly message (that helps me\n>> a couple times).\n>> --\n>> Duy\n\nArch's pacman -S sync operation also has the -y flag, which updates\nthe local package databases, and can be used in conjunction with the\n-u upgrade flag to upgrade repositories.\n\n> That seems reasonable.\n>\n> Thanks,\n> Jake\n\nTo be clear, I'm not advocating changing the *default* behavior of git\nstatus; I agree that it wouldn't make sense. And although personally I\nconstantly update remotes manually (to the point where I abhor using\npull), I do think there's room to add an option to \"fetch the\nremote-tracking branch\" to git status.\n"},{"id":"311176","messageId":"5e9357f3-ca64-bdc9-34d1-67e700de7995@tngtech.com","threadId":"45064","inReplyTo":"CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com","subject":"Re: Request re git status","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-07T01:15:49Z","receivedAt":"2017-02-09T14:11:45Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 02/07/2017 01:45 AM, Phil Hord wrote:\n> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:\n> Do you mean you almost pushed some changed history with \"--force\"\n> which would have lost others' changes? Use of this option is\n> discouraged on shared branches for this very reason. But if you do\n> use it, the remote will tell you the hash of the old branch so you can\n> undo the damage.\n> \n> But if you did not use --force, then you were not in danger of being\n> bit. Git would have prevented the push in that case.\n\nI totally agree with Phil. Besides, git-status should be fast. And\ntalking to a remote can be painfully slow. As Phil pointed out, even the\nslow answer when talking to the remote can give you better guarantees\nthan the quick (local) answer. Therefore, I prefer the quick answer.\n\nSince you pointed out the use of --force, I want to add the\n--force-with-lease option of git-push. The idea is basically, that we\nmay force-push, if the remote end does indeed have the state we think it\nhas. This avoids those situations where somebody pushed to the remote\nwhile you were typing 'git push --force' (which would then loose the\nother contributor's work). For details have a look at 'git help push'.\n\n>> Or change the message to tell what it really\n>> did, e.g. \"Your branch was up-to-date with 'origin/master' when last\n>> checked at {timestamp}\"? Or even just say, \"Do a fetch to find out\n>> whether your branch is up to date\"?\n> \n> These are reasonable suggestions, but i don't think the extra wording\n> adds anything for most users. Adding a timestamp seems generally\n> useful, but it could get us into other trouble since we have to depend\n> on outside sources for timestamps. \n\nThe date of the last update is actually stored in the reflogs for the\nremote branches. That timestamp is \"internal\" and could be trusted.\nHowever, I don't quite believe that it would avoid accidents. For that\nyou would have to remember the time when some other (!) contributor has\npushed to the remote AND recognize that its timestamp is after the date\nprinted.\nI prefer being warned by git when I try to do something stupid.\n"}]}