Re: rationale behind git not tracking history of branches

From: Michal Suchánek <msuchanek@suse.de>
Date: May 27, 2020, 19:31 UTC
Message-ID: <20200527193149.GJ25173@kitsune.suse.cz>
In-Reply-To: <CAKTRx=29XBtKgt0m1+aCex_YZeiDzk5oBBxuM45NvVHmuqUVNQ@mail.gmail.com>

On Wed, May 27, 2020 at 11:24:59AM -0500, Kevin Buchs wrote:

Show 9 quoted lines

> Hi Jonathan,
> 
> Thanks for the reply. I will give you my current situation. I am just
> taking over a project that many cooks were involved in previously. We
> have three persistent branches: dev, staging and master which
> correspond directly to three CD environments: dev, staging and prod.
> The nominal commit history ought to be that all changes happen in the
> dev branch, and that the latest dev is merged into staging and then to
> master at appropriate milestones of testing. However, the history of

In this setup you should have merges on dev only. staging should be behind dev and master behid staging but any merge between these branches should be fast-forward. Creating the merge commits would only add noise.

Show 10 quoted lines

> commit chains clearly show that is not the case. Here is what gitk
> shows me: https://1drv.ms/u/s!AgKA2HL-SveIha4Y_5lihkQO7ulfKQ?e=oA9PEi
> .
> Now, you can see that the nominal practice was not followed. Sure,
> there are many commit messages to indicate merges and I could assume
> those are correct and possibly reconstruct which branch each commit
> might have belonged to. However, you can see there were a series of
> changes to multiple commit chains, when there should have just been a
> single chain - corresponding to the dev branch. How do I know there
> were not changes that should be included in dev that were stranded?

Find commits that are not ancestors of dev branch tip.

But if you are taking over the project maybe just auditing the actual difference between the branches might be easier. Then you can use git blame to see how the pieces of code that differ entered the branch in question.

Going from the diverging history to one where the branches are as described you can merge master to dev once to make all commits formally ancestors of dev, preferably after examining and reconciling the differences.

HTH

Michal