Moose commit history

[singhgp4321]

Hi,

I noticed that the commit history of moose submodule in Bison app is different for different versions of moose. Of course the latest version of moose will have additional commits, but for the common time range some of the commits found in one version of moose are not present in the other version of moose.

I am wondering if someone could explain why the commit history for moose differ from version to version. I can provide additional information if needed; let me know.

Thanks,
Gyan

[loganharbour]

We utilize the method of continuous integration when developing MOOSE and the MOOSE-based applications (see this wikipedia article for more info). We update the software many times a day, and when testing passes for a change in MOOSE, we update many of the MOOSE-based applications on the same day once their tests pass with the changes to MOOSE. This allows us to get updates to applications as soon as possible, whether it be bug fixes or new features.

The master branch of BISON has its MOOSE submodule updated once all of its own tests pass with the new changes to MOOSE. With this, you can grab any commit of BISON, and have a version of MOOSE (noted within the submodule) that is guaranteed to be compatible.

This is why you will see the MOOSE submodule within BISON (and many other MOOSE-based applications) change quite a bit: we update BISON as soon as reasonably possible with newer versions (more recent commits) of MOOSE.

Bottom line: whenever you update an application, be sure to update the MOOSE submodule if it has one!

[loganharbour]

We never rewrite history.

The only time I could see this is an issue is with a manual submodule update with a commit that comes from a PR instead of within next/devel/master. Github is smart enough to let you use a sha from a PR when pulling from a repo. That sha could no longer exist.

It shouldn't be hard to write a quick python script to parse the log and find these. I don't know if this is the issue, but this is the only case I could think of. If this is indeed the problem, we should cause prechecks to fail if the hash isn't associated with moose/next.

[GiudGiud]

That'd be great.
Just a side note that the dates are generally not linear, not just if commits have been amended. Rebasing for example will keep the original dates of your commits, yet place them all at the end of the log.

[singhgp4321]

Here are the commit histories for two versions of Moose for two corresponding versions of Bison. You'll notice that Jan 4 commit shows up in one version's commit history but not in the other one: moose_commit_histories.txt

[GiudGiud]

If you checkout 59f7e5b and look at the log you will find all the commits that are in your text file. You might have to go a bit far in the log, I recommend using git log --pretty=format:'%h : %s' > log.log

From git log at the first commit in your file, the January 4 commits in bold.

59f7e5b : Merge commit '44404267f136d11f3a09c8220ea98c6d4f809034'
4440426 : Merge pull request #16618 from lindsayad/check-leaks
96a63b8 : Merge pull request #16404 from crswong888/listing-improvement-16401
2e197b2 : Merge pull request #16588 from aeslaughter/reporter-declare-initialSetup-16586
3164e97 : Update libmesh
bb9d19b : Only populate attributes if supplied and reincorporate the attributes override into listing extension
310686b : Updated documentation for listing extension
9fc3b35 : created unit tests for listing extension
ba6897e : change names of 'prefix' and 'suffix' settings to 'prepend' and 'append' in extractContent() to avoid conflicts
56dd034 : Fix bug with float numbers - reset counter on every tokenization so that it doesn't accumulate during a live serve, which leads to higher and higher numbers.
aea2874 : Execute pre- and post-read methods for MooseDocsTestCase
3b70222 : Removing listing gold
ba54103 : more refactoring of listing extension
9f4a6a0 : Re-factor ability to remove blocks and params from hit files
e163c9f : listing extension can now exclude blocks and parameters that otherwise would be rendered
e572e43 : Merge pull request #16157 from lindsayad/isnt-prepared-mesh-api
eec233d : Merge commit '3877bd279e97bab2a579b926ecd33a543ea2fa2a'
211f7da : Initialize output lists for each call to output
e010c68 : Create test to demonstrate issue #16586
44a89d7 : Merge pull request #16570 from loganharbour/modules_unit
46327bf : Use MeshBase data to inform us when we should prepare
198485f : Add test
f9af866 : Merge pull request #16397 from lindsayad/auto-full-matrix-16396
3877bd2 : Merge pull request #16463 from cbolisetti/csvsampler
8444a70 : Merge pull request #16527 from milljm/16513-moose-pyhit-tlc
071d529 : Merge pull request #16475 from arovinelli/nl_forced_its
e5cb79c : Merge commit 'bbd2e27f25001c4834201d1d3ff5bb4fae46c84e'
bbd2e27 : Merge pull request #16597 from loganharbour/pandas_update
b319bbd : Resolve comparison warnings for stochastic tools unit tests
6b0743b : Resolve comparison warnings for porous flow unit tests
da567e7 : Resolve comparison warnings in geochemistry unit tests

[singhgp4321]

Thanks Guillaume for the clarification! Yes, I do see the Jan 4 commits after going far down in the log; for some reason I could not view the log down enough earlier. Also, I am realizing that git log isn't the best way to look at the log. The pretty and graph arguments provide a much cleaner and clearer history of the commits. git log --since "JAN 01 2021" --until "JAN 14 2021" --pretty=format:"%h %cd %s" --graph provides what I was looking for. Thanks!