Xen schreef op 25-05-2017 9:29:
The only thing I really require is a clean index that is independent to
myself.
What I meant here really is three things:
- I assume only the .gitmodules file needs to be updated in the parent,
so a clone or worktree checkout with only that one file would probably
create the clean working directory and clean index required for that
commit
- anything more advanced is just not required here
- in lieu of any "separate" location to do this in, only locking would
be a viability. I was just asking if locking a local copy in Git is
possible. If the roundabout way to do this is to create a worktree
clone, that is also viable, it is just more work.
That's all really.
I think that if I experiment with the worktree I get an easy solution, I
was just meaning to reduce the amount of code I am writing (it is
already so much :p).
That script I wrote now already sends 3 kinds of emails and uses my own
specific "medium" style formatting (but without the Date, since I guess,
I don't need a reason for it, it just doesn't have a date in the log
output :p) that I took from StackExchange which I don't like:
commit %H%nAuthor: %an <%ae>%n%n%w(0,4,4)%B
since I couldn't find the format for "medium".
which was that %w(0,4,4) but how to find out? lol.
The %w thing had the *least* amount of documentation.
I need to integrate two of the emails though since they are basically
the same except for the subject.....
I spent at least 2 hours trying to find out how I could beat postfix
until I realized the rewriting of the sender address was done on the
relay (smtp) host and not my own... :p.
My script sends emails using local addresses and then they get forwarded
to a "real" address.
But my local postfix needed to know about that local domain of course...
In any case the purpose of this thing... well whatever.
In this case the parent repository is not meant to be using code from
the subrepository. I just want them to group them.
The submodule feature is apparently only meant as a "consumer" thing,
ie. much like Apache Maven downloads all kinds of dependencies, you are
not meant to modify those dependencies.
So the submodule link-ins are not meant to see any real work done in
them.
By contrast I am working in them which is why I want the parent ref to
always be up to date. The parent in this case does not need a "specific"
commit, I just want it to get out of the way.
If --ignore-submodules is set to all the parent would not bug you with
it, but any checkout (cloned recursive whatever) would then not check
out the latest copies, which would be annoying.
So I am happy actually that this git version DID bug me with it :p.
I don't even want to know, like I said, what kind of nightmares can
occur with submodules.
I have only one project currently that uses an actual submodule as part
of the tree.
Which is basically an addon and not even required, so there are not
actually any dependencies between them :p.
If I needed specific commits then I would not do this but this means you
become a consumer.
That means you really need to work on your submodule elsewhere.
At that point it makes sense to lag a little behind the submodule...
But Git is like some ongoing exploration and it takes a while before you
learn all the pitfalls to any thing you want to do.
Much like as if everyone needs to go this road alone.
It would be nice if the implementation was less open and less plumbing
would be exposed.
Someone (a guy named Amber) wrote a piece on all the pitfalls.
I'll deal with them when I get there.
No need now.
--
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.
