On 1/1/16 Jan 1 -6:18 AM, Kambiz Darabi wrote:
On 2016-01-01 09:59 CET, Kambiz Darabi darabi@m-creations.com wrote:
Happy New Year,
On 2015-12-31 16:12 CET, Robert Goldman rpgoldman@sift.net wrote:
On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
On 2015-12-29 01:58 CET, Robert Goldman rpgoldman@sift.net wrote:
The problem of having clones not get auto-populated seems not worse than needing to do a magical incantation when you merge stuff back and forth at the cost of garbling your repo.
The complete magical incantation reads:
git subtree add --prefix=ext/alexandria --squash https://gitlab.common-lisp.net/alexandria/alexandria.git master
and to update it to the lastest master, replace 'add' with 'pull'.
The submodules cause annoying quiet failures, but even when the annoying quiet failures happen, you don't end up mangling your repo.
The problem with submodules is that every single person who checks out the repo is concerned with it, whereas git subtree has to be performed only by one single person and for all others it just works without them even knowing that there is a 'subtree' being used somewhere.
Can you explain that stuff about needing to squash? I read the subtree tutorial and that discussion just seemed like gibberish to me. Very far from clear. Maybe it's easier than the discussion made it seem. As I read it, it seemed to be saying that if you didn't remember to do --squash at the right times you would end up with a repo clogged with duplicate commits.
If that's the case...ugh. But perhaps it was just a bad explanation? Or does your subtree add expression above ensure that the squashing becomes the default?
My command above does contain the '--squash' option. The git-subtree author just chose the wrong default: usually, you are not interested in seeing each and every commit in the external repo.
But again, if you do the wrong thing, it's just a matter of:
git reset --hard HEAD~2 git subtree add/pull --squash ...
If we could figure this out maybe subtrees would be easier. But if you have to remember to squash every time, forget it....
IMO such commands should be automated with a makefile entry, so you wouldn't have to remember the --squash option.
Unfortunately, right now the makefile is in the worst condition of the whole project, because of the recent merge of minimakefile, which by its nature was largely untestable (since exercising its functionality would change the repository, and even the upstream repository).
Indeed, just recently, I wasn't able to use the makefile to fix my problems with the addition of new ext/ submodules because..... the makefile didn't work until the submodules were added.
I pushed a branch to my repo which contains the necessary changes:
https://gitlab.common-lisp.net/darabi/asdf/tree/ext-subtree
The specification of what to get where and which version is in ext/dependencies.lisp-expr
and
git checkout ext-subtree make ext
does the job.
I'm happy to consider switching to using git-subtree. It may indeed be better.
But not until it gets some better documentation. The discussion in the Pro-Git book, to be honest, just makes my head hurt. See https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
So, the remote repository is added as a remote for the *containing* repository? ASDF would have the cl-scripting as an upstream remote for ASDF, not for a contained thing?
And this
"Then, you can merge those changes back into your master branch. You can use git merge -s subtree and it will work fine; but Git will also merge the histories together, which you probably don’t want."
...may mean something to the person who wrote it, but it really doesn't mean anything clear to me.
The whole section is like this.
I am grateful to the author of this book, and I know documentation is hard, but this simply doesn't rise to the level of an explanation. I suspect that the problem is that giving a real explanation would require standing up repositories both with and without the use of git subtree and showing by worked example what is meant by merging histories together.
Also, it seems like if you forget to use --squash merging and then push the results to the main (cl.net) repo, you end up messing up the ASDF repo's history in an unrecoverable way. That seems too risky to me. Yes, *if you notice* you can undo it with a git reset, but if you *don't* notice, and you push, what happens then?
Best, r