let's think ~/.gitignore.d through

[Dieterbe]

do we really need the bakfiles for seed-gitignore? some arguments why not:

• if the user invokes this command, he could expect that his files will get overwritten
• user has $HOME/.gitignore.d/* in git anyway (or at least should have)
• if user is going to have a tool automatically maintaining a file, putting manual stuff in there is pointless anyway
• maybe we could add a -f flag to force overwrite, but still this doesn't seem like a natural approach (read on).

some arguments in favor

• .bak files can easily be gitignored (although, if he has $HOME/.gitignore.d in git, he uses vcsh to manage it, is there a way to maintain ignore files that are not overridden by git-seedignore?
• maybe the gitignore.d dir should contain for each repo 2 files: .manual and .auto the autofile can be automatically rewritten by vcsh and needs no backing up, and vcsh wouldn't touch the manual files. it however create a new file .merged, or something which simply contains the sum of both files. (which is basically a work around for git's lack of multiple ignore files)

the latter is maybe the best solution: it removes the need for backupfiles completely, and allows users to maintain their own gitignore rules safely.

[RichiH]

$VCSH_BASE/.gitignore.d is the only place that works:

• It most closely resembles git's .gitignore
• Users may have $XDG_CONFIG_HOME set to different locations on different machines or several users may use one repo. vcsh could not handle this without softlinks or other hacks

Thus, $VCSH_BASE/.gitignore.d is the only place that makes sense. I could make this a config option, but I doubt this is useful and only serves for people to shoot their own feet.

[Dieterbe]

this ticket has nothing to do with the location of the gitignore.d location.

[RichiH]

After some (hrhr) deliberation, I agree with your point.

Do you want to take a stab at it? Else, I will put it onto my TODO pile.