@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.

@sir
>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...

@Wolf480pl ¯\_(ツ)_/¯

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).

I wonder...
does anyone make random commits on master that should be logically after a feature branch?

@Wolf480pl @sir Yes, all the time. If it's not a major project with several developers, I only use branches if I'm working on something that I may not ever want to merge back into master.

@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.

@sir
>git checkout feature-2
>git rebase master

won't that also pick the first feature-1 commit onto master?

@sir
"It turns out feature-2 doesn't depend on any of the changes in feature-1"

But they share the commit in the middle of the graph. If I put names on them,

o1--o2--o3--o4--> master
\--o5--o6--> feature-1
\--o7--> feature-2

The commit o5 is part of the history of feature-2, and it's shared with feature-1, so I would say feature-2 is based on the changes in feature-1.

Also, in the end you present the rebase, and I interpret it like

o1--o2--o3--o4--> master
| \--o7--> feature-2
\--o5--o6--> feature-1

So now o5 is not in the history of feature-2. Is that correct? I don't understand very well how o5 got lost.

P. S.: It's an awesome guide, incredibly instructive, and that's the part I love most of your work. Thank you very much.

@josealberto4444

>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?

@sir
Ah, OK, now I understand your point. And how does git know that? Because git knows it's working with graphs and this is an equivalent way to see that history:

o1--o2--o3--o4--> master
          \--o5--o7--> feature-2
                 \--o6--> feature-1

I mean, what is the algorithm? Picking all the commits from master and also all the commits in feature-1 that aren't shared with any other branch?

@josealberto4444 I think I'll have to refer you to the git-rebase man page before I go summarizing it poorly in a toot

@sir
I've been taking a look at the man page and I think I was right. What I called o5 is not lost when you do that command. Instead, for your purpose, you should use git rebase --onto master feature-1 feature-2 (the last word can be omitted if you have already checked out at feature-2, but it is useful to understand).

You can use a git repository ready to do the rebase command to confirm all this in https://git.sr.ht/~josealberto4444/test

Anyway, I learnt a lot reading the man page. =)

@josealberto4444 thanks for clarifying. Maybe you can distill this into a patch to git-rebase.io?

@sir
Is it possible to sent patches to that page? I'd like to send that change myself, if you don't mind.
@sir
I have to go right now, but I will do it tonight or tomorrow. =)
@sir
~sircmpwn/public-inbox@lists.sr.ht, the address written in the readme.

@josealberto4444 oh, your email is encoded wrong. Is it not UTF-8?

@sir
I can open it with my email client and it says it's encoded in utf-8:
From: =?UTF-8?q?Jos=C3=A9=20Alberto=20Orejuela=20Garc=C3=ADa

(That's the only place where there are non-ASCII characters, but it's my name, I cannot avoid that) XD

I checked the codes (corresponding to é and í) and they are right. I don't understand what's the problem.

@josealberto4444 okay, likely fix being deployed now, try again in ~10 mins

@sir
You mean my fix is being deployed and that I can check the page or that you fixed the issue with the characters and I should resend the email?

@josealberto4444 can you email me directly, sir@cmpwn.com? 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

Show more
ugh. constantly forget what "bonk" and "tonk" do

@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 Nice site! It'll be extremely handy if I ever need to explain git rebase to a friend.
Thanks a lot!

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!