search

AllStarLink / app_rpt

Refactoring and upgrade of AllStarLink's app_rpt, etc.
3 stars 2 forks source link

Usb select #298

Closed tsawyer closed 3 months ago

tsawyer commented 3 months ago

I think this brings one in one earlier commit that has been superseded.

InterLinked1 commented 3 months ago

Can you clarify your comment? "one in one"?

I'm a little confused... this seems to be exactly the same as 35953672dbd6960dad7d7ae2316437fa1bcfac61, which was already merged?

I'm also seeing this merge commit here: https://github.com/AllStarLink/app_rpt/commit/cdd760ad9acd8346a09ba01a85ec3cb4638f2446

Somehow the history has gotten messed up I think... please do not merge merge commits in the tree. You should always pull upstream changes before pushing your own. It's not clear why it shows those changes again, but I am going to bed now so I will have to analyze more tomorrow.

tsawyer commented 3 months ago

Look at what @encbar5 posted on slack. Looks like there is one additional commit comparing master to usb_select.

InterLinked1 commented 3 months ago

Look at what @encbar5 posted on slack. Looks like there is one additional commit comparing master to usb_select.

I think that is likely due to commit squashing. The 3 commits on the branch were turned into 1 commit.

The code seems to be in the tree currently. This might be due to your merge commit, not entirely sure. At this point, the branch history on the original branch is not relevant and should be discarded,.

tsawyer commented 3 months ago

At this point, the branch history on the original branch is not relevant and should be discarded,.

@encbar5 Could you explain that further? This seems to keep happening for some reason. Any hints as to how to prevent it and recovery as needed?

InterLinked1 commented 3 months ago

At this point, the branch history on the original branch is not relevant and should be discarded,.

@encbar5 Could you explain that further? This seems to keep happening for some reason. Any hints as to how to prevent it and recovery as needed?

It isn't a real issue that you need to worry about at all. Just delete the branch, it's dead anyways.

For a more detailed answer, see: https://stackoverflow.com/questions/63862271/github-still-shows-differences-between-branches-after-sucessfull-merge

I think if people forced pushed commits instead of pushing additional commits that need to be squashed, it might not happen, but either way it isn't a big deal.

encbar5 commented 3 months ago

At this point, the branch history on the original branch is not relevant and should be discarded,.

@encbar5 Could you explain that further? This seems to keep happening for some reason. Any hints as to how to prevent it and recovery as needed?

@tsawyer The article that InterLinked1 pasted above is basically saying what I was pointing out - that the calculation GitHub uses only cares about three commits - the 2 branch heads and the merge base.

I did not check the actual file diffs, but assuming they are the same, there is no recovery needed, just delete the branch.

As for prevention - this comes down to development practices and which merge strategies you want to allow for the project. You can read up on Merge Methods Also, there are Branch Protection Settings

One thing you could do is whenever a branch is merged, no matter the merge strategy, make sure to delete the branch. Then if you need to make any changes, create a new branch off of main and use that.

tsawyer commented 3 months ago

Closing and will delete branch.