Odtnhj

1. (in some working directory A) I did some local changes and performed add and commit


2. (in some working directory B) I got a patch for these local changes (in directory A) and applied it in directory B. I performed add/commit/push in directory B.


3. (in the working directory A) I performed a git pull and expected my local commit to disappear. It did not.


4. (in the working directory A) I performed a git reset HEAD~. git diff shows the changes which are already pushed earlier. (forget about this point -- this was my attempt to solve this problem)

Obviously I did something wrong. what is it?

This is what I think you described:
On machine 1 make commit X
On machine 2 apply a patch which does the same thing, and create commit X'
Push commit X'

On machine 1 pull commit X'
Machine 1 now has 2 commits: X and X'

You reset HEAD~ on machine 1, removing commit X', and leaving commit X.

The pull is a fetch followed by a merge.My understanding is that in a merge git can recognize identical changes.

Still, it might be interesting to do the pull again, and run
git show HEAD
to see what was committed.
Perhaps it's a merge commit with very little content?
Someone with more plumbing knowledge could answer that better that I can.
It is likely to depend on what you merge settings are also. Merge, rebase?

There are many ways to look at how you might coordinate the content across two machines' working directories.

The most basic is: if you committed changes on machine A, and want them on machine B, you can fetch them from A to B so that A and B will have the patch via the same commit. Sometimes that's not a suitable answer, and so other ways are possible. But which one makes sense for what you're doing depends on what you're doing, and we don't know enough to necessarily address that yet.

So we can follow up on that if it makes sense, but let's start by clarifying a possible conceptual misunderstanding:

(in the working directory A) I performed a git pull and expected my local commit to disappear. It did not.

My question would be, why is that the expected behavior? In general, you don't want your local changes to disappear when you pull in remote changes; instead you want to combine them.

Now, in the specific case where the local changes and the remote changes are identical, you might indeed want the local changes to go away, and if you rebase the local changes onto the newly-fetched remote changes then that is what should happen.

git pull --rebase

Now if, in the process of rebasing your local changes onto the fetched changes, git finds that a local commit's patch is exactly the same as the patch for one of the fetched commits, the local commit will be discarded.

Perhaps you expected that behavior because in the past you've used repos configured to rebase on pull by default? Be aware that auto-rebasing is documented as a "potentially dangerous" feature, so you might want to consider if it's really the best default; but if it is the default you want, look up pull.rebase in the git config docs: https://git-scm.com/docs/git-config

You can do it with a git pull, but I would use rsync

cd directory_A; rsync -mauvPAX directory_B/ .

This would efficiently duplicate the content of directory_B into directory_A and preserve any files in directory_A that are missing from directory_B.

If you want to scrub any additional files from directory_A that aren't in directory_B then include the --delete flag.