Follow

advice please?

in my .git folder, there are trash files, sync-conflict created by . Usually I delete these in other directories and move on. Will deleting these files inside .git mess git (and my remote repo) somehow?

Also: I want to create a local copy of my repo. The idea is to have one for my live site, one for experimental site. Is there a way to do this locally without copying the files I want &leaving the git ones out? I want 2 different repos on local and on the remote.

· · Web · 3 · 0 · 0

Here's a picture that explains the issue better.

For example, .git should have index, but all the other index.sync-conflict should not. These are created by Syncthing and I want to be sure they're OK to delete manually (think rm) without screwing up git.

@jrss git does not "care" about the ".sync-conflict*" files and they can be safely deleted. If you want to be doubly sure, move them out into a temp folder, use git to verify functionality, and then delete.
I also use syncthing to sync repos and the rare conflict file is kind of a nuisance.

@jrss not sure I follow the intent behind the copy of the repos. You want to have an full copy of the repo in another local location without the `.git` folder? I imagine you want this folder to stay up to date with the repo contents?
If I understood correctly then one way would be to write a script that makes a copy to your chosen location that is triggered by a git hook.

@shom @adamsdesk

I think I made this more complicated than it is.

So, I have my hugo blog on gitlab. I want to have another hugo blog, essentially an exact copy, on which I can experiment on.

It will be the same set up with netify etc, only it won't have a a .com domain. This way I can play with shortcodes and css and what not without screwing the real site.

What I think: copy the files I have locally on my machine to another folder, then create another git there, and push to gitlab.

makes sense?

@shom @adamsdesk if it does make sense, the only thing i *don't* want to copy over is the .git folder, because I want to create a new one....

does this still make sense? lol

@jrss ah I see, you want a staging site. I have a slightly different suggestion. I would treat your main repo as the upstream and "fork" it to your experimental repo that way you'll have the full common history. Then you can experiment in your fork and if you want to include anything in your main repo you can just treat it as a pull request from your experimental fork to upstream. Then there's no copy pasta, all git!

Does that make sense?

@adamsdesk

@shom @adamsdesk

Yes.... I'm "afraid" of git, see.

Last time I branched out, I messed it up and couldn't get back to my master, my website didn't update, I think I had to do a hard reset with help and.. yeah.

I use magit and I keep to only stage, commit, push. That's it.

Yes, I know it doesn't make sense. I have weird issues what can I say

@shom

Oh! also. I the repository in gitlab is private. If I just branched out to an experimental, it doesn't change that, right?

I am trying to have a couple of hugo folks looking into an issue and they need access, so I guess that means a new repo?

@jrss making a branch won't change the privacy setting but others won't be able to see that the new branch. So yes, you would need to make a new repo (you can use same process in my other reply, steps 1-3).
Just curious why the repo needs to be private since the website itself is public?

@jrss ha, everyone has weird issues, just different ones. Since you're a magit user, you can do stuff pretty easily without worrying about branching, if you wanted to:
1. create a new experimental (dev) repo in gitlab
2. add the new repo as a new remote to production (prod)
3. push the prod code to dev remote
4. clone the dev as a new repo and play around in that and push when you're happy
5. go back to prod repo and pull from the dev remote to take those new changes

@adamsdesk

@jrss I'm not sure I fully understand. However just use a got hook to copy it to another location automatically.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!