-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make git push --force-with-lease
safer
#640
Comments
Hi @dscho ! Is this issue still unsolved? I studied this and it seemed very interesting to me. I would like to work on this. |
From what I have inferred, the issue is that many Git UIs or sometimes even the user may unknowingly fetch the latest status of the remote ref but will not compare it with our local branch before pushing since the user does not ask so. Right now, our job is to make sure that the local incorporates the tip of the remote, essentially doing a fetch first and then comparing before pushing, is that correct? I am not able to understand how this happens as you quote here:
How will we overwrite any updates when the remote ref won't match the local ref when we use the |
I think that this has been addressed via the |
@periperidip and if you're looking for work, how about finishing |
What exactly is missing would you like to talk about it a little bit here? |
I am quite bored with the whole work. I was thinking of trying something else with Git. Plus, that work has been finalised as a project for the upcoming GSoC too. Do you have any other stuff I could work on? Any issues which are left or any discussions which are going on? I was also thinking of working on some |
In that case, I do not want you to work on any issue that concerns me personally, lest you get bored on working on that, too ;-) |
@dscho, could you please direct me to the work that was done previously on this (and any other relevant links maybe). Maybe I could work on it and try to finish it :). |
Sure. https://lore.kernel.org/git/[email protected]/ seems to be the latest attempt, and git@1861aa4#diff-1e38796093f163084858763921ead3459e09087f85af3e4354f3401c1641392dR1158-R1169 has the information what still needs to be done. But please only work on this if you find it personally satisfying or interesting. |
Thanks 😄
Sure, it would help me dive deep into the codebase and understand it properly :). |
I guess if it was up to me, I'd not work on submodules, unless I had committed to it. In my mind, submodules are a mistake by design. Therefore, if I were to work in this space, I'd try to design something with the same goal (allowing not to check out a given set of subdirectories) around partial clone and |
Okay, then I'd rather find a different issue to work on. Thanks 😄 |
I mean, I don't want to discourage you from working on submodules, at the same time I have to admit that I find other parts of Git much more rewarding. |
The
--force-with-lease
option ensures that you can only force-push updates where your remote-tracking ref agrees with the remote ref.Obviously, the idea was that if you call
git pull <remote>
, you will have seen and incorporated the remote commits, even if you rebased and the result therefore does not fast-forward.However, one rather common setup is ignored by this idea: Git UIs often "helpfully" fetch in the background. And that does not update the local branch, therefore it is quite possible to lose commits inadvertently.
On the mailing list, I proposed the following strategy:
The text was updated successfully, but these errors were encountered: