Is git rebase wrong / right in this case (syncing git master with a SourceSafe Repository)

Question

I am working on some git-VSS interop and the way I have approached syncing my git master with SS is

1. git checkout vss_branch

2. ss get . -W -R -Q -Y$SSNAME

3. git checkout master

4. git rebase vss_branch master

And I am not sure about the last part, the way I read it, that contradicts the advice mentioned here

The basic logic here is that the "vss_branch" is always just a straight up copy of whatever is currently in VSS, "ss get . -W -R -Q -Y$SSNAME" gets everything out of source safe as a write-able copy.

I treat master as "my build branch" so I "git merge" my dev branch onto that when I feel the code is "build ready"

However after reading this advice I feel I am doing it the wrong way round.

The reason I currently prefer "git rebase" instead of "git merge" is git merge threw up a load of conflicts whereas the rebase does not..but this seems very much like a "that one seems to work, so I will use that one" approach. I am worried that in reality git rebase would lead to repeating the same merge conflict over and over if I change a section of code repeatedly through several commits and some one else makes a small change to the same section of code.

I appreciate any help to get/keep me on the right track

Answer 1

I came across a very interesting feature in git

git branch --set-upstream-to <branch/remote>

this allows me to

git branch --set-upstream-to vss_branch

This creates the relationship I actually want. Before I was certainly doing it wrong because vss_branch was a branch from master and the rebases were getting painful (more changes = more time).

This allows me to use git pull, git push with the vss_branch.

"git pull" with the default settings simply pulls vss_branch onto master.

But because "master" and "vss_branch" don't share the same name I have to use

"git push . HEAD:vss_branch"

This solves the problem however if you find yourself doing this, your doing something very odd.

A better solution, given that git is distributed, might be to create another folder on your machine that you actually set as "origin"

For example:

git remote add <NAME> <PATH>

Would add a new remote and you could

git remote add origin /c/path/to/alternate/folder

This means you need two folders, but if one of those is on say an external hard drive then you are actually increasing your data protection.

At which point you could use git push and pull and you are then treating the other folder as your "upstream" which is what I was going for here and its why I am currently happy with the "set-upstream" option

It works well for me, which in reality means what I wanted was "merge" as that's what the default "pull" does. But I cant say this is the correct "answer" as this is more what fits my workflow and current opinion on "what works"