4 ms·

It makes a merge commit which is usually unnecessary. If there were no conflicts, there's no need to have a commit fixing them up. If you just want to know who

It makes a merge commit which is usually unnecessary. If there were no conflicts, there's no need to have a commit fixing them up. If you just want to know who integrated the patch, git stores the author and committer fields separately. Most git users in touch with the design goals of git use branches sparingly, either for long lived projects (with hundreds of commits) or as a sandbox in which work is frequently rebased into a concise history of a few patches, which are usually integrated upstream without a merge. Merges are also used to merge disparate trees, like when Linus merges in trees from around the kernel development scene (since each kernel subsystem maintains their kernel tree as almost independent projects, using merge makes sense to integrate the foreign histories into the upstream kernel). The Linux kernel approach probably requires a full-length article to fully explain, though, so don't read too much into that.

Steltek 8y ago
I would argue the "design goals" of git have evolved far past the kernel, which is a very unique and special project. These new patterns don't seem to invalidate how the kernel uses git and they offer a lot of ergonomics in a Github-styled atmosphere. Are the only downsides that 1) users don't understand how kernel development is done, which extends far beyond source control; and 2) a merge commit is left as a marker?
- Sir_Cmpwn 8y ago
  It's not really about the kernel, the kernel is just where the world's most talented git experts work. The downsides include the creation of a merge commit, sure, but also the fact that it's used as a crutch by users who would rather not strive to understand how git works.
WorldMaker 8y ago
Git uses a DAG for multiple reasons. Avoiding merge commits is ignoring most of the power of having a DAG for data structure. The Linux Kernel repo itself has some fascinating examples of DAG usage, including some of the most well known "octopus" merges with many more than two merge parents.
- Sir_Cmpwn 8y ago
  I don't think octopus merges or most merges in the Linux kernel are related to the point the article is making, or the workflow GitHub encourages. I'm not saying you should never merge, I said: >You should only use merging to merge two divergent or unrelated histories.
  - WorldMaker 8y ago
    Merge history can be useful history in source control. Rebases and cherry picks just hide merges, sweeping them under the rug, sometimes making them extremely hard to spot when they go wrong, and even harder to fix down the line when it causes the next merger to go wrong (as this article series works to show in explicit examples). It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories".
    - Sir_Cmpwn 8y ago
      The conflicts shown in the article are generally solved by rebasing and are not any different from a merge conflict. If the changes which caused them represent divergences in genuinely separate histories, then a merge makes sense. >It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories". Remember that git is distributed, not just nominally but also in workflow.
fulafel 8y ago
Merges record what actually happened, rebase rewrites history. Recording accurate history is not strictly necessary, but it's a useful thing inba vcs. Merge commits visibility in revision log is just an UI artifact.
- Sir_Cmpwn 8y ago
  Not only is it not strictly necessary to record an accurate history, but it's explicitly desirable to rewrite history. Effective git use starts with frequent and thoughtful rebasing. Merge commits are supposed to show up in the UI, for the reason you said - recording it when it happens. But it's only useful when it needed to happen, during the normal course of development this is not usually the case.
  - fulafel 8y ago
    So what are the costs of preserving history that exceed the benefits? Benefits include at least (1) tracking down merge errors, (2) safety from the train wrecks when someone inevitably rebases and merges the same code, (3) additional resolution in the the actual history of the code as it happened including dead ends as failed experiments to learn from? I can think of only one well founded case for wanting to rewrite history (instead of adding metadata to the history, such as merge commits and revert commits), and that is polisihng the history after the fact to hide what happened in the sausage factory. This may be a legit reason if you are not working in a safe environment or otherwise want to prepare for a future adverserial setting with some people who will see the history. A special case of this is when you accidentally commit a secret into the code, but that case has satisfactory technical recipes already. If we want to improve the s/n in the log messages, a good avenue is better commit messages and metadata for the merges. For example in a github PR based workflow the main change note in each unit of work is the PR's description, and the individual commit messages are just minor notes along the way.

Steltek 8y ago

I would argue the "design goals" of git have evolved far past the kernel, which is a very unique and special project. These new patterns don't seem to invalidate how the kernel uses git and they offer a lot of ergonomics in a Github-styled atmosphere. Are the only downsides that 1) users don't understand how kernel development is done, which extends far beyond source control; and 2) a merge commit is left as a marker?

Sir_Cmpwn 8y ago
It's not really about the kernel, the kernel is just where the world's most talented git experts work. The downsides include the creation of a merge commit, sure, but also the fact that it's used as a crutch by users who would rather not strive to understand how git works.

WorldMaker 8y ago

Git uses a DAG for multiple reasons. Avoiding merge commits is ignoring most of the power of having a DAG for data structure. The Linux Kernel repo itself has some fascinating examples of DAG usage, including some of the most well known "octopus" merges with many more than two merge parents.

Sir_Cmpwn 8y ago
I don't think octopus merges or most merges in the Linux kernel are related to the point the article is making, or the workflow GitHub encourages. I'm not saying you should never merge, I said: >You should only use merging to merge two divergent or unrelated histories.
- WorldMaker 8y ago
  Merge history can be useful history in source control. Rebases and cherry picks just hide merges, sweeping them under the rug, sometimes making them extremely hard to spot when they go wrong, and even harder to fix down the line when it causes the next merger to go wrong (as this article series works to show in explicit examples). It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories".
  - Sir_Cmpwn 8y ago
    The conflicts shown in the article are generally solved by rebasing and are not any different from a merge conflict. If the changes which caused them represent divergences in genuinely separate histories, then a merge makes sense. >It's better to merge often and rarely if ever allow two branches to even have "divergent or unrelated histories". Remember that git is distributed, not just nominally but also in workflow.

fulafel 8y ago

Merges record what actually happened, rebase rewrites history. Recording accurate history is not strictly necessary, but it's a useful thing inba vcs. Merge commits visibility in revision log is just an UI artifact.

Sir_Cmpwn 8y ago
Not only is it not strictly necessary to record an accurate history, but it's explicitly desirable to rewrite history. Effective git use starts with frequent and thoughtful rebasing. Merge commits are supposed to show up in the UI, for the reason you said - recording it when it happens. But it's only useful when it needed to happen, during the normal course of development this is not usually the case.
- fulafel 8y ago
  So what are the costs of preserving history that exceed the benefits? Benefits include at least (1) tracking down merge errors, (2) safety from the train wrecks when someone inevitably rebases and merges the same code, (3) additional resolution in the the actual history of the code as it happened including dead ends as failed experiments to learn from? I can think of only one well founded case for wanting to rewrite history (instead of adding metadata to the history, such as merge commits and revert commits), and that is polisihng the history after the fact to hide what happened in the sausage factory. This may be a legit reason if you are not working in a safe environment or otherwise want to prepare for a future adverserial setting with some people who will see the history. A special case of this is when you accidentally commit a secret into the code, but that case has satisfactory technical recipes already. If we want to improve the s/n in the log messages, a good avenue is better commit messages and metadata for the merges. For example in a github PR based workflow the main change note in each unit of work is the PR's description, and the individual commit messages are just minor notes along the way.