commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc <...@spaceroots.org>
Subject Re: [Math] Filtering message from git?
Date Tue, 04 Nov 2014 14:27:49 GMT
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 <erans@apache.org>
>>>>> Authored: Sun Nov 2 23:22:11 2014 +0100
>>>>> Committer: Gilles <erans@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 <erans@apache.org>
>>> AuthorDate: Sun Nov 2 23:22:11 2014 +0100
>>> Commit:     Gilles <erans@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message