Hi Gilles,
Le 2014-11-04 14:05, Gilles a écrit :
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.
Yes, it could, but rebase may be dangerous and create really confusing
history.
The main problem I did encounter with rebase, when I started using Git
without
fully understanding the consequence of my commands, is that once
something
has been pushed to a remote repository, you should not rebase it later
on locally
and push again. Rebase is good as long as it is done only on one
repository, just
before pushing it remotely. Rebase does what Git calls "history
rewriting" and
if this can be safe on a completely controlled and local environment, it
is a
source of big problems if done on an history line that has already been
shared.
Shouldn't we define workflow guidelines that would help avoid
confusion?
This would be nice.
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
This is done using "git add <filename>"
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" (?)
This would be perfect up to this point, and if everything is clean
there,
the next steps would be :
8b. merge the branch back to the local master branch
8c. push the new updated local master branch to the reference Apache
repository
9a. How to locally "uncommit" (?) files?
Just remove them and commit the removal (this commit and the preceding
ones can be collapsed in the following step).
9b. How to change the commit log?
When you merge the development branch back to the master branch, you can
use
the flag --edit to change the commit log, and you can use the flag
--squash to combine
everything into a single change.
If you want to pick up several commits one by one, and ignore a few of
them along the
branch history, then instead of a merge you can use git cherry-pick to
select exactly
the parts of the changes you want to include in the master branch.
9c. How to "unstage" (?) files?
Before the commit, this is done using "git reset HEAD <filename>". If
the file
has already been committed, you should "git rm" and commit the removel.
10a. How to see/select what will be "push"ed?
What is pushed is simply the commit themselves. You can review them with
"git log" and
its numerous options.
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?]
The more I think about it, the more I think the behavior is intentional,
as it is not straightforward to get the full list of files from previous
commits. It is not a bad thing IMHO as the merge is a good place to
summarize
all the changes done on the parents.
best regards,
Luc
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
