commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Filtering message from git?
Date Tue, 04 Nov 2014 15:08:53 GMT

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
>>>>>> Project: 
>>>>>> Commit:
>>>>>> Tree: 
>>>>>> Diff: 
>>>>>> Branch: refs/heads/master
>>>>>> Commit: 7df65a5ddf59b564af1d753b89d30f8dc33a2c5d
>>>>>> Parents: 4a6bf54 45ae5c7
>>>>>> Author: Gilles <>
>>>>>> Authored: Sun Nov 2 23:22:11 2014 +0100
>>>>>> Committer: Gilles <>
>>>>>> Committed: Sun Nov 2 23:22:11 2014 +0100
>>>>>> ----------------------------------------------------------------------
>>>>>>  src/changes/changes.xml                         |  3 +
>>>>>>  .../math3/ode/        | 71
>>>>>> ++++++++++++++++++--
>>>>>>  .../math3/ode/sampling/    | 28 ++++++--
>>>>>>  .../math3/ode/    | 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 
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 
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 
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 
before the files are committed, but afterwards, you have to add the 
of the reference (branch?).

So, will you set up a "git CM mini-howto"? :-)


>> 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 <>
>>>> AuthorDate: Sun Nov 2 23:22:11 2014 +0100
>>>> Commit:     Gilles <>
>>>> CommitDate: Sun Nov 2 23:22:11 2014 +0100
>>>> Merge branch 'master' of
>>>> 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 and not
>>>> 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:
For additional commands, e-mail:

View raw message