4 ms·

Rebasing isn't just a pain, it's rewriting history. I'm so tired of this!! Of course you never rewrite history on a public branch!! Of course rebase is fanta

by e40 12y ago

Rebasing isn't just a pain, it's rewriting history. I'm so tired of this!! Of course you never rewrite history on a public branch!! Of course rebase is fantastically helpful on a private/feature branch where you are doing development, before you do your final push to the public branch!! Can we stop with these tired, old tropes please??

Kiro 12y ago
Sorry for OT but even if you have a point it's hard to take your comment seriously when you end every sentence with double exclamation or question marks.
- e40 12y ago
  Well, it was for emphasis. I can't count how many times I've seen the "rebase is evil" trope. It's so tired and abused and annoying and misguided. So, yeah, the sentence terminators were to convey the very real emotion on this subject.
  - smeyer 12y ago
    The point of the previous commenter is that even if it's to convey very real emotion, it makes your comment harder to take seriously and actually lessens the impact of it.
barrkel 12y ago
What do you mean by "public branch"? Public to the team, or public to the whole world? I do commercial closed-source development; there is no public branch to the whole world. OTOH, all feature branches are public to the team; only trivial features involve a single developer. So your assertion doesn't seem well-formed to me. Further: The distribution of code and feature responsibilities in a team of full-stack engineers is fluid. Depending on the day, any person might be working on a feature, and the person previously working on it might not even be in the office. It's a general policy where I work to push your branches before close of business.
- e40 12y ago
  What do you mean by "public branch"? Public to the team, or public to the whole world? To anyone other than you. If other people are involved, then think very seriously whether or not rebase should be used. Almost in every case it should not be.
  - barrkel 12y ago
    Exactly my point. How do you reconcile the idea of rebase "should not be" used vs "a merge should only occur to merge a finalized branch in". I'm on your side. My objection was to the latter statement, not the former. The basis of my objection to the former was (in part) because of the problems with rebasing when a branch is distributed. The idea that the only merges that occur are merges of finalized branches seemed very naive to me.
- bnegreve 12y ago
  > I do commercial closed-source development; there is no public branch to the whole world. OTOH, all feature branches are public to the team If you don't work with private branches, it's not surprising that you don't see any value in rebasing which is mostly useful for private branches. In fact, if you don't have private vs. public scenarios, it's not really clear whether you need a distributed version control system. But that makes sense, DCVS were developed for OSS after all.
  - nawitus 12y ago
    What does "private branch" mean? All branches are "private" until I publish them. If I create a branch which tracks a remote branch and make a commit to it, my local branch is "private" and the commit is "private. However, I can push that "private branch" to other developers, and then it becomes public.
    - guipsp 12y ago
      >What does "private branch" mean? All branches are "private" until I publish them. Exactly that. An unpublished branch.
jordigh 12y ago
> Of course you never rewrite history on a public branch!! The problem is that git doesn't track what "public" means. There was a proposal to work on this for GSoC 2012[1], but nobody picked it up. This concept is called "phases"[2] in Mercurial, which are a building block for Evolve[3]. In Mercurial, it'ss possible to safely rewrite commits, and it's also possible to safely propagate your edits to other repos. Git would have to grow something like changeset evolution to make this completely safe and to be able to deprecate `git push --force`. There could be a safer alternative that does not require any forcing. [1] https://github.com/peff/git/wiki/SoC-2012-Ideas#published-and-secret-commits https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an... [2] http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases [3] https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg

by e40 12y ago

Kiro 12y ago

Sorry for OT but even if you have a point it's hard to take your comment seriously when you end every sentence with double exclamation or question marks.

e40 12y ago
Well, it was for emphasis. I can't count how many times I've seen the "rebase is evil" trope. It's so tired and abused and annoying and misguided. So, yeah, the sentence terminators were to convey the very real emotion on this subject.
- smeyer 12y ago
  The point of the previous commenter is that even if it's to convey very real emotion, it makes your comment harder to take seriously and actually lessens the impact of it.

barrkel 12y ago

What do you mean by "public branch"? Public to the team, or public to the whole world? I do commercial closed-source development; there is no public branch to the whole world. OTOH, all feature branches are public to the team; only trivial features involve a single developer. So your assertion doesn't seem well-formed to me. Further: The distribution of code and feature responsibilities in a team of full-stack engineers is fluid. Depending on the day, any person might be working on a feature, and the person previously working on it might not even be in the office. It's a general policy where I work to push your branches before close of business.

e40 12y ago
What do you mean by "public branch"? Public to the team, or public to the whole world? To anyone other than you. If other people are involved, then think very seriously whether or not rebase should be used. Almost in every case it should not be.
- barrkel 12y ago
  Exactly my point. How do you reconcile the idea of rebase "should not be" used vs "a merge should only occur to merge a finalized branch in". I'm on your side. My objection was to the latter statement, not the former. The basis of my objection to the former was (in part) because of the problems with rebasing when a branch is distributed. The idea that the only merges that occur are merges of finalized branches seemed very naive to me.
bnegreve 12y ago
> I do commercial closed-source development; there is no public branch to the whole world. OTOH, all feature branches are public to the team If you don't work with private branches, it's not surprising that you don't see any value in rebasing which is mostly useful for private branches. In fact, if you don't have private vs. public scenarios, it's not really clear whether you need a distributed version control system. But that makes sense, DCVS were developed for OSS after all.
- nawitus 12y ago
  What does "private branch" mean? All branches are "private" until I publish them. If I create a branch which tracks a remote branch and make a commit to it, my local branch is "private" and the commit is "private. However, I can push that "private branch" to other developers, and then it becomes public.
  - guipsp 12y ago
    >What does "private branch" mean? All branches are "private" until I publish them. Exactly that. An unpublished branch.

jordigh 12y ago

> Of course you never rewrite history on a public branch!! The problem is that git doesn't track what "public" means. There was a proposal to work on this for GSoC 2012[1], but nobody picked it up. This concept is called "phases"[2] in Mercurial, which are a building block for Evolve[3]. In Mercurial, it'ss possible to safely rewrite commits, and it's also possible to safely propagate your edits to other repos. Git would have to grow something like changeset evolution to make this completely safe and to be able to deprecate `git push --force`. There could be a safer alternative that does not require any forcing. [1] https://github.com/peff/git/wiki/SoC-2012-Ideas#published-and-secret-commits https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an... [2] http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases [3] https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg