Ok, I think there's something that could be tried with git, that both
* saves the full history of work
* shows only meaningful history on master
* keep the history of pull requests
I've never done this, and I'm only running from approximation, but you
actually made me curious enough to think about it. I must admit that I'd
seriously like the more successful git hosting platforms to seriously
consider point 3, because the history of a given pull-request is
impossible to follow (you never know if the committer added a new
commit, or if they amended the last commit)
So:
1. Hack and commit along the way
----A----B----C
\
--D---E---F
2. When you're ready for a pull-request, create a merge commit and put a
tag on it saying "PR 123 attempt 1". The merge commit should contain
a summary of whatever happened in the initial branch. Put the merge
commit in its own branch, like "PR 123" and create a pull-request
from this merge commit to master
----A----B----C
\
\-------------M
\ /
--D---E---F
3. If you want to modify the commits, do the changes on the feature
branch, and when you're done create another merge commit. Put it
after the first one in the "PR 123" branch, and put a "PR 123 attempt
2" tag to it. Using standard tools such as github or bitbucket, by
putting the merge commit in the same branch the PR will automatically
be updated
With this scheme you have the history of the PR itself through the
branch, where you can see the different attempts, and the summary at
each attempt. When you're on master and you want to have a quick
overview of the history, you can use "git log --first-parent" to only
see the commits that are part of this branch and not all the parent.
In the poor drawings I attempted, you'd see L, then C, then B, then A.
The history is easy to see, however a little googling shows that
bisecting this is not exactly trivial. You'll have to instruct git
bisect to skip over M3^C, ie "everything that is in M3 but not in C".
Unfortunately the standard git isn't smart enough to show two parallel
branches as truly parallel, it tries to squeeze the graph to as few
parallel branches it can show, meaning they all needlessly look
intertwined. Moreover it requires manual fiddling in merge commits to
properly tag them and edit their message for it to be meaningful, but
nothing that can't be easily programmed.
* saves the full history of work * shows only meaningful history on master * keep the history of pull requests
I've never done this, and I'm only running from approximation, but you actually made me curious enough to think about it. I must admit that I'd seriously like the more successful git hosting platforms to seriously consider point 3, because the history of a given pull-request is impossible to follow (you never know if the committer added a new commit, or if they amended the last commit)
So:
1. Hack and commit along the way
2. When you're ready for a pull-request, create a merge commit and put a tag on it saying "PR 123 attempt 1". The merge commit should contain a summary of whatever happened in the initial branch. Put the merge commit in its own branch, like "PR 123" and create a pull-request from this merge commit to master 3. If you want to modify the commits, do the changes on the feature branch, and when you're done create another merge commit. Put it after the first one in the "PR 123" branch, and put a "PR 123 attempt 2" tag to it. Using standard tools such as github or bitbucket, by putting the merge commit in the same branch the PR will automatically be updated 4. You don't have to put changes after the ones in the previous attempt, they can totally be in parallel 5. When you like the changes, just merge Mx into master With this scheme you have the history of the PR itself through the branch, where you can see the different attempts, and the summary at each attempt. When you're on master and you want to have a quick overview of the history, you can use "git log --first-parent" to only see the commits that are part of this branch and not all the parent. In the poor drawings I attempted, you'd see L, then C, then B, then A. The history is easy to see, however a little googling shows that bisecting this is not exactly trivial. You'll have to instruct git bisect to skip over M3^C, ie "everything that is in M3 but not in C".Unfortunately the standard git isn't smart enough to show two parallel branches as truly parallel, it tries to squeeze the graph to as few parallel branches it can show, meaning they all needlessly look intertwined. Moreover it requires manual fiddling in merge commits to properly tag them and edit their message for it to be meaningful, but nothing that can't be easily programmed.