Don't remove .gitmodules if there're other modules

[ForNeVeR]

Consider that I have a repository with multiple submodules like this.

After I run git-submerge cscctest, it deletes the .gitmodules, but there're other modules I also want to import!

I think that git-submerge should just remove a reference to the merged module from .gitmodules, and it should remove a .gitmodules after that only if it's empty.

[Minoru]

Hi! Sorry for taking so long to respond—I got buried under some work and life commitments.

I planned for git-submerge to be smarter about .gitmodules, but took a shortcut in 362825d so that I could release 0.1 faster.

This project is discontinued and I don't have any plans to revive it. Are you absolutely sure you need it? Have you considered alternative approaches I describe in my blog post?

[ForNeVeR]

Sorry for taking so long to respond—I got buried under some work and life commitments.

That's never a problem, thanks for reply!

This project is discontinued and I don't have any plans to revive it.

Yes, I understand. That doesn't mean we shouldn't file issues though!

Are you absolutely sure you need it?

As far as I currently understand: yes.

Have you considered alternative approaches I describe in my blog post?

I have read your post. It seems that git-submerge is still the only option if I want the "Pretending we never even had a submodule" way?

Also, I'm curious: why was it discontinued? Have you found any blocking issues, or do you just no longer need it?

[Minoru]

> Have you considered alternative approaches I describe in my blog > post? I have read your post. It seems that git-submerge is still the only option if I want the "Pretending we never even had a submodule" way?

That's correct.

Also, I'm curious: why was it discontinued? Have you found any blocking issues, or do you just no longer need it?

Just no longer need it. It was a proof-of-concept written to solve a specific issue I had at work. A few days after publishing the post, I realised that "one repo, multiple histories" approach is sufficient for me, and it's less intrusive so is 1) easier to implement, and 2) harder to implement incorrectly. I went with that, and git-submerge was discontinued. git-submerge requires a lot more work to become truly useful and useable, and I just don't have any motivation to do that work now. Do you want to take over? I'm happy to transfer this to Codingteam or wherever you want. Also okay with answering some "WTF?" questions—current implementation is more like an overblown shell script than an actual program, one will probably need some guidance to understand some of the decisions.

[ForNeVeR]

Yes, I'd like to revive the project. I'm sort of PL librarian/archaeologist, and I often have to deal with old repositories full of odd things like submodules nobody actually use. So I need significantly more tooling to deal with these cases, and git-submerge looks like one of these tools I could use. Could you please transfer the project to me?

(Don't want yet to involve Codingteam because it looks like the project will have only one active ct-related maintainer, myself.)

[Minoru]

Could you please transfer the project to me?

Sure! But first, you'll have to remove the fork you made when you worked on Windows build for git-submerge :)

[ForNeVeR]

Done.

[ForNeVeR]

Alright. According to my investigation, we should be able to call something like

$ git config -f .gitmodules --remove-section submodule.$submodulename

And it should remove the submodule info without touching anything else in the config. Will investigate how to call that through libgit2.

[ForNeVeR]

I've solved my task at hand using this bash script, so I'm not currently interested in the solution of this issue with .gitmodules.

Here's what we've got so far: I've created a branch feature/33-gitmodules and pushed my implementation of .gitmodule editing subroutine.

The feature is still not implemented because of that: that code removes the .gitmodules file from the repository, although we need it to edit the file instead.