Gergely Polonkai schreef op 24-05-2017 22:33:
Still, you seem to want solving a problem with Git that is not in Git's
domain.
It is possible that updating a submodule also requires updating files
in the main repository (e.g. due to changing interfaces), so Git should
allow changing both the submodule and the main repo's files.
I am not talking about what Git should allow or should not allow. I am
not asking about a way to fundamentally separate parent regular commits
and parent SHA updates for a submodule.
If you say the issue should be resolved at a later stage by developer
review then you are merely postponing the decision; but both, whether
you do it ahead of time or after the fact, are process related
questions.
It is the process that uses the tool. Whether the process uses the tool
ahead of time or after the fact is irrelevant; that is just a difference
of moment.
If the process can ensure a split ahead of time, it does not need to do
so after the fact.
It saves human resources if the process can do this automatically.
There is no point in disallowing the process the ability to do this
ahead of time.
The whole point of automation is to save human resources.
I am not asking for a Git that can fundamentally or would always
fundamentally refuse to mix two kinds of commits, I am asking for the
tool USER to ensure this outcome in THIS PARTICULAR CASE.
It is really just a plain concurrency issue.
I understand your question well. In a centralised version control
system I would agree you need to do such things. But Git is
distributed, and this also means in your local copy you can do whatever
you want, as possible upstream/peer repositories won't always see such
changes.
I was not talking about peer or upstream repositories.
So it comes down to the process you have, even if you develop alone
(actually you aren't; you work together with past and future you).
I was just talking about my local copy.
Make yourself not to commit submodule changes with code changes.
The whole point is that there is a concurrent process doing that. So the
question becomes how I can prevent a concurrent process from modifying
my index and worktree. Generally this is called locking.
Now the only way I can think of doing that is to create some kind of
worktree copy that would check out the current master of the parent and
check out the current master of the child directly, and create the
commit in that worktree.
I would assume that the worktree would have an independent index and
independent work directory (obviously).
The only thing I really require is a clean index that is independent to
myself.
--
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
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
