Re: git-subtree Ready #2
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 21, 2012, 06:34 UTC
- Message-ID
- <7vwr7gitjl.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <87ehtowxu7.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > >> Jeff King <peff@peff.net> writes: >> >> It sounds like the simplest and cleanest would be to treat it as if its >> current version came as a patch submission, cook it just like any other >> topic in 'pu' down to 'next' down to eventually 'master', with the usual >> review cycle of pointing out what is wrong and needs fixing followed by a >> series of re-rolls. > > Ok, but we will preserve the history via the subtree merge, yes?
I'll comment on just this part, but a short answer is "no, I do not think so".
Even though you left "Jeff King writes", you removed everything he said that I was quoting, and in order to understand why the answer is 'no', it would have been better if you kept this part from what he said in your reply:
>> ... Either way, I do think it's >> worth saving the commit history by doing a real merge.
as that was what I was agreeing to with my "as if ... a patch submission".
Show 17 quoted lines
>> After looking at the history of subtree branch there, however, I agree >> that it would not help anybody to have its history in my tree with log >> messages like these (excerpt from shortlog output): >> >> update todo >> Some todo items reported by pmccurdy >> todo >> Docs: when pushing to github, the repo path needs to end in .git >> todo >> todo^ >> todo >> todo: idea for a 'git subtree grafts' command > > Ok, these are Avery's commits. I don't know that I have enough context > to improve the logs but I will look throught revisions and try to figure > things out. Avery, could you be of any help here? It sounds like we > need more descriptive log messages.
That was not what I was suggesting.
I was saying that the history up to the current state, littered with these commits that are not "logical progression" but merely "a snapshot of then-current state" may not be worth preserving, with or without better messages.
Rewriting the entire history to make it a logical progression just for the sake of history is obviously not worth the effort.
Which suggests that taking the end result that exists at the tip of your subtree branch as a single code-drop, without pulling its history, lets us start from a reasonably well tested state and would not lose us anything of value. And that was what I was suggesting. For our history to explain why/how the code got there better, another approach might be to instead treat your bd7b2cf (Add 'contrib/subtree/' from commit '2793ee6ba...', 2012-01-29), which is where you took Avery's then-current state, as the code-drop event that adds everything in contrib/subtree/ with a single patch submission. I.e. in a git.git repository:
git checkout -b subtree master
git fetch git://sources.obbligato.org/git/git.git subtree
git merge --squash bd7b2cf
git commit -m "contrib: add git-subtree from Avery's tree"to take the tip of your subtree branch. The history up to that point is in Avery's repository where he stopped, which such an approach will not pull in to git.git. And then we can replay bd7b2cf..FETCH_HEAD like so:
git checkout FETCH_HEAD
git rebase --onto subtree bd7b2cf
git push . HEAD:subtree
git checkout pu
git merge subtreeto preserve the history since that single code-drop event that records your effort to adjust the code-dump into a better shape to live in our contrib/ area. That will make it clear the division of blame on the code added to git.git between Avery (everything before the squashed merge) and you (everything after that).