From: Herman van Rink <rink@initfour.nl>
To: Junio C Hamano <gitster@pobox.com>
Cc: greened@obbligato.org, dag@cray.com,
Hilco Wijbenga <hilco.wijbenga@gmail.com>,
Git Users <git@vger.kernel.org>
Subject: Re: Subtree in Git
Date: Mon, 07 May 2012 21:50:49 +0200 [thread overview]
Message-ID: <4FA82799.1020400@initfour.nl> (raw)
In-Reply-To: <7v8vh78dag.fsf@alter.siamese.dyndns.org>
On 05/05/2012 06:25 AM, Junio C Hamano wrote:
> greened@obbligato.org writes:
>
>>> I basically did a: git subtree merge --prefix=contrib/subtree <my
>>> git-subtree branch>
>>>
>>> The work in progress in on: https://github.com/helmo/git (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 README.md 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 (README.md is lost) at
> 9ffdeb, a commit with a single-liner "fixing typo" log message adds the
> README.md 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 README.md 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
thing.
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 https://github.com/helmo/git/tree/subtree-updates
The subtree merge version is still available as
https://github.com/helmo/git/tree/subtree-updates-merged
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
next prev parent reply other threads:[~2012-05-07 19:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 18:48 Subtree in Git Hilco Wijbenga
2012-04-27 20:38 ` dag
2012-04-27 21:09 ` Hilco Wijbenga
2012-05-01 8:34 ` Herman van Rink
2012-05-04 2:26 ` greened
2012-05-04 10:08 ` Herman van Rink
2012-05-05 4:25 ` Junio C Hamano
2012-05-07 15:21 ` dag
2012-05-07 19:50 ` Herman van Rink [this message]
2012-05-07 21:57 ` dag
2012-05-11 20:24 ` Junio C Hamano
2012-05-23 15:13 ` dag
2012-06-12 1:30 ` greened
2012-06-13 13:20 ` Herman van Rink
2012-07-11 16:14 ` dag
2012-10-20 20:03 ` Herman van Rink
2012-10-21 6:32 ` Junio C Hamano
2012-10-21 15:09 ` Herman van Rink
2012-10-21 19:51 ` Junio C Hamano
2012-10-21 20:23 ` Herman van Rink
2012-10-22 14:47 ` dag
2012-10-22 14:44 ` dag
2012-10-22 14:41 ` dag
2012-10-26 13:10 ` Herman van Rink
2012-10-26 13:58 ` David Michael Barr
2012-10-26 16:54 ` James Nylen
2012-10-29 15:55 ` dag
2013-03-01 2:28 ` Kindjal
2013-03-01 22:05 ` Paul Campbell
2013-03-02 11:21 ` David Michael Barr
2013-03-02 17:43 ` Paul Campbell
2013-03-04 22:33 ` Paul Campbell
2012-10-29 15:53 ` dag
2012-05-04 22:50 ` Daniel Koester
2012-06-12 1:32 ` greened
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FA82799.1020400@initfour.nl \
--to=rink@initfour.nl \
--cc=dag@cray.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=greened@obbligato.org \
--cc=hilco.wijbenga@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).