Re: interactive rebase results across shared histories

From: Stepan Kasal <kasal@ucw.cz>
Date: Feb 26, 2016, 22:56 UTC
Message-ID: <20160226225650.GA3185@ucw.cz>
In-Reply-To: <87povj41m9.fsf@gmail.com>

Hello Seb,

let me add a few things, perhaps they'll clean some misunderstandings.

On Fri, Feb 26, 2016 at 03:12:46PM -0600, Seb wrote:

Show 10 quoted lines

> After cleaning up all the mess, I've ended up with a long master branch,
> and a series of earlier commits that are not reachable from master.
> Fortunately, the tags have kept them alive. This is the scenario
> simplified:
> 
> A---C---D(tag2)                 loose commits (not on any branch)
>  \
>   B(tag1)
> 
> E---F---G---H---*               (master)

I noticed that these are tags. Actually, tags in git are meant to mark certain fixed points, and they are not meant to change in the future.

They are used to mark releases in the project, and they can even have a cryptographic signature attached to it, so that no one can forge them.

I guess that you used them as a temporary mark for yourself when you reaced a point in development, or to mark a stable point as a base for future development. If that was the case, you could have used a branch as well.

I guess that people subconsciously still think that branch is ecpensive, based on the experiences from other VCS. It's not true: branch is a variable that holds a value: the hex id of the top commit. As you do not care how many variables you need to declare when writing code, you should not hesitate to create as many branches as you need to mark the points in the history.

Perhaps you just delte the tags. That would be true if the code in these old branches has already been copied (by rebase) to the new master.

If you would like to mark the corresponding points in the rewritten history, you can create these marks again. (As branches, perhaps.)

Then you say that you want to put everything to one branch master, to create a linear history of development. (Well, not true history, but a made up history, you see.)

For that goal, does master already contain all the code? If yes, then you have it. You can perhaps just delete all the old branches that were used to develop individual parts...

I'm working on a project, where we decided to have linear history
on the main server.
So my own local git clone of my work contains lots of branches named
after features and their combination, like:
    counting
    counting-3counters
    pairs
    counting-with-pairs
    counting-3c-pairs

I use rebase heavily to move each of the feature (=series of commits) to another branch ot to master.

For example, when i wanted to enhance branch "counting" with the feature "pairs," I did it like this:

git branch counting-with-pairs pairs git rebase -i counting counting-with-pairs

That will take all the commits that are in pairs, but not in counting. (This is usually all the commits in "pairs", staring from the point where in branched from master.) And all these get replayed on the tip of "counting".

Likewise, I can move the topic to the latest master, then move master (git checkout master; git merge --ff-only some-branch) and then push.

BTW, another thing: when you decided to clean up the history -- are there any other people working with the repository you are working with?

If yes, then each of them has to be prepared to follow your cleanup. All their work is currently base on the old history; if they push their work all the old hostory will be back.

They could throw away their current local clones and start anew, if they had no work there. But that's probaably not the case.

So they have to fetch your new history of master and then rebase all of their features --onto your new master.

I hope some of my talking will be useful.

Stepan