2

I have a directory on a debian server. I created a git repo I would like to clone in. This git repo is a clean version of this directory which not include all non-necesserary files to store on my repo.

So, I would like to clone files into this directory, BUT I don't want to erase files in common without a kind of "merge conflict" if needed.

I saw this solution on this post : 

git init
git remote add origin PATH/TO/REPO
git fetch
git reset origin/master  # this is required if files in the non-empty directory are in the repo
git checkout -t origin/master

But what I'm asking is, would this just replace existing files (On server) with the version of those files from my repo ? Or will it shows to me if there are conflicts ?

Thanks !

Ritooon
  • 155
  • 12
  • Don't do this ! save your work before git reset origin/master shoud be ok – jo_ May 23 '18 at 13:03
  • What do you mean ? – Ritooon May 23 '18 at 13:17
  • git reset origin/master shoud be ok (all your updates will appear in git status) but your work is not saved. I suggest that you create a branch and do a git status ; git add ; git commit ; Once you have your work saved in a branch look for things like git merge – jo_ May 23 '18 at 13:26
  • Good solution, thank you ! – Ritooon May 24 '18 at 08:03

1 Answers1

1

That procedure is partially, but not entirely, correct for your use case. Consider this approach:

# ... in the local directory
git init

You mention that your local has files that shouldnt' be in the repo - and presumably aren't in the repo yet. So create a .gitignore file that lists those files. Then

git add .
git commit

Now you have a local commit with your current worktree state.

A <--(master)

Then

git remote add origin URL/OF/REMOTE/REPO

(Note that URL/OF/REMOTE/REPO could be PATH/TO/REPO, if REPO is on the local filesystem; but even then I generally use a file:// URL.)

git fetch

Now you have access to the repo's history. Maybe it looks like

x -- x -- x -- O <--(origin/master)

A <--(master)

Next step is to merge the changes from the remote.

git merge --allow-unrelated-histories origin/master

For files only on your local copy... well, you put them in .gitignore so they should remain untracked.

For files only on the repo copy, they'll be added to the merge result.

For files identical in both locations, the merge will auto-resolve.

For anything else, you'll get a standard merge conflict.

Once you've resolved the conflicts, you should have a working tree state like what you want. Just so we have a clear picture, let's look at what happens if you complete the merge.

git add .
git commit

Now you have

x -- x -- x -- O <--(origin/master)
                \
            A -- M <--(master)

You could push that, so that master shows updates to match your local state (excluding the files you .gitignored). That will also make commit A part of the origin history, which you might not want. So another option from here would be

git reset --soft origin/master

Your local change will still be in the index and worktree, but the commit graph will now look like

x -- x -- x -- O <--(origin/master)(master)

A -- M

So now you can re-commit. A and M will eventually drop from your local repo due to gc, and will never be made part of the remote history; but by re-committing you do add the changes to the remote, to sync it with your local directory (other than the ignored files).

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52