Re: Subtree in Git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 05/05/2012 06:25 AM, Junio C Hamano wrote:
> greened@xxxxxxxxxxxxx writes:
>>> I basically did a: git subtree merge --prefix=contrib/subtree <my
>>> git-subtree branch>
>>> The work in progress in on: (the
>>> subtree-updates branch)
>> This branch seems to have a bunch of commits from master or some other
>> branch:
> Isn't the confusing shape of the history a direct result of what Herman
> said he did above, i.e. use of "subtree merge"?  I thought that we agreed
> not to do any more subtree merges for further updates when we slurped the
> subtree history to contrib/ early in this cycle, so if that is the case,
> Herman needs to rebase his work so that the integration will not need any
> "subtree merge" into git.git, perhaps?
> I looked at various branches found with ls-remote in that repository but I
> couldn't quite tell which is what, with too many cross merges, among which
> there are unnecessary duplicated commits (e.g. 90275824 and b9a745f7 seems
> to be two equivalent commits) and questionable changes from the overall
> project's point of view.
> For example, it renames git-subtree.txt to at a4416ee; while I
> find the idea of departing from asciidoc somewhat attractive (perhaps this
> is only because I haven't been burned by markdown yet), if "git subtree"
> wants to live in the git.git repository, that change is a regression.
> Later the file is renamed back to git-subtree.txt ( is lost) at
> 9ffdeb, a commit with a single-liner "fixing typo" log message adds the
> file with full contents of git-subtree.txt again at d9ccd03b,
> and then later merge of the branch at 8861de28 finally decides to revert
> that to have a shorter that the history originally had, or
> something.  In short, it is a mess.
> Not very impressed, but I have this suspition that the history I was
> looking at was not what was meant to be sent to me and an older
> incarnation of the project before Herman cleaned it up for public
> consumption, or something.
> Confused...

I agree that it's a messy history.  It the result of the many painful
merges I did. In various stages a conflicting indentation and other
changes made it painful to get a clean merge.
In an attempt to get through this in a pragmatic way the history has
taken some damage.

Before  starting this latest subtree merge I actually tried to rebase.
However this failed very quickly, on the I think third commit out of 60,
landing me in conflict resolution as I had already been through.
I'd love to improve git but this was just taking too mush effort.
When I saw the quick result from subtree merge that seemed like a good

Wouldn't a good rebase have almost just as messy a history as the
subtree merge?

As an alternative I've now applied a patch with all changes on a clean
master branch.
In the commit message I've named all committers from the original history.
Would that be acceptable?
Its now available as
The subtree merge version is still available as


Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google