1

I erred by working locally on a local repo's "main" branch, instead of branching out with a new branch and modifying code there. I brought more modifications to the code than I thought I would, all without pushing anything to remote "origin". A quick $ git reflog --date=iso | grep pull yielded the hash that corresponds to the pull from "origin/main", from which I should have branched out in the first place (and didn't), say it's "D".

Before restoring my local "main" to the prior state of interest, "D", I created a "new-branch". Now I have:

         E' (new-branch)
        /   
B--D--(E)   (main)

So currently E' reflects all changes locally made to D. What I would like is to end up with all changes reflected in E' to be as if they :

     E'     (new-branch)
    /   
B--D--      (main)

Not sure that the two schematics above are fully correct representation. In any case it's all local. Would doing

$ git checkout main
$ git checkout -b new-branch
$ git checkout main
$ git reset --soft <sha1_for-D>

revert all changes to previous state "D" on my local "main", while preserving changes stored in "new-branch" as "E'". But is this strictly equivalent to

$ git checkout main
$ git switch -c new-branch
$ git checkout main

as suggested here?

Continuing to work on "new-branch" will eventually lead to a merge into "main" after testing. Will that future "merge" unfold any differently from a merge that would have occurred with no soft reset on "main" ?

SwissCodeMen
  • 4,222
  • 8
  • 24
  • 34
Cbhihe
  • 511
  • 9
  • 24
  • I don't know.... I think it would be ok to create (or _place_ if it's already created) the new branch on `E'` (if it's not there already) and then just reset the local `main` to where `origin/main` is. The trick is to understand that branches are just _pointers to commits_ that you are free to move around at will, it's not like there's metadata in the commits that keeps track of the _branches_ that were used to create them. – eftshift0 Jul 03 '23 at 16:13
  • By the way.... you could also consider keeping a local `main` branch is worth it if your goal about it is to keep it in perfect sync with `origin/main`. You can interact with `origin/main` without having to use the local `main` branch. – eftshift0 Jul 03 '23 at 16:14
  • What is `(E)` in your chart? And a nice chart in the question having `main`, `origin/main` and `new-branch` would be awesome.... something like `git log --oneline --graph main origin/main new-branch` – eftshift0 Jul 03 '23 at 16:15
  • @eftshift0: tx. I think I understand your first comment, but not sure I do your second one. How can I NOT use the local main branch if it is the backbone for all feature development and part of the testing ? -- As for (E), I put it in parentheses because this was a local commit I removed after creating the *new-branch*. Just my notation; sorry if not appropriate. – Cbhihe Jul 03 '23 at 16:23
  • i think the chart with `git log` will help. If your muscle memory is used to using a local `main` branch, it's ok.... it's just unnecessary and you might be surprised how easy it is to avoid it... but it needs some adjustments that I won't be able to explain in a comment. – eftshift0 Jul 03 '23 at 16:26

1 Answers1

1

Your chart is a bit misleading, as there seems to be no commit E'. After git checkout -n new-branch both branches point to the same commit E like this:

C--D--E (main) (new-branch)

If you then checkout main and reset it to commit D as you proposed this will result in

     E (new-branch)
    /
C--D   (main)

You might want to consider using git reset --hard or at least switch back to the new-branch immediately after the reset to not have this somewhat confusing state of the repository with lots of uncomitted local changes that git reset --soft leaves behind.

SebDieBln
  • 3,303
  • 1
  • 7
  • 21
  • Oh, I thought preserving the index was preferable to a hard reset, without fully understanding why that that would be an advantage if all code changes were effectively captured in E' (or E as per your chart) ... Also my bad for the initial typo on `git checkout -n..` . I fixed it to be `git checkout -b ...`. -- Finally I did a hard reset, and everything went well. Tx, – Cbhihe Jul 03 '23 at 16:57