|
New Yorp New Yorp posted:Git (and dvcs in general) is 100% the wrong tool for this job. Beside being insanely complicated, it's unsuitable for storing revisions of non-text assets. Why invest the effort into shoehorning a tool to work with content types and work flows for which it is, by design, wholly unsuitable? Aside from the complexity, what do you think are the biggest drawbacks for it? If you worked off of it in a compatible format like Markdown which then could run a pipeline to use pandoc or something else to convert it to whatever other format you need, would it not work to show those kind of revisions? I thought "by design" Git is used to store complicated revisions of text (code). If you were say, a collaborative team of researchers writing out a complicated paper, wouldn't the complexity of the tool be worth the added tracking of revisions, commentary and the ability to branch? Or say legislators/governance teams or whatever drafting complex policy/legal docs but want to be able to allow for contributions without fear of it messing up their originals (I guess Wikis have version control too but in highly bureaucratic organizations getting "approval" is sacrosanct unfortunately) and who need precise tracking of revisions? Only other document management tools I've used is something like SharePoint which requires you to "check-in" entire document or "check-out" entire documents, but this completely prevents concurrent work. I guess merging together different branches could be difficult if you were collaborating off something line by line but couldn't Git merge easily enough text documents that different people were working off of say, different entire sections? Also interesting would be to use some of the language-based linters people have developed that can automatically scan for things like style guides (i.e. readability, plain language use, lack of passive voice, etc.). Maybe I'm conflating Git to just mean being able to do "version control with branching" along with using Markdown for What You Say Is What You Mean (WYSIWYM) so that you can focus on just the text and let automation handle all the templating and formatting junk that people get stuck in when writing in MS Word. Definitely agree that using Git as-is would be too clunky for this, so thats why I'm curious if anyone's modded something like Gitlab, stripped it away of the unnecessary parts and re-built it with things like a rich text markdown editor that could be used in MRs.
|
#
?
Jul 27, 2022 13:01
|
|
|
|
| # ? Apr 27, 2024 15:31 |
|
|
Oysters Autobio posted:If you worked off of it in a compatible format like Markdown which then could run a pipeline to use pandoc or something else to convert it to whatever other format you need, would it not work to show those kind of revisions? Your average non-technical document author is not going to be using Markdown (or Latex). They're going to be using Word or some other binary format. For anyone technical enough to be using an actual diffable text format, just learning enough Git to be dangerous is enough. This seems very much like an idea that doesn't have an audience combined with every problem looking like a nail.
|
|
#
?
Jul 27, 2022 18:38
|
|
|
New Yorp New Yorp posted:Your average non-technical document author is not going to be using Markdown (or Latex). They're going to be using Word or some other binary format. For anyone technical enough to be using an actual diffable text format, just learning enough Git to be dangerous is enough. Yeah I guess you're right. I just want people to stop emailing random ad-hoc versions of Word documents, so the appealing parts of Git is the centralization, "single source of truth" and version control but none of those things are super unique to Git. Unfortunately, most corporate enterprise document management software out there is just garbage so instead people are back to shared drives and email. I'm just gonna try and get people to use Confluence at least, thats maybe an achievable goal.
|
|
#
?
Jul 28, 2022 02:12
|
|
|
Oysters Autobio posted:Yeah I guess you're right. I just want people to stop emailing random ad-hoc versions of Word documents, so the appealing parts of Git is the centralization, "single source of truth" and version control but none of those things are super unique to Git. I’m happy using Git with LaTeX for technical documents (Overleaf even has nice GitHub integration), but there’s no way normal people are going to work that way. Asking non-programmers to learn git is particularly insane. Office 365 basically does what you ask for already, though. It keeps track of (and let’s you compare or roll back to) different versions of the same document, and stores all of that information in a centralized place with one “single source of truth.” It’s not Microsoft’s fault if your org isn’t using it! I doesn’t have great ways to do things like branches or merges, but it’s pretty cool and fairly seamless to collaborate in real time with other people.
|
|
#
?
Jul 28, 2022 02:44
|
|
|
Does anyone have a "recipie" for moving a file from one git repository to another, in addition to the commit/revision history of that file (including past names since the file I'm looking to move has been renamed). I can find various guides saying various things, but they all seem to be for slightly different situations I'm in. I see lots of guides on moving a subfolder, but I don't want to move a whole subfolder, just a single file. That single file also happens to be in the root of the repository. The things I do find don't have much explanation around what each step is doing, so I'm having a hard time even modifying them to work with my situation, because I don't understand what they're doing in the first place.
|
|
#
?
Sep 12, 2022 17:31
|
|
|
FISHMANPET posted:Does anyone have a "recipie" for moving a file from one git repository to another, in addition to the commit/revision history of that file (including past names since the file I'm looking to move has been renamed). Assume you have RepoA that you want to keep and RepoB that you want the file from: git clone repoB git filter-repo --path thefileyoucareabout git push git clone repoA git remote add repoB repoBURL git merge repoB/master That should do it?
|
|
#
?
Sep 12, 2022 17:44
|
|
|
I want to keep both repos, but I think that would destroy repoB?
|
|
#
?
Sep 12, 2022 17:51
|
|
|
FISHMANPET posted:I want to keep both repos, but I think that would destroy repoB? RepoB still exists unmolested from wherever you cloned it… Edit: can. Instead of pointing at the remote RwpoB from RepoA point at the local .git folder. Don’t push RepoB to it’s origin.
|
|
#
?
Sep 12, 2022 18:06
|
|
|
I have a coworker who has changed their name, and would like to not see their old name in git commit graphs, Azure DevOps file history, etc. where they were the author of those commits. Adding a .mailmap has addressed some other instances of this (e.g. git log) but is not respected most of the time it seems. This is for a large codebase with several years of commit history, and all of the options git provides here seem dangerous. Is there any third-party tooling anyone can recommend that solves this problem?
|
|
#
?
Oct 12, 2022 12:49
|
|
|
You could put a wrapper around git-blame to iterate through .mailmap and replace the field? Using porcelain if necessary. Looking it up it seems plenty of people have said that they've just had to live with being deadnamed in version control, which is a little depressing.
|
|
#
?
Oct 12, 2022 13:09
|
|
|
Changing the author name on a bunch of commits and then having everyone rebase their in-progress stuff on top of the new history is conceptually pretty simple, but coordinating it seems like a nightmare if you have more than a handful of people touching the repo.
|
|
#
?
Oct 12, 2022 16:39
|
|
|
https://www.git-tower.com/learn/git/faq/change-author-name-email/ right at the bottom, there's a bit about filter-branch that should do what you want. Same warnings about editing shared history, though - the author information is included in the commit SHA, so every time you change this you're creating a brand new commit and git will have to recreate every descendant commit. Basically, it's 100% doable, but they'll have to have big time buy in from their team (or whoever owns the repo). Honestly, I'd assume that unless you're at a particularly progressive workspace, they're gonna have to live with being deadnamed
|
|
#
?
Oct 13, 2022 14:14
|
|
|
Yeah, I've read that already - and also some additional stuff that warns against using filter-branch for perf reasons. My workplace is reasonably willing to entertain a fix for this, and small enough that I could reasonably ask everyone to check in their work at the end of the day for me to make changes - was just hoping this was more of a solved problem
|
|
#
?
Oct 13, 2022 15:22
|
|
|
JawKnee posted:was just hoping this was more of a solved problem Seems pretty solved to me. It's an unusual* requirement and the tool supports it if you really need to do it. *I know people change their names when they get married all the time but it's just generally accepted that "we'll do it if it's not too much of an inconvenience" is the general attitude there; this is a case where I expect there would be significant backlash if the "too much effort, deal with it" attitude were invoked.
|
|
#
?
Oct 14, 2022 03:09
|
|
|
What tools aren't respecting mailmaps?
|
|
#
?
Oct 14, 2022 03:58
|
|
|
New Yorp New Yorp posted:Seems pretty solved to me. It's an unusual* requirement and the tool supports it if you really need to do it. okay pseudorandom name posted:What tools aren't respecting mailmaps? The big one for the moment is Azure Devops. This manifests in the Files > Contents view of any branch, the commit history graph, and I'm sure some other places
|
|
#
?
Oct 14, 2022 15:47
|
|
|
Well, we ended up re-writing history. Took a while and some planning, and some organization. git filter-repo made making the changes themselves a breeze, with devops only being slightly annoying to handle
|
|
#
?
Jan 12, 2023 08:28
|
|
|
Related to the above, kinda: I have a local repo in a folder with something I put together, and now a team I work on wants me to add that stuff to a bigger repo as a folder (and then push it to the remote). How the gently caress do I do that? Repo structure: Repo A: in folder /repoA/ Has branches main and feature/do-poo poo Repo B: in folder /repoB/ Has main and origin/main branches What I want: Folders: code:I feel like git-filter-repo is the right way to do this, but my brain just isn't clicking with the docs. edit: To be a bit clearer, repoB has other branches and features, but they're very much localized to single project folders, and my new thing doesn't depend on any of that. SporkOfTruth fucked around with this message at 17:09 on Jan 26, 2023 |
|
#
?
Jan 26, 2023 06:35
|
|
|
And nobody wants to use a submodule? Is repoA going to change much in ways repoB either does or doesn't want? ie, do you want to let folks check repoA out on its own?
|
|
#
?
Jan 27, 2023 03:41
|
|
|
repoA is, for all intents and purposes, dead now outside the context of being used within repoB. I developed it entirely locally, and it will not be pushed to a remote ever, but the history needs to be preserved.
SporkOfTruth fucked around with this message at 04:54 on Jan 27, 2023 |
|
#
?
Jan 27, 2023 03:58
|
|
|
I have a similar situation, except it's more like wanting to make a monorepo of several projects that will continue to be developed. The plan I have right now is to move everything in each repo individually to a subdirectory as they should be structured after the combining, then replay the history of each repo into a new one, with branch names changed so they don't clash. Then at the end do an octopus merge between all the separate heads from each repo and end up with a single one. I'd rather not have to bother with rewriting the history of all the original trees, but prefer to preserve everything.
|
|
#
?
Jan 27, 2023 08:12
|
|
|
I’ve done that years ago with got bfg and it’s not bad. What you want to do is use filter repo or bfg or whatever to rewrite history such that the path was always /repoA/file1 instead of /file1. Then when you are done with that in repoB you add repoA as a remote called repoA. And finally git merge RepoA/master. Now all history from A is in B
|
|
#
?
Jan 27, 2023 09:17
|
|
|
This is very possibly a 'it's hard because you're not meant to do this' problem, though I'm not good enough at git to know for sure. We've got branches A and B, where B is quite far ahead of A. I want to make a new branch, C, that's based on A but also has commits from B if they were made by a certain set of authors. Their changes are spread throughout the repo. I can use git log to get the relevant commits without a problem. The issue is that there's several hundred commits I need to move over, and cherry-picking that many isn't ergonomic, since I have to manually fix a lot of merge conflicts that crop up. I took a look at https://github.com/newren/git-filter-repo, and while it lets you interrogate commits for the author name with the 'commit callback' flag, it doesn't seem to let you throw them away based on that. Any suggestions on the least-bad way to do this? Just suck it up and cherry pick everything?
|
|
#
?
Apr 25, 2023 13:42
|
|
|
Aren't both of these the same operation / will run into the same merge conflicts? Maybe you can mitigate the pain with git rerere but in principle you're starting with A and sequentially applying a subset of B either way, no?
|
|
#
?
Apr 25, 2023 14:46
|
|
|
Ruud Hoenkloewen posted:This is very possibly a 'it's hard because you're not meant to do this' problem, though I'm not good enough at git to know for sure. We've got branches A and B, where B is quite far ahead of A. I want to make a new branch, C, that's based on A but also has commits from B if they were made by a certain set of authors. Their changes are spread throughout the repo. I can use git log to get the relevant commits without a problem. The issue is that there's several hundred commits I need to move over, and cherry-picking that many isn't ergonomic, since I have to manually fix a lot of merge conflicts that crop up. If you always want B, you can do an interactive rebase, use -X to force a resolution strategy, and generate your todo list by simply tweaking your log output. If you don't always want B, then you can still do the interactive rebase, just manually fix merge conflicts instead of using -X.
|
|
#
?
Apr 25, 2023 15:24
|
|
|
Vanadium posted:Aren't both of these the same operation / will run into the same merge conflicts? Maybe you can mitigate the pain with git rerere but in principle you're starting with A and sequentially applying a subset of B either way, no? Semantically yeah, the difference to me is practicality. My hope was to find some command that'd zip through everything and just leave me with the codebase at the end, in whatever mangled state that might be. Hopefully that makes sense. raminasi posted:If you always want B, you can do an interactive rebase, use -X to force a resolution strategy, and generate your todo list by simply tweaking your log output. If you don't always want B, then you can still do the interactive rebase, just manually fix merge conflicts instead of using -X. I do always want B, so I'll give this a go and see how well forcing it to pick their changes works. Thanks!
|
|
#
?
Apr 25, 2023 18:37
|
|
|
Just started a new job, first week in. Cloned a repo and saw two developers committing to main - one with frequent, poorly worded commits, the other one having pulled, merged and discarded the other devs changes and pushed back up. So. Yeah. I don't really have a question I guess except maybe how justified am I to immediately and unilaterally lock down main and require PRs with mandatory reviews? Anywhere between Totally and 100% Absolutely, right?
|
|
#
?
Jun 4, 2023 00:48
|
|
|
TheBlackVegetable posted:Just started a new job, first week in. Cloned a repo and saw two developers committing to main - one with frequent, poorly worded commits, the other one having pulled, merged and discarded the other devs changes and pushed back up. 100% justified, 0% chance of it sticking "We can't get our work done like this we have to remove all this red tape" 
|
|
#
?
Jun 4, 2023 00:56
|
|
|
ChickenWing posted:"We can't get our work done like this we have to remove all this red tape" Don't dig up my past like this, except it was not sharing a single server root password in a google spreadsheet.
|
|
#
?
Jun 4, 2023 02:48
|
|
|
TheBlackVegetable posted:Just started a new job, first week in. Cloned a repo and saw two developers committing to main - one with frequent, poorly worded commits, the other one having pulled, merged and discarded the other devs changes and pushed back up. Maybe they have a separate "developed" branch that they merge into when they are ready to release the code they've developed? If everyone is a senior dev and depending on how the code is used, you can maybe get away with requiring PRs but not requiring approvals.
|
|
#
?
Jun 4, 2023 14:48
|
|
|
TheBlackVegetable posted:Just started a new job, first week in. Cloned a repo and saw two developers committing to main - one with frequent, poorly worded commits, the other one having pulled, merged and discarded the other devs changes and pushed back up. I mean, I'd start with a conversation about it, because as tempting as it is, doing something like this out of the blue as the FNG is going to define you to the people whose workflow you interrupt, and you're going to have an adversarial relationship with your teammates for a long time. You can make a strong argument about it, and maybe they'll be on board to improve the situation.
|
|
#
?
Jun 5, 2023 08:25
|
|
|
Che Delilas posted:I mean, I'd start with a conversation about it, because as tempting as it is, doing something like this out of the blue as the FNG is going to define you to the people whose workflow you interrupt, and you're going to have an adversarial relationship with your teammates for a long time. You can make a strong argument about it, and maybe they'll be on board to improve the situation. Never fear, I know well enough to approach carefully and avoid any sudden movements. At the moment I'm focused elsewhere but my job is in fact in a lead role, so I'll be dealing with this at some point - my current plan is to get them there gradually and lead by example as I set up the new services I'm working on.
|
|
#
?
Jun 5, 2023 09:36
|
|
|
Maybe lock down force pushes at least? Still annoying but if people are pushing junk commits already shouldn’t be that much friction.
|
|
#
?
Jun 5, 2023 13:08
|
|
|
You can make some noise now and have some conversations with your boss about this. Then wait. Then if something goes wrong that a nicer process would have solved you’ll be well positioned to make the change.
|
|
#
?
Jun 5, 2023 13:26
|
|
|
Having a locked down main branch with code reviews seems to be a pretty low bar. But if it's really all that contentious, you can coax them in by focusing on the "release process" instead of their commit workflow. So for example, introduce a branch called "production" and, well, nobody is using it right now so might as well add some branch protection rules. They can continue to use their existing workflow to write and push and share quickly on main. The first few times you make a release, you can do the pull request yourself to go from main to production with a nicely written summary of all of the changes since last release. Once they're used to seeing you do that, slowly have them start to do the same. This is really just semantics, making production the real main and main some development branch, but it might come across better as "here's some entirely new thing we can do to get release notes written down" as opposed to "here's how we're going to change something you're already doing."
|
|
#
?
Jun 17, 2023 01:26
|
|
|
Speaking of pushing directly to main: in GitHub, is there a way to allow commits to a branch (main or otherwise) unless a certain file was changed, in which case it would require a PR? e.g. I can push a commit that changes a.txt and b.txt, but if that commit also contained changes to c.txt, it would fail and I'd have to PR.
|
|
#
?
Jun 19, 2023 19:54
|
|
|
Lumpy posted:Speaking of pushing directly to main: in GitHub, is there a way to allow commits to a branch (main or otherwise) unless a certain file was changed, in which case it would require a PR? e.g. I can push a commit that changes a.txt and b.txt, but if that commit also contained changes to c.txt, it would fail and I'd have to PR. You're looking for something called a pre-receive hook.
|
|
#
?
Jun 19, 2023 20:04
|
|
|
In ADO you can run a pipeline on PR, and require that pipeline passes as a build validation step, then you can put whatever validation logic you want in there. It looks like required workflows are the equivalent feature for github actions, but that is in private beta right now.
|
|
#
?
Jun 19, 2023 20:09
|
|
|
The Fool posted:In ADO you can run a pipeline on PR, and require that pipeline passes as a build validation step, then you can put whatever validation logic you want in there. That's not going to prevent a commit from being pushed in the first place. That's the ask. It comes up a lot.
|
|
#
?
Jun 19, 2023 20:14
|
|
|
|
| # ? Apr 27, 2024 15:31 |
|
|
New Yorp New Yorp posted:You're looking for something called a pre-receive hook. Ah ha! Thank you. I could not google anything that returned this. Much apprecated!
|
|
#
?
Jun 19, 2023 20:18
|
|