Re: Request re git status
- From
- Cornelius Weig <cornelius.weig@tngtech.com>
- Date
- Feb 7, 2017, 01:15 UTC
- Message-ID
- <5e9357f3-ca64-bdc9-34d1-67e700de7995@tngtech.com>
- In-Reply-To
- <CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com>
On 02/07/2017 01:45 AM, Phil Hord wrote:
Show 9 quoted lines
> 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'.
Show 9 quoted lines
>> 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.