Just out of curiosity, why should you not rebase against master? I thought it was good practice to rebase often, and never merge master into your branch
or is this specific to atlassian bamboo? plz help
-
-
Bram Gotink Retweeted Cold Stone Steve Austin
He's talking about rebasing the master branch itself, not rebasing another branch onto master. Rebasing master means you're changing the history of master, breaking every clone or fork. They didn't actually rebase by the way:https://twitter.com/davidreghay/status/1120176026603139075?s=19 …
Bram Gotink added,
2 replies 0 retweets 4 likes -
Replying to @bram_gotink @tobequitefrank1 and
That's actually still a history rewrite though. The commit message is part of the commit object, which is in turn hashed to become the commit id, which must be referenced by all child commits... It didn't use the "rebase" tool/command, but the same effect was achieved.
2 replies 0 retweets 3 likes -
Replying to @widdr @bram_gotink and
It still creates new commits and hashes but it's not technically the same as rebasing, which "flattens" history and requires actually replaying changes. This preserves history more faithfully, for example by leaving the branching history intact
1 reply 0 retweets 4 likes -
Replying to @davidreghay @bram_gotink and
You can use rebase without actually inserting, reordering, or removing commits (like rebase -i to do rewording). When you do this it's the same as the other thing and doesn't create any new tree references, and thus requires no replays :) IDEA has a "reword" UI element for this.
1 reply 0 retweets 0 likes -
Replying to @widdr @davidreghay and
But yeah, again, it's just just multiple different tools and methods to do the same thing, none of which affect the tree snapshots, only the commit graph.
1 reply 0 retweets 0 likes -
Replying to @widdr @bram_gotink and
rebase _always_ replays commits. when your history is complex this can lead to weird conflicts even when all you're trying to do is "reword" a single commit. that's even if you use the `-p` option for preserving merge commits.
2 replies 0 retweets 1 like -
Replying to @davidreghay @widdr and
also, the commit graph is what i was talking about. if you rebase without making any substantive changes (i.e. leave in all the commits as "pick" or "reword" whatever) you will end up with a flattened graph. the `-p` option can alleviate this but you can still get conflicts
1 reply 0 retweets 2 likes -
Replying to @davidreghay @widdr and
we definitely considered rebasing as an option but ultimately this was a case where `filter-branch` a) made sense and b) avoided conflicts that were specifically being caused by attempting to rebase
1 reply 0 retweets 1 like -
Replying to @davidreghay @widdr and
just by the way i am a big fan of rebasing and all the control it offers
2 replies 0 retweets 0 likes
aka more rope than anybody could possibly need to hang themselves
-
-
Replying to @chaosprime @davidreghay and
With enough rope, you can land on the ground and run away!
1 reply 0 retweets 3 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.