Hi
so you have
*---1---2---3---4--
\
--D--
You have that '3' and 'D' each changed/created/added the file readMe.txt
(it is always worth drawing a diagram, just in case)
You asked for "-i" interactive (and other stuff - is it necessary). This
should have shown you a list of commits that will be moved (picked). The
rebase is a list of cherry-picks of commits that are being grabbed from
one branch and placed onto (on top of) another branch, and to finish,
the old branch tip is swappped to the new tip.
The list should be simply
pick D message
you (the rebase) want to end up with:
*---1---2---3---4---D'--
where D' is the old D, but with the [merge] conflict fixed (without a
merge).
Oh Oh Oh, just seen your "no-FF". Hmm, not sure about that, or where it
gets used. I wasn't expecting that in a rebase.... A rebase is
explicitly so we do not merge old work, rather we move it to a better
place - we cut off a side piece and fasten it back on further
up/somewhere else.
It sounds like your expectation about rebase is still incomplete. I
would agree that the concepts used in Git (and other DVCS) do feel
somewhat alien because in the real [material] world there can only be
one original.
In the Git/computer world there are zero originals, just 1..N+1
identical copies (here that's of the file contents==blobs). And then
there are all those Directed (acyclic) graphs and trees (also directed
and acyclic). Those graphs have tips (ends) which we (often) label with
the 'refs' (short for references) such as the branch heads refs (they
point the other way).
So for the branch 'Daughter' it was point at the commit "D", and Master
was pointing at "4". You asked to move the part of Daughter that wasn't
on master up to the top. Git scans the graph 'painting' down master (the
don't wants), and then down Daughter (the wants) (default via the first
parent list) till it gets to the don't want paint, and see that it's
list comprises of just '4'.
It then goes back to the top of master, and transfers '4' onto the end
of the graph (keeping it's own special ref pointer to know where it is
up to because it does not move master's own pointer). It should prompt
for resolution at this point if there are conflicts. After completing
the move (todo) list [instruction sheet(insn?)], git can then update the
daughter's branch ref to where it has got up to. Thus the old daughter
branch seems to disappear ('cos it has moved). Git's helpful in that it
keeps a copy of that old ref in a special ref called REBASE_HEAD (IIRC),
just in case it needs to abort etc.
So. First do create a short commit sequence that does have real messages
and file content
echo one >one.txt && git add -A && git commit -m.one
...
git checkout -b daughter :/.two
echo daughter>three.txt && git add -A && git commit -m.D
Do check that I have those short form command right, along with the ":/"
method for finding a commit by message - see the revisions guide
git help revisions
git help glossary
Also the messages will start with a dot '.' as it made this note more
readable;-) .Plus (advanced stuff) the :/<text> method should be
compared with HEAD^{/<text>} method to see (roughly) what the : is being
swapped for
I hope that gives you a start in creating a nice clean MVCE
(https://stackoverflow.com/help/mcve) and exploring the rebase with the
fewest extra options - more options implies you are more and more a
special case, so probably going in the wrong direction, or made a
mistake earlier to be leaned from.
Ooo thats longer than I expected, but useful to do.
Philip
On 06/04/2019 17:36, neverasi...@gmail.com wrote:
Hi Philip and all you,
I'm too confused, maybe going by degrees is the best.
Let's suppose
* we have a "master" branch linear history composed by 4 commits,
* in the third commit of "master" branch was created a file
"readMe.txt", unchanged in the fourth commit of "master" branch
history,
* we have also a "daughter" branch generated just after the second
commit of "master" branch (before the third commit of "master"
branch),
* during the "daughter" branch commit history, a different file
"readMe.txt" was created.
In this situation I execute
git rebase -i --allow-empty-message --keep-empty --stat -v --verify
--no-ff "master" "daughter"
and I find that "daughter" "readMe.txt" file is silently set in the
rebased history, resulting as the current file version.
Indeed I expected an explicit merging request: why not? How possible?
What was I wrong?
I tried also git rebase -i --allow-empty-message --keep-empty --stat
-v --verify --no-ff --merge"master" "daughter" with no effect!
I'm very frustrated:
* maybe would I explicitly have to set "merge" option (instead of
default "pick" option) in the first row of todo-file?
* maybe I was wrong in any above command line option?
What are the correct approaches?
Thanks in advance for your patience.
Il giorno sabato 6 aprile 2019 10:53:48 UTC+2, never...@gmail.com ha
scritto:
Hi all,
could anyone clarify the meaning and the usage of
* --root command line option,
* --merge command line option (Maybe is it anyway related to
merge option in interactive todo-file?),
possibly providing an example in principle?
The official documentation is very obscure because too synthetic
... it could be understood just by whoever already knows GiT.
--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to git-users+unsubscr...@googlegroups.com
<mailto:git-users+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
