4 ms·

I see often, including in this case, that GitHub contains only a squashed version of the development history. Assuming that the developer keeps working on top o

I see often, including in this case, that GitHub contains only a squashed version of the development history. Assuming that the developer keeps working on top of the original branch with full history, is there a way to keep a squashed and a not-squashed branch in sync automatically?

bluejekyll 6y ago
When you say “squashed” vs “not-squashed”, are you referring to the “squash” merge feature in Github? If so, that turns a PR branch into a single commit onto the target branch (master). Unless the old branches are kept around, the unsquashed commits won’t be available.
- hobo_mark 6y ago
  I'm referring to the squash feature of git rebase. The developer collapsed years of commits into one before pushing to GitHub, I am wondering if there is a way to keep working on top of the original history privately, and pushing to the "clean" history on GitHub, without having to cherry-pick all new commits for GitHub by hand.
  - wadim 6y ago
    I guess the "easiest" solution would be a clean and separate "github" directory where no work happens and where you just cp all your changes from your actual working directory into. If they version it, I could also imagine using master as an orphan branch and just cherry-pick the changes between two tags or commits into it.
  - mook 6y ago
    git replace¹ should be able to do it; otherwise, grafts² work too. ¹ https://git-scm.com/docs/git-replace https://git-scm.com/docs/git-replace ² https://git.wiki.kernel.org/index.php/GraftPoint https://git.wiki.kernel.org/index.php/GraftPoint
    - hobo_mark 6y ago
      That is it! Fantastic, thanks! https://git-scm.com/book/en/v2/Git-Tools-Replace https://git-scm.com/book/en/v2/Git-Tools-Replace gives the exact example of what I had in mind.
Rexxar 6y ago
In this particular case it seems justified as the framework was part of a bigger project. So probably the majority of the commit history would not be relevant to the project in its current state.

bluejekyll 6y ago

When you say “squashed” vs “not-squashed”, are you referring to the “squash” merge feature in Github? If so, that turns a PR branch into a single commit onto the target branch (master). Unless the old branches are kept around, the unsquashed commits won’t be available.

hobo_mark 6y ago
I'm referring to the squash feature of git rebase. The developer collapsed years of commits into one before pushing to GitHub, I am wondering if there is a way to keep working on top of the original history privately, and pushing to the "clean" history on GitHub, without having to cherry-pick all new commits for GitHub by hand.
- wadim 6y ago
  I guess the "easiest" solution would be a clean and separate "github" directory where no work happens and where you just cp all your changes from your actual working directory into. If they version it, I could also imagine using master as an orphan branch and just cherry-pick the changes between two tags or commits into it.
- mook 6y ago
  git replace¹ should be able to do it; otherwise, grafts² work too. ¹ https://git-scm.com/docs/git-replace https://git-scm.com/docs/git-replace ² https://git.wiki.kernel.org/index.php/GraftPoint https://git.wiki.kernel.org/index.php/GraftPoint
  - hobo_mark 6y ago
    That is it! Fantastic, thanks! https://git-scm.com/book/en/v2/Git-Tools-Replace https://git-scm.com/book/en/v2/Git-Tools-Replace gives the exact example of what I had in mind.

Rexxar 6y ago

In this particular case it seems justified as the framework was part of a bigger project. So probably the majority of the commit history would not be relevant to the project in its current state.