search

nRF24 / RF24Log

A nice logging library for Arduino devices
GNU General Public License v2.0
7 stars 4 forks source link

Weird history shown by gitk #3

Closed wmarkow closed 3 years ago

wmarkow commented 3 years ago

After accepting PR #1 I see a weird history shown by gitk. Just see weird_gitk_history

I have marked the weird in a red ellipse. According to the tree it looks like remotes/nRF24/main is behind my dev branch, however I have compared the files on both branches and they are the same.

Or take a look at my merge of PR from @2bndy5 - see it marked in green ellipse. From that tree I see that the branch has been really merged to my dev.

Do you have an explanation of this? Or maybe PR from my dev branch was merged with some special options? Or gitk has some issues with showing the history tree?

2bndy5 commented 3 years ago

never used gitk unless you're talking about GitKraken (which I sometimes use).

when I merged #1 I squashed the commits into 1 (using the GitHub mobile app), so maybe that is screwing up the history with your dev branch.

2bndy5 commented 3 years ago

maybe try starting a new branch based on upstream/main, then move your stash to the new branch? I don't usually use git stash

wmarkow commented 3 years ago

never used gitk unless you're talking about GitKraken

I don't have GitKraken in mind. I really mind gitk (this is a command line tool) which comes together with git native (Windows in my case) installation.

when I merged #1 I squashed the commits into 1 (using the GitHub mobile app), so maybe that is screwing up the history with your dev branch.

That may be. When I merged your PR I didn't use any squash option.

maybe try starting a new branch based on upstream/main, then move your stash to the new branch?

Yes, this is what I was going to do but then I found the weird history. I will start a new branch from upstream/main

2bndy5 commented 3 years ago

I only squashed the commits from #1 because that's what we normally do for PRs into RF24 lib. It doesn't usually cause a problem since I tend to use 1 branch per new feature/revision, then delete said branch after the PR is merged.

I actually foresee this same problem when the RF24/rp2xxx (the WIP support for the Pico SDK) branch is ready and the overload-begin branch has already been squashed into main

wmarkow commented 3 years ago

Ok.

Now I'm sure that I have chosen a Create a merge commit option when accepting your PR.

More info here: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request

It also says:

Pull requests are merged using the --no-ff option, except for pull requests with squashed or rebased commits, which are merged using the fast-forward option.

In my merge a --no-ff option has been used and the tree history looks nicer - at least for me.

wmarkow commented 3 years ago

I'm closing the issue. It is just the way how a PR has been merged and probably also the way how gitk shows merges.

@2bndy5 thanks for your help.

2bndy5 commented 3 years ago

probably also the way how gitk shows merges.

yea squashed commits may be harder to emphasize in history