Hi Buga,
Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> writes:
[...]
> I don`t know, I`m thinking if we are looking at todo list from
> different perspectives - to you, it seems to be a sequence of
> commands to create something new (yes, from something that already
> exists, but that`s implementation detail). In that context, using
> `merge` might have sense (even if still being a very special merge).
>
> But to me, as we already have `pick` and not `commit` to rebase
> commits, it means we are not creating but rather reusing what we have
> (being an important concept to reason about), thus `pick` would still
> fit in for picking a merge commit just nicely, and more naturally,
> too.
Exactly.
Fundamentally, a good editing tool should first be able to just safely
reproduce back what it got, only then everything else goes.
>From this follows that git history-editing tool should start from sound
history representation, i.e., some text representation of the DAG that
allows to re-create the DAG back.
The simplest way is to just list all the nodes in some topological
order, along with references to the parents. Then, to simplify the list,
first parent, unless explicitly specified, could be assumed to be the
preceding item in the list.
Next, we actually need _to do_ something with this, so we convert this
to a _todo_ list by prepending action to each element of the list (isn't
it Lisp once again?). Let the action be called 'pick'. Then, e.g., the
piece of history:
B1-------B2
/ \
S--M0---M1---- M2 ----M3 -- M4
from M0 to M4 will be represented like this:
skip S # Just to have a handy reference
pick M0 # Implicit first parent (S)
pick M1 # Implicit first parent (M0)
pick M2 # Implicit first parent (M1)
pick B1 M1 # Explicit first parent
pick B2 # Implicit first parent (B1)
pick M3 M2 B2 # Explicit first and second parents
pick M4
Which basically gets us back to what you are advocating.
Here is another variant, using command options to specify parents (I
also exchanged order of branch and mainline):
skip S # To have the base reference handy
pick M0 # Implicit first parent (S)
pick B1 # Implicit first parent (M0)
pick B2 # Implicit first parent (B1)
pick M1 -1 M0 # Explicit first parent M0
pick M2 # Implicit first parent (M1)
pick M3 -2 B2 # Implicit first parent (M2) and
# explicit second parent B2
pick M4 # Implicit first parent (M3)
I like this one even better.
IMHO, this is indeed a good starting point. No special treatment for
merges is needed so far.
-- Sergey
