Hello.
On Mon, 03 Nov 2014 21:25:10 +0100, Luc Maisonobe wrote:
Le 03/11/2014 20:57, Luc Maisonobe a écrit :
Le 03/11/2014 12:09, Gilles a écrit :
Hi.
Hi Gilles,
Three posts such as the following were sent to this ML:
Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/commons-math
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit:
http://git-wip-us.apache.org/repos/asf/commons-math/commit/7df65a5d
Tree:
http://git-wip-us.apache.org/repos/asf/commons-math/tree/7df65a5d
Diff:
http://git-wip-us.apache.org/repos/asf/commons-math/diff/7df65a5d
Branch: refs/heads/master
Commit: 7df65a5ddf59b564af1d753b89d30f8dc33a2c5d
Parents: 4a6bf54 45ae5c7
Author: Gilles <er...@apache.org>
Authored: Sun Nov 2 23:22:11 2014 +0100
Committer: Gilles <er...@apache.org>
Committed: Sun Nov 2 23:22:11 2014 +0100
----------------------------------------------------------------------
src/changes/changes.xml | 3 +
.../math3/ode/ContinuousOutputModel.java | 71
++++++++++++++++++--
.../math3/ode/sampling/StepInterpolator.java | 28 ++++++--
.../math3/ode/ContinuousOutputModelTest.java | 21 ++++--
4 files changed, 105 insertions(+), 18 deletions(-)
----------------------------------------------------------------------
They seem like a report on what happened on my local repository so
that I could commit local changes after the main repository had
been
updated.
This kind of message looks utterly useless and distracts from those
that report actual changes to the main repository.
Don't you think that they should be filtered out?
I'm not sure.
If not, can you explain their purpose?
I think this is due to the very strict handling of history by Git.
Each
commit is completely linked with its parent and the commit hash
takes
this link into account. In other words, the commit does not depend
only
on what it contains but also on what point in the history it is
applied to.
A side effect is that if the main repository history is:
A -> B -> C -> D
and at this point you clone it and start working on a local change,
your
local history will be as follows:
A -> B -> C -> D
|
-> G1 -> G2 -> G3
Then, someone else pushes other modifications on the main
repository,
which still only has D as its head, so the main repository history
becomes:
A -> B -> C -> D -> E -> F
On your local clone, you merge these changes and get:
A -> B -> C -> D -> E -> F---------
| |
-> G1 -> G2 -> G3 --> G4
where G4 is a merge.
This can occur several time.
When you finally push your work back to the repository, it pushes
the
full history of your current head to become the new head. So you
will
see G1, G2, G3 (and this is really what you want, as it means you
can do
small incremental changes without losing anything), but it will also
see
some merge about thing you did not do yourself.
Thanks for the detailed description. I could vaguely imagine something
of the like, and that "git" must of course keep track of all the
history.
However the issue was more about avoiding confusion that could (and
did)
arise from a message reporting a "trivial" local change that nobody
cares about but "git").
For the record, there is a way to completely avoid this merge, by
replacing the branch with a new one "replaying" the commits G1, G2
...
on top of F instead of their original start commit which was D. This
is
done using "git rebase". After a rebase, G1 parent becomes F and the
merge is done in a simpler linear way, this is what Git calls a
"fast-forward" merge. However, I would not recommend using rebase,
especially to someone not already accustomed to Git.
Why?
At first sight, from the perspective of the other contributors,
shouldn't
it be done that way.
Shouldn't we define workflow guidelines that would help avoid
confusion?
You could perhaps list the sequence of git commands that are most
suitable
in each scenario that corresponds to basic usage in the context of CM.
One of them would be the situation described above (e.g. a contributor
works on a feature while the "origin" is evolving). So:
1. Update the local copy
2a. Create a branch (?)
2b. Change local files
3. View the changes
4. "Add" (stage?) files
5. Commit files (locally)
6. View the changes in the committed files (not as obvious as point 3!)
7. Keep the local repository in sync with origin
8. "rebase" (?)
9a. How to locally "uncommit" (?) files?
9b. How to change the commit log?
9c. How to "unstage" (?) files?
10a. How to see/select what will be "push"ed?
10b. Commit ("push") to the main repository
Here, commit 7df65 is a merge commit. It does not really include any
change, but only records the fact the current point in history has
two
parents as it is the result of merging (here without any conflict)
commits 4a6bf54 (which was also a previous merge in your local
history)
and 45ae5c7 (which was the head of main repository). If you follow
the
link "Diff" from the message, you will see this commit is labeled as
"trivial merge" without any modified files associated.
Perhaps you could ask INFRA
With my currently limited knowledge of "git", I won't dare enter in a
discussion where I might not understand some of the answers or requests
for further information... [E.g. Is the problem there, or BKAC?]
Best regards,
Gilles
why the message from merge commit 7df65 does
contain the list of files modified by one of its parent commit (here
45ae5c7) instead of an empty list as there was no conflict between
the
merge. If I run "git show --format=fuller 7df65" to have an
extensive
description of the commit, I only get:
commit 7df65a5ddf59b564af1d753b89d30f8dc33a2c5d
Merge: 4a6bf54 45ae5c7
Author: Gilles <er...@apache.org>
AuthorDate: Sun Nov 2 23:22:11 2014 +0100
Commit: Gilles <er...@apache.org>
CommitDate: Sun Nov 2 23:22:11 2014 +0100
Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/commons-math
Also looking at the list of files changed, it seems it includes
files
from several commits in the branches, not only the last changed
files:
commit 45ae5c7 only changed ContinuousOutputModel.java and not
StepInterpolator.java which was changed by an earlier commit in the
history. So I really don't know how the files list is created and
put
into the message. Perhaps INFRA knows.
best regards,
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
