greened@xxxxxxxxxxxxx (David A. Greene) writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Jeff King <peff@xxxxxxxx> 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".
>> 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 subtree
to 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html