Hi.
On Tue, 04 Nov 2014 15:27:49 +0100, luc wrote:
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.
The example below, I actually meant as belonging to that document to be
created
in the "doc" directory of the code repository.
I did not really need the information right here right now. ;-)
[I have some comment, perhaps to clarify the proposed document.]
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 (?)
This should certainly be explained, e.g. if it's best to create one
branch for
each feature, or one branch (a bug fix) that depends on another (design
change
needed to fix the issue, but independent of it).
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
Example of explicit command, e.g. based on the 2-branch scenario above.
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).
Wouldn't that create yet another layer of insignificant changes: Rather
than have "nothing" in the history, we'd have a log of
1. File creation
2. File removal
for a file that would have never existed on the reference repository.
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.
Ah, that's very important, in order to limit the flow of automatic
posts to this ML.
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.
How to be sure that nothing would be missing from the reference
repository (e.g. local changes make it possible to compile locally,
but will fail remotely)?
Is it possible to create another "view" (a branch?) of the local
repository
with only the "cherry-picked" selection?
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.
Does this keep local changes?
While "git checkout -- <file>" would wipe out any trace of changes?
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.
I had mentioned that it was not obvious because "git diff" shows the
diff
before the files are committed, but afterwards, you have to add the
name
of the reference (branch?).
So, will you set up a "git CM mini-howto"? :-)
Thanks,
Gilles
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
