[Blackthorn]

I agree with you in spirit (people need to learn their tools more) but your examples...not so much. Merging main into the feature branch was the original intent on how to do it. PRs are sent the way you describe because GitHub literally offers the maintainer a squash option and it's a lot easier to review a pull request when history is unedited.

[aulin]

PR should be sent to review in a state that author considers ready to merge. Assuming it will be squashed and taking that as a reason for submitting dirty history is just sloppy and unrespectful.

Merging is for keeping track of a group of commits that has been taken from a feature branch and included in the mainline. Why would you clutter the feature branch with periodic main merges when you can cleanly rebase it and keep it tidy?

[Blackthorn]

> Merging is for keeping track of a group of commits that has been taken from a feature branch and included in the mainline.

Merging is for bringing a group of commits from branch A into branch B. It is, quite literally, the original way to perform this operation. It's not "clutter", it's a correct picture of how the code was developed.

[aulin]

It's clutter because it adds no information value on a short lived branch. If it's a branch that periodically syncs with another it's ok, if you're just basing off current master for a feature branch rebase is the way to go.

[Blackthorn]

I've developed branches against a moving target all the time where the moving target introduced a problem in my code that wouldn't have been found by a simple merge conflict resolution. It's much much easier to find the source of the problem when you have the real history (a merge) instead of a rewritten history (a rebase).

[aulin]

You are right, makes sense.

[7bit]

> it's a lot easier to review a pull request when history is unedited.

Ist it really? If you would See my uncleaned history, it would take you days to understand what I was even trying to do.

Your statement seems based on the assumption that someone knows how to achieve a particular thing right from the start. But that isn't always the case and there might be a lot of different approaches until the correct or best one is found.

Do you really want to review dead code that's somewhere in the commits of a feature branch?

[Blackthorn]

Yes, I'd much rather review a PR with the full unedited history, not the history that the submitter thinks is good or pretty. You often don't know what information you need until you need it. I'll take the entire, dirty history, and once I'm done with it it can be squashed.

[CRConrad]

> PRs are sent the way you describe because GitHub...

Oh, and here I though this discussion was about git. But you're talking GitHub.

[Blackthorn]

They used the phrase pull request, which means GitHub, because git does not have a concept of "pull request".

[keybored]

To request a pull has been a term in git(1) since 2005.

https://opensource.stackexchange.com/a/380/30121

(Is this pedantic? I guess in a lot of contexts. But you talked about the original, intended way to do it. So it seems on-topic here.)

[Blackthorn]

Yes, pull is old. Pull request, which the original poster was explicitly discussing, is a GitHub thing.

[keybored]

I was talking about “pull request”. So is the link I used.

[Blackthorn]

Right. It discussed the command "git request-pull". I do not believe the phrase "pull request" existed until GitHub popularized it.

[keybored]

> Merging main into the feature branch was the original intent on how to do it.

Based on?

[Blackthorn]

The merge script existed as far back as git 0.5. Rebase came later.

[keybored]

Linus Torvalds needs the merge operation as an integrator.

Considering the email workflow of the kernel I can’t really make sense of “intended way to do it”. For individual commits people send out patches. I’ve never seen an email thread where some merge topology is recorded: it’s just a list of patches. A straight line.

I’m pretty sure that people used patch queues before Git (and even now with quilt). Restacking a bunch of commits on top of the mainline is the same operation as a rebase.

I’ve certainly seen Linus get mad at another maintainer for allowing a back-merge into his history (merge main back into feature branch).