@sir This is a fantastic site and a great walkthrough. I'll be sure to bookmark this for reference
@sir Great guide, thanks!
The sentence in the very end, "when git doesn't realize that a commit it's pulled from the "other" branch is an updated version of the commit it conflicts with on "our" branch.", seems to have a typo, the last "it"? s/it/that?
Also perhaps it's better to show the branch graphs in the rebase section as SVGs or something?
@YaLTeR fixed that phrasing to make it more clear, thanks! I chose not to use SVGs because I want to encourage people to use the git command line, and I wanted to use the dataviz which the command line shows you to help familiarize people with it.
>git checkout master
>git rebase squash
hmm, I'd rather
git rebase master
git checkout master
git merge --ff-only squash
If squash is fast-forward of master, it gives the same result, but if it's not (i.e. there are commits in master that are not in squash), it'll put things in opposite order...
Well, my way assumes you don't have WIP commits on master, so I guess the git-rebase.io way is safer to recommend to newbies...
Instead of doing what's safe I just don't make mistakes 😉
@sir me too :P
And I know I never have WIP stuff on master, so I rebase feature branches onto it and then merge back (which is fast-forward so no merge commit appears).
does anyone make random commits on master that should be logically after a feature branch?
@Wolf480pl I don't buy the cargo culting around feature branches. Not every feature has to be on a feature branch. I use feature branches sometimes (particularly when I have to use Github), but I also work off of master all the time and just rebase madly to keep different features in order. Then I use commands like git send-email -2 HEAD^^ to send slices of my history off for review
@sir oh, ok.
(I hope) I'm not cargo-culting feature branches either.
I personaly tend to create shitloads of branches, and reserve master for simple bugfixes that will be merged into upstream quickly.
But your workflow seems reasonable too. I'll keep in mind this is another viable option.
>git checkout feature-2
>git rebase master
won't that also pick the first feature-1 commit onto master?
>But they share the commit in the middle of the graph. If I put names on them
They share the commit, but that doesn't mean it depends on it. Say that o5 introduces function foobar, o6 uses function foobar to do some task, and o7 introduces foobaz. But o7 doesn't use foobar, so it doesn't need o5 to be correct. The rebase rearranges history to reflect that, *re-basing* feature-2 off of master instead of feature-1. If the foobaz introduced by o7 used foobar, then foobar should be *based* on feature-1 because it requires changes introduced by feature-1. Does that make more sense?
@josealberto4444 I think I'll have to refer you to the git-rebase man page before I go summarizing it poorly in a toot
@josealberto4444 thanks for clarifying. Maybe you can distill this into a patch to git-rebase.io?
@josealberto4444 hmm, where'd you send it to?
@josealberto4444 oh, your email is encoded wrong. Is it not UTF-8?
@josealberto4444 okay, likely fix being deployed now, try again in ~10 mins
@josealberto4444 the latter
@josealberto4444 can you email me directly, firstname.lastname@example.org? Who's your MTA and MUA?
@josealberto4444 thanks for the email, can you also git send-email me the patch directly?
@josealberto4444 thanks, I'll use these to work the problem then apply them manually. Much appreciated
@sir One more nitpick:
>let's do a "soft reset" by running git reset HEAD^
Technically that's a mixed reset. A soft reset would leave the index intact.
Though I'm not sure if changing it to say "mixed reset" would be good... a footnote maybe?
@Wolf480pl would accept a patch... I agree it's confusing but hard to fix
@sir just sent one https://lists.sr.ht/~sircmpwn/public-inbox/patches/5511
@sir Nice site! It'll be extremely handy if I ever need to explain git rebase to a friend.
Thanks a lot!
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.