Maintaining my own branch with git

[Andrea Venturoli]

Hello.

I know tons of messages have been written on the subject: I read them
all, along with the Git Primer docs, but somehow I think I'm not doing
it right and I cannot understand what I'm doing wrong.

I need to have some patches applied to both src and ports and distribute
them to several machines.
So I have my own git server and I want to keep my own FreeBSD branches.

I cloned FreeBSD's git repository and pushed into my server; then I
created my own branches.

% git remote
freebsd
netfence
% git status
On branch main
Your branch is up to date with 'netfence/main'.
nothing to commit, working tree clean

So I'm on my own branch with my own differences wrt original freebsd's.

Now I issue:
1) git pull freebsd
2) git rebase freebsd/main
3) git push netfence --force



1) This does not merge, as I'm not on a "freebsd" branch. Ok, I think.

2) Here I have the first problem: rebasing is getting slower and slower.
It almost looks like it's every time replaying history from the first
day I started this to the current status. AFAICT, if I rebase now,
everything from the past should be accounted for and forgotten. If I
rebase tomorrow, I would expect only the new upstream commits to be
taken into acount, but instead there are thousands of them.

3) Pushing without "--force" is not allowed as "the tip of your current
branch is behind its remote counterpart. Integrate the remote changes
(e.g. hint: 'git pull ...') before pushing again."


What's wrong with the above approach?

bye & Thanks
av.

[Steve O'Hara-Smith]

On Wed, 28 Apr 2021 13:49:23 +0200

Post by Andrea Venturoli
Hello.
I know tons of messages have been written on the subject: I read them
all, along with the Git Primer docs, but somehow I think I'm not doing
it right and I cannot understand what I'm doing wrong.
I need to have some patches applied to both src and ports and distribute
them to several machines.
So I have my own git server and I want to keep my own FreeBSD branches.
I cloned FreeBSD's git repository and pushed into my server; then I
created my own branches.

OK let's stop there. I would not do that.

I would do this:

1: Clone the FreeBSD repository into my work area
2: Create my branch(es) off freebsd/main like this:
git checkout main
git checkout -b myworkingbranch
3: Apply my patches in myworkingbranch and commit them to that branch
NB: git commit --amend and git rebase -i are your dear friends for
keeping a clean history in your branch.
4: Push myworkingbranch to your server whenever you're done with a commit
Don't push the freebsd branches ever
5: Update main with git pull (while freebsd/main is checked out)
NB: This will *always* be fast forward since you *never* commit to it
6: Update myworkingbranch with:
git rebase main
NB: This will stash your changes, bring in the updates and then reapply
your changes, requiring you to sort out any conflicts that come up.
7: After this rebase you will need to force push myworkingbranch to
your server

Branches in git are cheap, easy and throwaway things make branches
at the drop of a hat to keep separate threads of work separate, make
integration branches to merge them into and test branches to load with
throwaway debug and never think twice about doing it.

[Steve O'Hara-Smith]

On Wed, 28 Apr 2021 13:16:29 +0100

Post by Steve O'Hara-Smith
5: Update main with git pull (while freebsd/main is checked out)

UGH sorry (while main is checked out).

[Andrea Venturoli]

Post by Steve O'Hara-Smith

Post by Andrea Venturoli
I cloned FreeBSD's git repository and pushed into my server; then I
created my own branches.

OK let's stop there. I would not do that.

Ok, I probably worded that wrong: I don't have all of "freebsd" branches
on my git server.

Post by Steve O'Hara-Smith
5: Update main with git pull (while freebsd/main is checked out)
NB: This will *always* be fast forward since you *never* commit to it

I think here's the problem: in my situation I somehow fail to update
freebsd's branches.
I'll try to start over and check better.



bye & Thanks
av.

[Andrea Venturoli]

Post by Steve O'Hara-Smith
git rebase main
NB: This will stash your changes, bring in the updates and then reapply
your changes, requiring you to sort out any conflicts that come up.
7: After this rebase you will need to force push myworkingbranch to
your server
% git push
To ssh://...
! [rejected] netfence_main -> netfence_main (non-fast-forward)
error: failed to push some refs to 'ssh://...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Should I pull or push with "-f"?



bye & Thanks
av.

[Steve O'Hara-Smith]

On Thu, 29 Apr 2021 14:10:55 +0200

Post by Andrea Venturoli

Post by Steve O'Hara-Smith
git rebase main
NB: This will stash your changes, bring in the updates and then
reapply your changes, requiring you to sort out any conflicts that come
up. 7: After this rebase you will need to force push myworkingbranch to
your server
% git push
To ssh://...
! [rejected] netfence_main -> netfence_main
(non-fast-forward) error: failed to push some refs to 'ssh://...'
hint: Updates were rejected because the tip of your current branch is
behind hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Should I pull or push with "-f"?

Yes you should. What is happening is that when you rebase against
main you rewrite the history of your changes (they are based against a
different commit to those on your server) so you have to use force to get
the server to accept the rewrite of history.

[Steve O'Hara-Smith]

On Thu, 29 Apr 2021 14:10:55 +0200

Post by Andrea Venturoli
Should I pull or push with "-f"?

Just in case I wasn't totally clear you should push -f to force the
changes you want into place. If the version on the server was the source of
truth at this point you would want to pull - git of course doesn't know
which is the source of truth so just says do one or the other.