If you want to know the use case, both main and submodule are part of some
bigger project. Some components were split into submodules because they're
generic enough they can be re-used in different project (in the future),
however everything is being developed in parallel.
So project master always depends on most recent submodules. Indeed particular
release (tagged) (may and probably should be) pinned to submodule sha, but
during daily development updating sha every time I update submodule, would just
introduce too many meaningless commits in main repo.
That's why "ignore = all".
Adam Strzelecki | nanoant.com | twitter.com/nanoant
Wiadomość napisana przez Philip Oakley <philipoak...@iee.org> w dniu 18 cze
2013, o godz. 21:23:
> Which is the command(s) you are using that needs the "ignore = all", or is
> that figurative?
> From my viewpoint I would have thought that you would want to know which
> version of the submodule was being used at any step so that you can go back
> to any point in history and be sure that the submodule was the same version,
> rather than a moving target. Tha assumes that sub-module is part of the
> project rather than ancilliary details (e.g. one part is a renderer, and the
> other is the latest scenery to be rendered, as opposed to a render and a core
> function libray)
> ----- Original Message ----- From: "Adam Strzelecki" <o...@java.pl>
> To: "Philip Oakley" <philipoak...@iee.org>
> Cc: <email@example.com>
> Sent: Tuesday, June 18, 2013 4:23 PM
> Subject: Re: [git-users] Submodule tracking remote master shows modified on
> super project git status after submodule update --remote
> Thanks a lot for detailed info. For now I'll keep using "ignore = all" :>
> Adam Strzelecki | nanoant.com | twitter.com/nanoant
> Wiadomość napisana przez Philip Oakley <philipoak...@iee.org> w dniu 18 cze
> 2013, o godz. 00:23:
>> http://bec-systems.com/site/1020/git-submodules-can-now-track-branches may
>> be of help.
>> Noting this toward the end:
>> "This functionality is purely a convenience feature in the submodule update
>> command. In the actual repository, Git still stores submodules pointed to a
>> particular commit."
>> Have a read.
>> ----- Original Message ----- From: "Philip Oakley" <philipoak...@iee.org>
>> To: "Adam Strzelecki" <o...@java.pl>
>> Cc: <firstname.lastname@example.org>
>> Sent: Monday, June 17, 2013 10:15 PM
>> Subject: Re: [git-users] Submodule tracking remote master shows modified on
>> super project git status after submodule update --remote
>>> ----- Original Message ----- From: "Adam Strzelecki" <o...@java.pl>
>>> To: "Philip Oakley" <philipoak...@iee.org>
>>> Cc: <email@example.com>
>>> Sent: Monday, June 17, 2013 6:49 PM
>>> Subject: Re: [git-users] Submodule tracking remote master shows modified on
>>> super project git status after submodule update --remote
>>>> The super project 'git status' will tell you if any of it's parts have
>>>> been changed, and that includes, the status of the sub-directories that
>>>> are sub-modules - and you just said that it had been updated.
>>> Yes they were updated, but their HEAD still is equal to what .gitmodule
>>> "branch" is set to. I would expect it didn't show any modifications then,
>>> unless submodule header != .gitmodule "branch".
>>>> Importantly, sub-modules are "never" on a branch, they are (normally)
>>>> checked out at a specific commit (remember the bit about fixed libraries),
>>>> so that may be part of your problems - It takes a bit to get though all
>>>> the manual pages and even then, understanding doesn't always convert to a
>>>> useful working practice.... [aside: I still battle the msysgit/git
>>>> sub-module structure]
>>> So it makes "branch" setting introduced in Git 1.8.2 just a hint for git
>>> submodule update --remote, and nothing more (unfortunately), right?
>>> Then well this isn't really useful if I need to manually update submodule
>>> tracked SHA1 anyway whenever branch gets updated :(
>>> Adam Strzelecki | nanoant.com | twitter.com/nanoant
>>> Hi Adam,
>>> Looking through the documentation history in the History tab
>>> https://github.com/git/git/commits/master/Documentation/git-submodule.txt I
>>> don't see anything that changes the basic underlying behavior about having
>>> a specific commit checked out, but there are updates with the --branch
>>> option for fetching updates.
>>> The super project git tree needs to know the exact version of every part of
>>> the tree, including the sub-modules, to do a commit, so if your update of
>>> the submodule means you have a newer version, then yes, status will show
>>> that change (of checked out commit sha1 id). The ability to get updates
>>> easier for sub-modules doesn't mean that verification/validation recording
>>> has gone away.
>>> If you truly want those new sub-modules updates in the tree then yes, it is
>>> an uncommitted change.
>>> But, it is easy to accidentally misunderstand and talk past each other on
>>> sub-modules... perhaps a short command history. or an example sequence that
>>> can recreate your concern would help clear any misunderstanding.
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3345 / Virus Database: 3199/6419 - Release Date: 06/17/13
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.