-2

Well, I thought I knew how to do this... I did the sequence shown here, but am still stuck.

My sequence:

git reset --hard
git clean -fd
git pull

and I get error:

CONFLICT (content) Merge conflict in <file>

How do I get past this?

Deleting the local files before the process makes no difference.

Jonesome Reinstate Monica
  • 6,618
  • 11
  • 65
  • 112
  • 1
    Are you trying to remove your new local commits that aren't on the remote branch also? If the answer is yes, then you *didn't* do what the answer you linked to says to do. You left off the remote branch at the end of the hard reset command. You would need `git reset --hard @{u}` (and you're done, no need to pull after that). – TTT Mar 22 '22 at 18:32
  • @TTT Thank you. You are correct. I assumed that the reset command would operate in my current branch space, and did not understand that the branch param is required. (Running the command without a branch name threw no error or warning.) I find GIT to be more complicated than I need, and often end up in rabbit holes like this. (Perforce is so much more straightforward.) – Jonesome Reinstate Monica Mar 22 '22 at 19:16
  • 1
    The default is HEAD, when not provided. [Documentation here.](https://git-scm.com/docs/git-reset) Since you were already up to date with your own branch, it just did nothing. ;) – TTT Mar 22 '22 at 19:28
  • @TTT Thank you. Using GIT requires more knowledge than I have (or want). I appreciate your detailed engagement. (I do not use branches in GIT, and am not familiar with the nomenclature on the link. The suggestion to use the {u} parameter was very helpful, and perfect for me because I am always in the same branch.) – Jonesome Reinstate Monica Mar 22 '22 at 23:22

1 Answers1

-2

The answer is: The branch name must be used in the reset command.

The following command sequence works:

git reset --hard @{u}
git clean -fd
git pull
Jonesome Reinstate Monica
  • 6,618
  • 11
  • 65
  • 112
  • @matt No, actually it does not. You are assuming a level of GIT knowledge on my part that I do not have. I do not use branches in GIT, and am not familiar with the nomenclature on the link. The suggestion to use the {u} parameter was very helpful, and perfect for me because I am always in the same branch. If the link had been able to help me, I would not have posted this thread. (Please have consideration for those who have to use a tool, GIT, but neither know it well nor like it. We are doing our best!) – Jonesome Reinstate Monica Mar 22 '22 at 23:20
  • OK, sorry, no offence was intended. I've removed the comment. If you have a genuine interest in improving your mental image of what Git is and does, I've written a helpful and engaging intro: https://www.biteinteractive.com/picturing-git-conceptions-and-misconceptions/ – matt Mar 23 '22 at 00:40
  • And here's an answer of mine that might help you picture what `reset` does: https://stackoverflow.com/questions/3528245/whats-the-difference-between-git-reset-mixed-soft-and-hard/59675191?r=SearchResults&s=1|38.4548#59675191 – matt Mar 23 '22 at 00:43
  • @matt Thank you! The essential problem for people like me is that we do not need the distributed features of GIT. That feature set adds a _lot_ of complexity to the mental model. So here I am, with a comprehensive mental model of server based VCS, and I am always forced to learn more (that I neither want nor need) about GIT just to do simple operations. (My projects are just two or three people, single branch, github as server.) I hate GIT because there are things I need (and have had for decades) that GIT can't do (like revision numbering of files), and it has a cognitive load I don't need. – Jonesome Reinstate Monica Mar 23 '22 at 05:31
  • You can't really (practically) *not* use branches in Git. (It's theoretically possible, it's just too difficult for humans, and I say that knowing just how bad Git is for humans as it is.) What you can do—and are doing, in this case—is just use *one* branch, and one remote-tracking name. – torek Mar 23 '22 at 13:56
  • @torek Correct. We work in a single branch and do not create new branches for features. I am fine with "strong branching" (what is done in old school Perforce style development). I just find that "light branching" as has become common is simply a hassle my teams don't need. There is more to life than integrating/merging. – Jonesome Reinstate Monica Mar 23 '22 at 18:19