She’s modest too!

And successful Hollywood film producer – props on getting into the stakeholder end of the business so early in your career!

She probably is, just anonymous. It would be crazy to expect anyone to post on lemmy under their real name.

I think he was a senior contributor for the underground cracker mag 1600 back in the late 80s.

They called em zines.

You didn’t hear of wayland.social?

On nvidia, it definitely feels much smoother, but some GPU accelerated programs like games become flickery, i think it’s an xwayland issue

Depends on a few things with your setup: age of your GPU, the resolution/refresh rate of your monitor. I think even the choice of DP/HDMI can have an impact too

deleted by creator

If you try to pull someone else’s rebased / history rewritten branch, your git will tell you that it’s rejected. You can completely avoid this by merging instead of rewriting history.

@agressivelyPassive @technom That’s a self-fulfilling prophecy, IMO. Well-structured commit histories with clear descriptions can be a godsend for spelunking through old code and trying to work out why a change was made. That is the actual point, after all - the Linux kernel project, which is what git was originally built to manage, is fastidious about this. Most projects don’t need that level of hygiene, but they can still benefit from taking lessons from it.

To that end, sure, git can be arcane at the best of times and a lot of the tools aren’t strictly necessary, but they’re very useful for managing that history.

We use history and blame a lot

Only users who don’t know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.

Because when debugging, you typically don’t care about the details of wip, some more stuff, Merge remote-tracking branch 'origin/master', almost working, Merge remote-tracking branch 'origin/master', fix some tests etc. and would rather follow logical steps being taken in order with descriptive messages such as component: refactor xyz in preparation for feature, component: add do_foo(), component: implement feature using do_foo() etc.

You can have both. I’ll get to that later. But first, let me explain why edited history is useful.

Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you’re a reviewer, you also wouldn’t want to waste time reviewing someone else’s mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.

Now the part about having both - the unedited and carefully crafted history. Rebasing doesn’t erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.

Removed by mod

Heaven forbid my teammates read any documentation or make any attempt to understand the tooling necessary to do their job.

That being said, I taught my dumbass git-illiterate team members a rebase workflow, with the help of the git UI in Pycharm. Haven’t had any issues with merge conflicts yet, but that might just be because they’re too scared to ask me for help any more

There’s 102 people mentioned in that commit and two of them happen to meet in the comments of a meme thread on Lemmy of all places. I love the Internet.

They were mentioned because a file they are the code owner of was modified in the PR.

The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).

If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.

Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.

In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.

Tbh, we just don’t hire people if they can’t operate git.

Pretty sure Radha Mitchell only does front end development.

Yeah, I had a feeling that was not the best way to put it but I was in a hurry :)

Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.

why would rebasing a feature branch change main?

the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.

The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @[email protected] meant.

I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.

Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).

What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.

Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.

When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.

What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.

The commits aren’t duplicated, but applied to the main branch. Since git has commit ids, they won’t be re-rebased either.

Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.

Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).

Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.

It’s really hard to create an analogy for this.

It inserts the master changes before the task branch ones.

Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.

You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up

The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.

Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.

The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.

Another advice …quick way to squash all your commits

in your IDE select the commits you want to squash. Then rightclick. Then “squash”. All done.

Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.

Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.

100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use reflog, cos…well, then you done messed up now son… (but even then hope lives on!)

Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.

Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.

Your notation does not make sense. You’re representing a multi-dimensional thing in one dimension. Of course it’s a mess if you do that.

Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is “branched off” from some commit M. D’s and A’s parent would be M (though there could be any amount of commits between A and M). Since A is “on the main branch”, you can conclude that D is part of a “patch branch”. It’s quite clear if you don’t omit this fact.

I also don’t understand why your example would have multiple merges.

Here’s my example of a main branch with a patch branch; in 2D because merges can’t properly be represented in one dimension:

M - A - B - C - C'
  \           /
    D - E - F

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.

If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They’re much faster too.