{"thread":{"id":"50961","subject":"[PATCH v2] Give git-pull a --reset option","startedAt":"2019-04-21T04:09:13Z","lastAt":"2019-04-22T15:14:39Z","messageCount":7,"participants":["Alex Henrie","Junio C Hamano","Philip Oakley","brian m. carlson","Phillip Wood"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"374179","messageId":"20190421040823.24821-1-alexhenrie24@gmail.com","threadId":"50961","inReplyTo":null,"subject":"[PATCH v2] Give git-pull a --reset option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2019-04-21T04:08:23Z","receivedAt":"2019-04-21T04:09:13Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"A common workflow is to make a commit on a local branch, push the branch\nto the remote, check out the remote branch on a second computer, amend\nthe commit on the second computer, force-push back to the remote branch,\nand finally submit a pull request. However, if the user switches back to\nthe first computer, they must then run the cumbersome command\n`git fetch && git reset --hard origin`. (Actually, at this point Git\nnovices often try running `git pull --force`, but it doesn't do what\nthey expect.) This patch adds the shortcut `git pull --reset` to serve\nas a complement to `git push --force`.\n\nSigned-off-by: Alex Henrie \n---\n Documentation/git-pull.txt | 8 ++++++++\n builtin/pull.c | 23 +++++++++++++++++++++++\n t/t5520-pull.sh | 24 ++++++++++++++++++++++++\n 3 files changed, 55 insertions(+)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 118d9d86f7..032a5c2e34 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -23,6 +23,7 @@ More precisely, 'git pull' runs 'git fetch' with the given\n parameters and calls 'git merge' to merge the retrieved branch\n heads into the current branch.\n With `--rebase`, it runs 'git rebase' instead of 'git merge'.\n+With `--reset`, it runs `git reset --hard` instead of 'git merge'.\n \n should be the name of a remote repository as\n passed to linkgit:git-fetch[1]. can name an\n@@ -141,6 +142,13 @@ unless you have read linkgit:git-rebase[1] carefully.\n +\n This option is only valid when \"--rebase\" is used.\n \n+--reset::\n+\tReset the local branch to be identical to the remote branch, discarding\n+\tany local commits or other changes.\n+\n+--no-reset::\n+\tOverride earlier --reset.\n+\n Options related to fetching\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n \ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 33db889955..b32134c1f1 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -95,6 +95,7 @@ static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;\n \n /* Options passed to git-merge or git-rebase */\n static enum rebase_type opt_rebase = -1;\n+static char *opt_reset;\n static char *opt_diffstat;\n static char *opt_log;\n static char *opt_signoff;\n@@ -144,6 +145,9 @@ static struct option pull_options[] = {\n \t \"(false|true|merges|preserve|interactive)\",\n \t N_(\"incorporate changes by rebasing rather than merging\"),\n \t PARSE_OPT_OPTARG, parse_opt_rebase },\n+\tOPT_PASSTHRU(0, \"reset\", &opt_reset, NULL,\n+\t\tN_(\"discard all local changes rather than merging\"),\n+\t\tPARSE_OPT_NOARG | PARSE_OPT_NONEG),\n \tOPT_PASSTHRU('n', NULL, &opt_diffstat, NULL,\n \t\tN_(\"do not show a diffstat at the end of the merge\"),\n \t\tPARSE_OPT_NOARG | PARSE_OPT_NONEG),\n@@ -860,6 +864,16 @@ static int run_rebase(const struct object_id *curr_head,\n \treturn ret;\n }\n \n+/**\n+ * Runs git-reset, returning its exit status.\n+ */\n+static int run_reset(void)\n+{\n+\tstatic const char *argv[] = { \"reset\", \"--hard\", \"FETCH_HEAD\", NULL };\n+\n+\treturn run_command_v_opt(argv, RUN_GIT_CMD);\n+}\n+\n int cmd_pull(int argc, const char **argv, const char *prefix)\n {\n \tconst char *repo, **refspecs;\n@@ -892,6 +906,9 @@ int cmd_pull(int argc, const char **argv, const char *prefix)\n \tif (get_oid(\"HEAD\", &orig_head))\n \t\toidclr(&orig_head);\n \n+\tif (opt_rebase && opt_reset)\n+\t\tdie(_(\"--rebase and --reset are mutually exclusive\"));\n+\n \tif (!opt_rebase && opt_autostash != -1)\n \t\tdie(_(\"--[no-]autostash option is only valid with --rebase.\"));\n \n@@ -986,6 +1003,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)\n \t\t\tret = rebase_submodules();\n \n \t\treturn ret;\n+\t} else if (opt_reset) {\n+\t\tint ret = run_reset();\n+\t\tif (!ret && (recurse_submodules == RECURSE_SUBMODULES_ON ||\n+\t\t\t recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND))\n+\t\t\tret = update_submodules();\n+\t\treturn ret;\n \t} else {\n \t\tint ret = run_merge();\n \t\tif (!ret && (recurse_submodules == RECURSE_SUBMODULES_ON ||\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex cf4cc32fd0..597f2429d5 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -708,4 +708,28 @@ test_expect_success 'git pull --rebase against local branch' '\n \ttest file = \"$(cat file2)\"\n '\n \n+test_expect_success 'git pull --rebase --reset is an invalid combination' '\n+\ttest_must_fail git pull --rebase --reset .\n+'\n+\n+test_expect_success 'git pull --reset overwrites or deletes all tracked files' '\n+\tgit init cloned &&\n+\t(\n+\t\tcd cloned &&\n+\t\techo committed > committed &&\n+\t\techo staged > staged &&\n+\t\techo untracked > file &&\n+\t\techo untracked > untracked &&\n+\t\tgit add committed &&\n+\t\tgit commit -m original &&\n+\t\tgit add staged &&\n+\t\tgit pull --reset .. &&\n+\t\ttest ! -f committed &&\n+\t\ttest ! -f staged &&\n+\t\ttest \"$(cat untracked)\" = \"untracked\" &&\n+\t\ttest \"$(git status --porcelain)\" = \"?? untracked\"\n+\t) &&\n+\ttest_cmp file cloned/file\n+'\n+\n test_done\n-- \n2.21.0\n\n"},{"id":"374183","messageId":"xmqqftqbdijl.fsf@gitster-ct.c.googlers.com","threadId":"50961","inReplyTo":"20190421040823.24821-1-alexhenrie24@gmail.com","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-04-21T05:38:38Z","receivedAt":"2019-04-21T05:38:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Henrie writes:\n\n> A common workflow is to make a commit on a local branch, push the branch\n> to the remote, check out the remote branch on a second computer, amend\n> the commit on the second computer, force-push back to the remote branch,\n> and finally submit a pull request. However, if the user switches back to\n> the first computer, they must then run the cumbersome command\n> `git fetch && git reset --hard origin`. \n\nDoesn't anybody sense there is a larger problem if such a workflow\nis \"common\" in the first place? In that sequence, when you come\nback to the first repository there is no guarantee that what you are\nlosing is exactly what you are willing to lose and nothing else\n(i.e. your earlier WIP you sent to the second repository, which was\nfurther polished, making the earlier WIP you had here irrelevant).\n\nIf the last \"recovery at the first repository\" step were \"pull --rebase\",\nat least you would realize that you have the earlier WIP locally\nthat either\n\n (1) conflicts with the more polished work that have been\n accepted at the upstream, in which case you can tell the\n rebase machinery to drop that earlier WIP _after_ making\n sure that it is only that stale WIP you not only are willing\n to but actively do want to lose that is getting discarded.\n\n (2) replays cleanly on top of the updated upstream, which hasn't\n accepted your pull request made from the second repository\n with the more polished version, in which case you'd realize\n that you may have to work on the topic further. And you\n have a chance to inspect what you ended up with before using\n \"reset --hard\" or \"rebase -i\" to discard what you no longer\n need.\n\nAt least, I think the longhand this attempts to replace, \"fetch\"\nfollowed by \"reset --hard origin\" is better because of two reasons.\nIt is more explicit that the procedure is destructive, and more\nimportantly, it can allow to have (and we should encourage users to\nmake a habit to have) an extra step to inspect what the user is\nabout to lose with \"git log origin..\" after \"fetch\" but before\n\"reset --hard\".\n\nSo I have a moderately strong suspicion that \"git pull --reset\"\npromotes a wrong workflow and should not exist.\n"},{"id":"374184","messageId":"CAMMLpeRnwrcjn3UAgs5p532pf8=xAwBqh2qg7Cfqun6qsqD06w@mail.gmail.com","threadId":"50961","inReplyTo":"xmqqftqbdijl.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2019-04-21T07:01:02Z","receivedAt":"2019-04-21T07:01:20Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano wrote:\n>\n> Alex Henrie writes:\n>\n> > A common workflow is to make a commit on a local branch, push the branch\n> > to the remote, check out the remote branch on a second computer, amend\n> > the commit on the second computer, force-push back to the remote branch,\n> > and finally submit a pull request. However, if the user switches back to\n> > the first computer, they must then run the cumbersome command\n> > `git fetch && git reset --hard origin`.\n>\n> Doesn't anybody sense there is a larger problem if such a workflow\n> is \"common\" in the first place? In that sequence, when you come\n> back to the first repository there is no guarantee that what you are\n> losing is exactly what you are willing to lose and nothing else\n> (i.e. your earlier WIP you sent to the second repository, which was\n> further polished, making the earlier WIP you had here irrelevant).\n\nYou may be right. On the other hand, you're expected to think about\nwhat you're doing before running `git push --force` and clobbering a\nremote branch. Similarly, you would be expected to think about what\nyou're doing before running `git pull --reset` and clobbering a local\nbranch. It's actually easier to recover from accidentally clobbering a\nlocal branch than accidentally clobbering a remote branch because you\ncan use `git reflog` to find the lost commits.\n\n> If the last \"recovery at the first repository\" step were \"pull --rebase\",\n> at least you would realize that you have the earlier WIP locally\n> that either\n>\n> (1) conflicts with the more polished work that have been\n> accepted at the upstream, in which case you can tell the\n> rebase machinery to drop that earlier WIP _after_ making\n> sure that it is only that stale WIP you not only are willing\n> to but actively do want to lose that is getting discarded.\n>\n> (2) replays cleanly on top of the updated upstream, which hasn't\n> accepted your pull request made from the second repository\n> with the more polished version, in which case you'd realize\n> that you may have to work on the topic further. And you\n> have a chance to inspect what you ended up with before using\n> \"reset --hard\" or \"rebase -i\" to discard what you no longer\n> need.\n\nI understand that `git pull --rebase` followed by `git rebase --skip`\nis a safer workflow. I just feel like an option like `git pull\n--reset` should be there for users who know what they're doing, just\nlike `git push --force` is available for users who know what they're\ndoing.\n\n> At least, I think the longhand this attempts to replace, \"fetch\"\n> followed by \"reset --hard origin\" is better because of two reasons.\n> It is more explicit that the procedure is destructive, and more\n> importantly, it can allow to have (and we should encourage users to\n> make a habit to have) an extra step to inspect what the user is\n> about to lose with \"git log origin..\" after \"fetch\" but before\n> \"reset --hard\".\n\nI'd be happy to emphasize the destructive nature of this option by\ncalling it `git pull --hard-reset` instead.\n\n> So I have a moderately strong suspicion that \"git pull --reset\"\n> promotes a wrong workflow and should not exist.\n\nIt'd be great to get some feedback from other Git users, but in the\nend it's up to you and I trust your decision.\n\n-Alex\n"},{"id":"374200","messageId":"e816c3d6-5948-5f4b-0a1e-67f7dee43f2d@iee.org","threadId":"50961","inReplyTo":"CAMMLpeRnwrcjn3UAgs5p532pf8=xAwBqh2qg7Cfqun6qsqD06w@mail.gmail.com","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-04-21T13:53:45Z","receivedAt":"2019-04-21T13:53:50Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Alex\n\nOn 21/04/2019 08:01, Alex Henrie wrote:\n> On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano wrote:\n>> Alex Henrie writes:\n>>\n>>> A common workflow is to make a commit on a local branch, push the branch\n>>> to the remote, check out the remote branch on a second computer, amend\n>>> the commit on the second computer, force-push back to the remote branch,\n>>> and finally submit a pull request. However, if the user switches back to\n>>> the first computer, they must then run the cumbersome command\n>>> `git fetch && git reset --hard origin`.\nThis will be quite a common occurrence especially for personal repos on \none of the hosting sites (GitHub, GitLab, etc), so we know that we are \nthe only user of that repo.\n\nI've certainly used that style of technique for Windows vs Linux machine \ntransfers of Git work (when my old hack linux machine is functional:-).\n>> Doesn't anybody sense there is a larger problem if such a workflow\n>> is \"common\" in the first place? In that sequence, when you come\n>> back to the first repository there is no guarantee that what you are\n>> losing is exactly what you are willing to lose and nothing else\n>> (i.e. your earlier WIP you sent to the second repository, which was\n>> further polished, making the earlier WIP you had here irrelevant).\nI'd agree that a public/joint repository could have issues if a user \nblindly assumes that no one has cooperated with them and added more \ncommits, but that becomes a social issue (plus worthy of a documentation \nmention!).\n\nThere are still a few blind spots in the functionality of Git regarding \nhow users interact with their hosting provider, which is trying to be \n(from a user perspective) both a backup and an independent repo (side \ndiscussion at Git Merge). This would appear to be one of those cases \nwhere one is collaborating with no-one (oneself), but from two machines.\n\nIt may just be that we need to put aside `pull` because of its old \nsemantics, and start with a fresh command name for the 'fetch + sort \nstuff out' for these use cases.\n> You may be right. On the other hand, you're expected to think about\n> what you're doing before running `git push --force` and clobbering a\n> remote branch. Similarly, you would be expected to think about what\n> you're doing before running `git pull --reset` and clobbering a local\n> branch. It's actually easier to recover from accidentally clobbering a\n> local branch than accidentally clobbering a remote branch because you\n> can use `git reflog` to find the lost commits.\n>\n>> If the last \"recovery at the first repository\" step were \"pull --rebase\",\n>> at least you would realize that you have the earlier WIP locally\n>> that either\n>>\n>> (1) conflicts with the more polished work that have been\n>> accepted at the upstream, in which case you can tell the\n>> rebase machinery to drop that earlier WIP _after_ making\n>> sure that it is only that stale WIP you not only are willing\n>> to but actively do want to lose that is getting discarded.\n>>\n>> (2) replays cleanly on top of the updated upstream, which hasn't\n>> accepted your pull request made from the second repository\n>> with the more polished version, in which case you'd realize\n>> that you may have to work on the topic further. And you\n>> have a chance to inspect what you ended up with before using\n>> \"reset --hard\" or \"rebase -i\" to discard what you no longer\n>> need.\n> I understand that `git pull --rebase` followed by `git rebase --skip`\n> is a safer workflow. I just feel like an option like `git pull\n> --reset` should be there for users who know what they're doing, just\n> like `git push --force` is available for users who know what they're\n> doing.\n>\n>> At least, I think the longhand this attempts to replace, \"fetch\"\n>> followed by \"reset --hard origin\" is better because of two reasons.\n>> It is more explicit that the procedure is destructive, and more\n>> importantly, it can allow to have (and we should encourage users to\n>> make a habit to have) an extra step to inspect what the user is\n>> about to lose with \"git log origin..\" after \"fetch\" but before\n>> \"reset --hard\".\n> I'd be happy to emphasize the destructive nature of this option by\n> calling it `git pull --hard-reset` instead.\n>\n>> So I have a moderately strong suspicion that \"git pull --reset\"\n>> promotes a wrong workflow and should not exist.\n> It'd be great to get some feedback from other Git users, but in the\n> end it's up to you and I trust your decision.\n>\n> -Alex\nI though it worth chiming in that folks do use these simple dumb use cases.\n--\nPhilip\n"},{"id":"374205","messageId":"20190421211833.GC6316@genre.crustytoothpaste.net","threadId":"50961","inReplyTo":"xmqqftqbdijl.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-04-21T21:18:33Z","receivedAt":"2019-04-21T21:18:41Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Apr 21, 2019 at 02:38:38PM +0900, Junio C Hamano wrote:\n> Alex Henrie writes:\n> \n> > A common workflow is to make a commit on a local branch, push the branch\n> > to the remote, check out the remote branch on a second computer, amend\n> > the commit on the second computer, force-push back to the remote branch,\n> > and finally submit a pull request. However, if the user switches back to\n> > the first computer, they must then run the cumbersome command\n> > `git fetch && git reset --hard origin`. \n> \n> Doesn't anybody sense there is a larger problem if such a workflow\n> is \"common\" in the first place? In that sequence, when you come\n> back to the first repository there is no guarantee that what you are\n> losing is exactly what you are willing to lose and nothing else\n> (i.e. your earlier WIP you sent to the second repository, which was\n> further polished, making the earlier WIP you had here irrelevant).\n\nIt may be helpful to point out that this is essentially the workflow I\nhad before I had only one computer. I would make some changes on my\ndesktop, which was my primary computer, then need to travel somewhere\nand use my laptop. I would want to go back to my desktop when I returned\nhome, because it was far more powerful, and I would know that I was the\nonly user of this branch.\n\nNow, as a contributor and a moderately advanced user, I would likely end\nup using \"git commit --fixup\" (or \"--squash\") for this purpose and\nsquash only before submitting, but there are situations where fixup\ncommits cause conflicts and it's necessary to do a rebase and force push\nif you don't want extensive pain.\n\nSo while I think that \"git pull --rebase\" or \"git pull --ff-only\" are\nprobably better options in most situations, I can see the use in this\ncommand, with appropriate foresight and knowledge. I can also see how\nit's easy to blow away data with the proposed option, especially for\nnovice users, who are likely not aware of how to restore it from the\nreflog.\n\nI'm not sure if this email is an argument for or against this option,\nbut maybe it provides some helpful perspective.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"374206","messageId":"xmqqftqb9bf1.fsf@gitster-ct.c.googlers.com","threadId":"50961","inReplyTo":"20190421211833.GC6316@genre.crustytoothpaste.net","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-04-21T23:38:26Z","receivedAt":"2019-04-21T23:38:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> It may be helpful to point out that this is essentially the workflow I\n> had ...\n> I'm not sure if this email is an argument for or against this option,\n> but maybe it provides some helpful perspective.\n\nI think you and Phillip misread me.\n\nI did not question if the workflow is common the message you are\nresponding to. I've done my fair share of \"I know what I have on my\nlaptop is stale as I pushed it out to elsewhere to continue working\non it, so let's get rid of it from the updated upstream and start\nafresh\" myself.\n\nWhat I questioned was if it is sensible to ensure that it stays\ncommon.\n\nWe'd be encouraging the dangerous workflow, instead of analysing the\nsituation where people employ it and trying to give them a better\nalternative to deal with the situation. That is what we'd be doing\nwith \"pull --reset\", i.e. an easier to type short-hand that robs the\nchance to double check in the middle of \"fetch && inspect && reset\"\nsequence.\n\nAs to where the feature should go, if we decide that it is a good\nidea to promote this workflow element as a supported feature, I\nagree with Alex's design in the patch that it makes sense to have it\nas \"pull --reset\". Existing \"pull --merge\" and \"pull -rebase\" are\n\"fetch and then integrate by merging theirs into ours\" and \"fetch\nand then integrate by rebasing our stuff on top of theirs\"; the new\n\"pull --reset\" would fit well sitting next to them with its \"fetch\nand then treat our stuff as valueless and replace it with theirs\"\nsemantics.\n"},{"id":"374244","messageId":"02595523-3b16-b434-1ea9-a9399d7f1783@gmail.com","threadId":"50961","inReplyTo":"xmqqftqb9bf1.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2] Give git-pull a --reset option","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-04-22T15:14:34Z","receivedAt":"2019-04-22T15:14:39Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"\n\nOn 22/04/2019 00:38, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n>> It may be helpful to point out that this is essentially the workflow I\n>> had ...\n>> I'm not sure if this email is an argument for or against this option,\n>> but maybe it provides some helpful perspective.\n> \n> I think you and Phillip misread me.\n> \n> I did not question if the workflow is common the message you are\n> responding to. I've done my fair share of \"I know what I have on my\n> laptop is stale as I pushed it out to elsewhere to continue working\n> on it, so let's get rid of it from the updated upstream and start\n> afresh\" myself.\n> \n> What I questioned was if it is sensible to ensure that it stays\n> common.\n> \n> We'd be encouraging the dangerous workflow, instead of analysing the\n> situation where people employ it and trying to give them a better\n> alternative to deal with the situation. \n\nI agree that it would be better to support this workflow in a safer \nmanner. I use a script that looks at the reflog of the local and remote \nbranches to work out if it is safe to reset --hard when pulling. If \nthere are local changes since the last push/pull (because I forget to \nsync before starting work) then it will run rebase --onto \n. If the remote branch and local branches have both been \nrewritten it tells me to run range-diff to figure out how to fix it.\n\nThe value of is the most recent push or pull that updated \nthe local branch. i.e. when both the local and remote refs pointed to \nthe same commit at the same time (rebase complicates this as the remote \nwe rebased onto does not appear in directly the local reflog - you have \nto look for \"rebase .*finish.* \". Also an ide \nmight auto fetch and update the remote ref while we're rebasing the \nlocal work which stops the reflog coinciding exactly.) The \nis also useful for making forced pushes safer. The script pushes with \n--force-with-lease=: if the local branch has been \nrewritten since the last sync so that any remote changes since the last \nsync are not overwritten.\n\nUsing the reflog to figure out the last sync makes forced pushes and \npulls much safer. If we want to support this workflow in core git (and \nit does seem to be fairly common) then I think it needs to be based on \nsomething that prevents people from accidentally throwing away local \nchanges when pulling and remote changes when pushing. There was some \ndiscussion of this with respect to pushing last summer[1]\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://public-inbox.org/git/CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@mail.gmail.com/T/#u\n\n That is what we'd be doing\n> with \"pull --reset\", i.e. an easier to type short-hand that robs the\n> chance to double check in the middle of \"fetch && inspect && reset\"\n> sequence.\n> \n> As to where the feature should go, if we decide that it is a good\n> idea to promote this workflow element as a supported feature, I\n> agree with Alex's design in the patch that it makes sense to have it\n> as \"pull --reset\". Existing \"pull --merge\" and \"pull -rebase\" are\n> \"fetch and then integrate by merging theirs into ours\" and \"fetch\n> and then integrate by rebasing our stuff on top of theirs\"; the new\n> \"pull --reset\" would fit well sitting next to them with its \"fetch\n> and then treat our stuff as valueless and replace it with theirs\"\n> semantics.\n> \n"}]}