Re: Git without morning coffee

From: Michael Witten <mfwitten@gmail.com>
Date: Sep 7, 2011, 17:23 UTC
Message-ID: <CAMOZ1BstyMteutmK7tst=3t9djavY9_4vBKJgdj7rhUnE1Wr7w@mail.gmail.com>
In-Reply-To: <7vehzs47we.fsf@alter.siamese.dyndns.org>

[Sorry for the repeat, Junio]

On Wed, Sep 7, 2011 at 16:46, Junio C Hamano <gitster@pobox.com> wrote:

Show 43 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> git merge ":/Merge branch 'jk/generation-numbers' into pu"
>> fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
>> to a commit
>> # Huh?
>
> Interesting.
>
>> git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
>> error: addinfo_cache failed for path 't/t7810-grep.sh'
>> Performing inexact rename detection: 100% (91476/91476), done.
>> error: addinfo_cache failed for path 't/t7810-grep.sh'
>
> Smells like another case where merge-recursive is looking at the work tree
> when it shouldn't inside an inner merge or something.
>
>> I mean, I'm merging a commit from origin/pu to origin/next when the
>> latter is basically contained in the former (except for some merge
>> commits).
>
> This falls into the "side note" category, but these days 'next' and 'pu'
> do not share any history beyond the tip of 'master'. Every time I update
> the 'pu' branch, it is rebuilt directly on top of 'master' from scratch by
> merging the topics in 'next' (and at this point I make sure its tree
> matches that of 'next') and then merging remaining topics on top of the
> result. A topic often goes through multiple iterations of fix-ups while in
> 'next', and these fix-ups result in multiple incremental merges of the
> same topic into 'next'; I do not want to see an incorrect merge when such
> a topic is merged in a single-step into 'master', and it is one way to
> ensure the health of the merge fixup machinery (including the rerere
> database) to attempt from-scratch-the-whole-topic-at-once merges and
> verify the result.
>
> The merge you attempted will have a lot of "the history leading to the
> current commit added/modified in a certain way and the history being
> merged did the same modification independently" kind of conflicts that
> should resolve to no-op.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I think it would be great if at some point you could write a detailed tutorial of how you maintain git (using example topics, example patch series and pull requests, and follow-along command sequences, etc.). Most importantly, it would be nice to see an explicit description of the maintenance properties you are trying to achieve with your workflow.