Re: [RFC PATCH 00/18] Multi-pack index (MIDX)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 10, 2018, 17:05 UTC
Message-ID: <nycvar.QRO.7.76.6.1801101756140.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <CAGZ79kYdgD2h7QjjJe0aA4eMATCGkH62XYvziUNvAPsBJDXOCA@mail.gmail.com>

Hi Stefan,

On Tue, 9 Jan 2018, Stefan Beller wrote:

Show 12 quoted lines

> On Tue, Jan 9, 2018 at 5:05 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Just to throw this out there: --abbrev=8! would be one possible
> > convention to state "I want exactly 8 hex digits, don't bother
> > checking for uniqueness".
> >
> > Not sure how urgent such a feature is.
> 
> You seem to have spent some time on rebase, including lamenting on the
> in-expressiveness of the instruction sheet (c.f. "rebase a mergy history
> sucks")

Let's call it "todo list" again?

And yes, I spend a *lot* of time in rebase. It's part of my duties as Git for Windows maintainer.

Show 9 quoted lines

> And in that light, I'd like to propose a new naming scheme:
> 
> (a) assume that we "tag" HEAD at the start of the rebase
> (b) any abbreviation must be given as committish anchored to said ref:
> 
> pick REBASE_HEAD~1 commit subject
> pick REBASE_HEAD~2 distak the gostim
> pick REBASE_HEAD~3 Document foo
> pick REBASE_HEAD~4 Testing the star-gazer

I do not necessarily agree that this is better because it is valid only locally, only in the current rebase (and you enter new problems because you implicitly require REBASE_HEAD to be worktree-local lest you prevent simultaneous rebases in related worktrees).

That prevents you from, say, chatting to your colleague and mentioning that commit that you are uncertain about. Imagine asking "Hey Todd, do you know what REBASE_HEAD~2 is all about?". Granted, if you ask about "deadbeef" and it just so happens that this shortened name is ambiguous in Todd's repository. But that is pretty unlikely, isn't it?

> And as we have the full descriptiveness of the committishs there, each
> commit can be described in a unique way using the graph relationship.  I
> am just throwing the name REBASE_HEAD out there to trigger some
> associations ("similar to FETCH_HEAD"), but I dislike the name.

Not only that. It would also be confusing to read after reordering...

> (c) this would not solve the problem of mergy history, yet. For that
> we'd need to introduce more keywords, that allow us to move around in
> the DAG, [...]

You probably missed my hint that I have a working solution for that. Please have a look at

	https://github.com/git/git/pull/447

Short version: for a commit topology like this:

	A - B - C
	  \   /
	    D

the generated list would look like this:

	# branch D
	pick 0123 A
	label branch-point
	pick 1234 D
	label D

	reset branch-point
	pick 2345 B
	merge 3456 D C

Ciao, Dscho