|
I've got a github C++ project in dire need of a code beautifier. There's mixed tabs/space all over and inconsistent brace style etc. Both a clang-format and an uncrustify config were created a while ago, sorta testing things out, but they never really got put to use. I'm wondering what options there are for any kind of automation of this, of if anyone here has experience doing this sort of thing. I guess maybe there's 2 main kinds of workflow: 1) Commits trigger a style-checker, which pass/fails, and then its up to the dev to run a beautify script applying style changes to make it pass. 2) Commits trigger a bot to actually format the code (and commit the changes itself?) Not even sure if that second one is actually a thing, but if so: - Would there be any way to review/veto the changes in case anything goes wrong with the formatter? - Can the changes be hidden from git blame/history in some way, or maybe just for a specific commit of an initial mass-update? Partially answering my own question, I did see this link which describes a feature to ignore specific commits from git blame in git versions >= 2.23. https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame#git-2.23-to-the-rescue But does anyone know if github's interface supports that also, or has any plans to? If possible, I'd like to have this automated in such a way that there's minimal added work for contributors, and currently open PRs hopefully don't all become 100% merge-conflicts. Basically just wondering what the path of least resistance would be while still moving forward. peepsalot fucked around with this message at 19:48 on Jul 4, 2020 |
#
?
Jul 4, 2020 19:41
|
|
|
|
| # ? Apr 26, 2024 06:55 |
|
|
Merge as much as you can, format the repo, then use CI to enforce it staying that way in the future. This way individual developers can still use annotations to bypass the formatting where necessary and you don't end up with a bunch of pointless bot commits. Encourage developers to configure their editors to format on save or commit.
|
|
#
?
Jul 4, 2020 20:41
|
|
|
Sanity checking something. I have a repo that looks like this:code:code:
|
|
#
?
Jul 7, 2020 14:45
|
|
|
Since that commit was reverted it won't work, iirc. Best bet is to revert the revert into a new branch and work off that.
|
|
#
?
Jul 7, 2020 14:58
|
|
|
Lumpy posted:Sanity checking something. I have a repo that looks like this: It's been a while since I did this but you can try: code:
|
|
#
?
Jul 7, 2020 15:00
|
|
|
necrotic posted:Since that commit was reverted it won't work, iirc. Best bet is to revert the revert into a new branch and work off that. So make a new branch off master, then revert def456 ? For my own learning, why wouldn't what I thought to do work? Hughlander posted:It's been a while since I did this but you can try: I don't understand this. Since the feature commit and the revert are pushed to origin, wouldn't rewriting history be bad?
|
|
#
?
Jul 7, 2020 15:30
|
|
|
Lumpy posted:So make a new branch off master, then revert def456 ? For my own learning, why wouldn't what I thought to do work? The commit that was reverted, ghi789, still exists in master. If you try to merge it again it a "no op", because that commit already exists. Revert is not undo, it just reverses the changes in a commit with a new commit. Here is a detailed description of how this is all working. quote:I don't understand this. Since the feature commit and the revert are pushed to origin, wouldn't rewriting history be bad? Yes, this would require force-pushing to master which is generally frowned upon.
|
|
#
?
Jul 7, 2020 15:45
|
|
|
necrotic posted:The commit that was reverted, ghi789, still exists in master. If you try to merge it again it a "no op", because that commit already exists. Revert is not undo, it just reverses the changes in a commit with a new commit. Awesome, thanks for the info / help!
|
|
#
?
Jul 7, 2020 16:26
|
|
|
Say I have a repo with ‘main’ and two branches, ‘feature’ and ‘clean’ I’ve been doing work in ‘feature’ and periodically merging in to ‘main’ Now I want to reset ‘main’ to the same state as ‘clean’, what’s the best way to do this?
|
|
#
?
Dec 3, 2020 21:35
|
|
|
code:
|
|
#
?
Dec 3, 2020 21:50
|
|
|
Also, the non-hard reset is an under-appreciated tool. Changes the HEAD pointer and nothing else. Useful when you just want to commit your changes and don’t care about any of the specific commits you have locally.
|
|
#
?
Dec 3, 2020 23:41
|
|
|
smackfu posted:Also, the non-hard reset is an under-appreciated tool. Changes the HEAD pointer and nothing else. Useful when you just want to commit your changes and don’t care about any of the specific commits you have locally. it's definitely one of those things that I originally couldn't imagine the use for but has definitely been the exact right tool in a handful of situations
|
|
#
?
Dec 4, 2020 15:54
|
|
|
An adjacent team has a problem where other people try to give them merges that blow up 6+ months of work because the merge chose to use the old stuff for every conflict that came up. I know the real solution for this involves a lot of dialog (and physical harassment) for the people trying to pass along these merges. However, I was curious if there's anything that can detect this kind of thing happening and give us some information about it in advance of the inevitable "conversation." I'm thinking of something like taking a guess at the base used for the bad merge commit and being able to separate what they actually did to the code versus what was done in the main branch normally. It would be like an "unmerge" or something. I don't expect something like that to work perfectly because you don't actually have all the information, and you'd eventually get that (hopefully) from the person trying to ram in the bad merge. However, I'd like to be able to quantify how far back it goes, what they pooped all over, and have a general take on what they actually individually did to the code versus what they just categorically reverted. What I am thinking of right is now is a script that just goes backwards through the git log, diffing each main commit against the merge, until it finds the lowest number of deltas.
|
|
#
?
Aug 10, 2021 18:37
|
|
|
Say I have a branch A with tons of commits in git, if I cherrypick a bunch of standalone changes out of it into another branch B, then merge B with master and rebase A, will it automagically ditch the cherrypicked ones in branch A, if the commit IDs didn't change?
|
|
#
?
Sep 2, 2021 00:29
|
|
|
Combat Pretzel posted:Say I have a branch A with tons of commits in git, if I cherrypick a bunch of standalone changes out of it into another branch B, then merge B with master and rebase A, will it automagically ditch the cherrypicked ones in branch A, if the commit IDs didn't change? Not sure if it will, but rebase —interactive would show whether it did and let you skip them if necessary.
|
|
#
?
Sep 2, 2021 00:33
|
|
|
Combat Pretzel posted:Say I have a branch A with tons of commits in git, if I cherrypick a bunch of standalone changes out of it into another branch B, then merge B with master and rebase A, will it automagically ditch the cherrypicked ones in branch A, if the commit IDs didn't change? Not to say this won't work the way you want, but cherrypicking "changes" commit IDs. (Strictly speaking, the new commits it creates have new IDs, because they're new commits.)
|
|
#
?
Sep 2, 2021 16:15
|
|
|
More specifically, cherry pick takes the change list from a given commit and applies it as a new commit where you choose. The commits will have identical changes, but they'll have different commit IDs and rebase will treat them as needing to be merged (although the merge ought to be handled automatically by any decent merge tool)
|
|
#
?
Sep 3, 2021 01:37
|
|
|
Ah too bad. I thought I could keep the housekeeping to a minimum.
|
|
#
?
Sep 3, 2021 02:50
|
|
|
There's a bunch of tricks to avoid cherry-picking, or making handle merges better, in this article series: https://devblogs.microsoft.com/oldnewthing/20180312-00/?p=98215
|
|
#
?
Sep 3, 2021 13:54
|
|
|
As a sort of follow-up to my last post in this thread, 2yrs ago, at the top of this page (slow thread, eh?), a maintainer on our project eventually bit the bullet and ran a code beautifier over the whole codebase and checked in the changes. Back then, I had asked if github would support ignoring bulk changes peepsalot posted:... So that was nice to see, however I'm now running into an unforeseen issue which is compounded by this formatting change... I knew the code formatting would cause a significant number of conflicts with very old/stale PRs in case they were ever picked up again (unfortunately there are quite a few), and I was ok with accepting that cost, at face value. Then the same project also underwent a large restructuring, where many source files were renamed for consistency in letter casing and/or organized into subdirectories. One particular PR was most recently sync'd with master 3 yrs ago, and I attempted to get it up-to-date after these changes. I found that not only are there many merge conflicts as expected, but much worse is that git is unable to follow the file moves/renames because of those changes. So e.g. the merge shows a number of false-positive "CONFLICT (modify/delete)" lines, and when I run "git mergetool", I get: code:For something like a single file's log history, it is capable of following renames, by comparing the "similarity index" (based on the # of matching lines / total lines) between two files deleted/created in a commit. And if that passes a threshold (configurable, but default 50%) then it counts as match and can follow that rename. But, when doing a merge, as far as I can tell it only compares the "endpoints" of the merge, and does not consider intermediate commits for the purpose of tracking file renames. So even though the bulk formatting change was 99% whitespace-only, and I would guess that < 20% of characters changed per file; that doesn't matter since only the number of lines changed is counted, which was apparently >50% from start to end. Also, for the record, the commits which renamed or moved files, I would estimate changed between 0 to 1% of total lines in those files. ANYWAYS, I guess my main question is: Once a merge has started is there a way to manually correct git to tell it the renamed file path, so that I can proceed with a proper 3-way merge, rather than just "choose modified or deleted file"? I suppose the other option would be to perform separate merges for commits immediately preceding any file move/rename, plus another merge for that commit itself. But this feels like another huge pain in the rear end to keep track of those commits and manually split up merges in this way. I'm also trying to find and document whatever is the most straightforward, understandable solution to these issues, so that any other PRs / developers in a similar position can follow. I just wish git was not so goddamn stupid... like I don't suppose there is any way to have merges just consider individual commits one-at-a-time when resolving a file rename, rather than just the entire before/after? Or like a way to change the "similarity index" metric to be character-based rather than line-based, i'm pretty sure the files would pass in that case too. peepsalot fucked around with this message at 22:59 on Mar 28, 2022 |
|
#
?
Mar 28, 2022 22:51
|
|
|
Just upfront, I'm not super knowledgeable on this. I'm here to learn too. That feels like a slog for old PR's anyway you sum it up. I wonder if cherry picking the name change is sufficient in cases like this. Effectively, the one that says, "delete A and add B which has A's contents." The release model seems to help such situations for me. I start a release from main, fix all the conflict mumbo jumbo from the feature branch I pulled in, then merge back into main.
|
|
#
?
Mar 29, 2022 01:49
|
|
|
peepsalot posted:But, when doing a merge, as far as I can tell it only compares the "endpoints" of the merge, and does not consider intermediate commits for the purpose of tracking file renames. Merge is explicitly just merging endpoints. Rebase exists to let you apply the commits of the branch you are rebasing one-by-one onto the commit you are rebasing on, if you prefer to do that -- I find it generally preferable to always rebase whenever I'm updating a feature branch, but opinions very much differ on that sort of thing. However for an old, stale branch rebase can be very painful, since odds are the early commits will have conflicts in code that is changed in later commits. You often end up resolving multiple conflicts in different commits as the same region of code gets updated. You can change how broadly an individual git rebase (or merge) detects renames with the git rebase -X find-renames=10% strategy option, which may be useful when dealing with something that's exceedingly diverged. You can technically also use an interactive rebase to interleave the commits of the two branches in some arbitrary order starting from some common ancestor, but unless everyone working on the codebase is OK with doing a big history rewrite on master I would strongly recommend against trying that.
|
|
#
?
Mar 29, 2022 06:48
|
|
|
Squash the old branch into 1 commit on a temporary branch, and rebase that on master with rerere enabled. resolve any conflicts which saves the conflict resolution. Then switch back to the old branchv and try merging master in You might still get conflicts that weren't cached by rerere but it should help somewhat If you still get too many conflicts and don't get the detailed history of the old branch you can just keep the squashed one instead If you get conflicts it doesn't mean rename detection didn't work though, that only affects how the diff is displayed. Conflicts happen because the same contents diverged, with different changes in the 2 sides of the merge
|
|
#
?
Apr 1, 2022 05:13
|
|
|
tak posted:Squash the old branch into 1 commit on a temporary branch, and rebase that on master with rerere enabled. resolve any conflicts which saves the conflict resolution. Then switch back to the old branchv and try merging master in I haven't tried rerere before, I will look into it some more. I have briefly read that it caches the manual resolutions of merge conflicts, and can somehow re-apply them when the same conflict comes up multiple times? Why/how would that happen though? But I think you misunderstand my issue with rename detection. Its not just the existence or even the number of conflicts that bothers me... It's that when rename detection fails, I only get the option to delete the file OR use the outdated branch version (see the "code block" prompt in my last post). When this happens "git mergetool" literally does not open my default tool (meld) to resolve the conflict in a reasonable way, because it was too stupid to determine the corresponding filename in master.
|
|
#
?
Apr 1, 2022 05:44
|
|
|
This is apparently impossible to google for. Does anyone know if git is planning to change the default branch name with git init from master to main? Checked 2.36, but that was still on master with a warning.
|
|
#
?
Apr 20, 2022 22:27
|
|
|
Selklubber posted:This is apparently impossible to google for. Does anyone know if git is planning to change the default branch name with git init from master to main? Checked 2.36, but that was still on master with a warning. From reading the tealeaves (and commits) yes, a lot of work was done to remove any dependencies on master as the default init branch in preparation for it changing to something. There is no date to do this, but as this is a major change, you should probably expect it in a major version change (i.e. 3). There are some threads on kernel.org about this but you may want to refrain from reading them if you don't want the urge to throw heavy things at people's faces over the internet If you have processes or documentation that depend on the default branch being master you should probably adapt right now as that option is already available and used, especially seeing as git(hub|lab)/azure devops/bitbucket have already made this change.
|
|
#
?
Apr 29, 2022 01:34
|
|
|
I have a problem that I cant seem to find an answer for. I have a remote linux box at work that I can login into and run git fetch/pull and the connection to the bitbucket repository is not a problem. However if I ssh into that machine and attempt to do a pull/fetch/push/whatever, I get the following error: code:Any help is appreciated.
|
|
#
?
May 4, 2022 18:07
|
|
|
Is your bitbucket key loaded into ssh-agent? If so, when you ssh into the machine you won't have access to the ssh-agent without some effort.
|
|
#
?
May 4, 2022 18:30
|
|
|
ExcessBLarg! posted:Is your bitbucket key loaded into ssh-agent? If so, when you ssh into the machine you won't have access to the ssh-agent without some effort. Sorry Im a little confused. Are you saying that I need to associate the ssh key thats in bitbucket to the computer I am using to remote into linux? I have a key that I am using to ssh into the linux box and then there is a separate key for making the connection between the linux box and bitbucket.
|
|
#
?
May 4, 2022 18:45
|
|
|
Tacos Al Pastor posted:I have a problem that I cant seem to find an answer for. SSH into the box in question. Go into ~/.ssh and see if bitbucket is in the known hosts file. Compare the contents of that known hosts to your local one that works. Also check if there is a pub key in the remote .ssh folder, id<something>.pub, and see if that’s associated in bitbucket correctly, if not ssh-key gen and add it. Alternatively you can just copy your local working .ssh files out there, but don’t think that’s good security practice, or create new
|
|
#
?
May 4, 2022 23:40
|
|
|
MarxCarl posted:SSH into the box in question. Go into ~/.ssh and see if bitbucket is in the known hosts file. drat. I just realized I didnt even check this. Let me give this a try.
|
|
#
?
May 4, 2022 23:59
|
|
|
Tacos Al Pastor posted:Are you saying that I need to associate the ssh key thats in bitbucket to the computer I am using to remote into linux? If so, what's probably happening is that your desktop environment is running a ssh-agent, which is a program that keeps ssh keys loaded in memory so you can use them with git or whatever. But when you ssh into that machine from elsewhere, you're not using the same session as your desktop and so don't (immediately) have access to the ssh-agent. You could probably still manually use the bitbucket key, but I'd assume it's password protected. If this is all what's going on there's a few approaches to solve it. One is to spawn another ssh-agent in your ssh session, and ssh-add the key. Another is to set the SSH_AUTH_SOCK environment variable to point to the socket of the existing ssh-agent (usually /tmp/ssh-blarblar/agent.12345 or something). A third is to use screen/tmux to share a shell between your desktop terminal and ssh
|
|
#
?
May 5, 2022 01:53
|
|
|
Known hosts does contain the correct info for bitbucket.ExcessBLarg! posted:If I'm understanding correctly, you have a desktop machine that if you sit down at, and open a terminal, you can successfully git pull from bitbucket. But if you ssh into that same machine, it doesn't work? Yep thats the issue quote:If so, what's probably happening is that your desktop environment is running a ssh-agent, which is a program that keeps ssh keys loaded in memory so you can use them with git or whatever. But when you ssh into that machine from elsewhere, you're not using the same session as your desktop and so don't (immediately) have access to the ssh-agent. You could probably still manually use the bitbucket key, but I'd assume it's password protected. Using screen does solve my problem, but I guess that means I always need to leave a screen running (which is fine). This is what I get when i run "ssh-agent -s": ssh-agent -s SSH_AUTH_SOCK=/tmp/ssh-wUmlOC8Zbibc/agent.16707; export SSH_AUTH_SOCK; SSH_AGENT_PID=16708; export SSH_AGENT_PID; echo Agent pid 16708; I assume I need to add this info to my profile file?
|
|
#
?
May 5, 2022 17:30
|
|
|
You can add "eval $(ssh-agent -s)" to your ~/.bash_profile and "eval $(ssh-agent -sk)" to your ~/.bash_logout, but you'll still need to manually run "ssh-add" every time you ssh into the machine. It also results in the issue that you may have multiple ssh-agents running, which can get confusing if some have keys loaded and some don't. I prefer screen myself. If your screen session dies you can start a new one "killall ssh-agent; eval $(ssh-agent -s); screen" or something like that.
|
|
#
?
May 5, 2022 18:54
|
|
|
ExcessBLarg! posted:You can add "eval $(ssh-agent -s)" to your ~/.bash_profile and "eval $(ssh-agent -sk)" to your ~/.bash_logout, but you'll still need to manually run "ssh-add" every time you ssh into the machine. It also results in the issue that you may have multiple ssh-agents running, which can get confusing if some have keys loaded and some don't. Thanks for your help. I didnt even think of using screen as a solution.. I think that last part is helpful. Like I said I leave the screen sessions running. Normally its to run a test on one screen while I am editing things on another, so screens never get killed.
|
|
#
?
May 5, 2022 22:13
|
|
|
This script runs for me on new shell creation to find my existing SSH agent instance and associate it to the new shell:code:
|
|
#
?
May 13, 2022 17:37
|
|
|
I know years ago there was lots of ideas floating around about getting non-tech people to start using actual version control that didn't consist of Report2022_v1_fbls_Sallys_finalFINAL.docx but other than the little bit more appealing GUIs like GitKraken, did anyone ever actually develop some type of git-backed document management system for a document-heavy organization? I know many tech orgs just make their non-tech teams use Gitlab or Github or whatever but they can do this because they have essentially enough sway to force them to learn it, but I work in a very traditional organization that doesn't even use SharePoint let alone some type of structured version control and instead emails around everything. Oh, and for our use-case it needs to be self-hosted / on-prem , lol for reasons unknown to me. Kind of something like a very stripped down Github that has a better UI, branching DVCS and made with markdown so you could visualize the entire workflow and each diff of a document. A self-hosted version of this Almanac app or Forestry IO so you've got a WYSIWYG rich text editor with version control for the non-tech users, but it's fully connected to a git repository so the more technically inclined can push out markdown and integrate it with their other workflows and you could do stuff like linting and other pipeline jobs Atlassian started doing this with their Work Management or whatever but thats only an issue tracker and doesn't have any version control. edit. I guess what I mean here is a 'docs as code' GUI for markdown based version control but not designed for technical users but like lawyers, policy, govt and academia in the humanities side that would want to be able to collaborate off very fine detailed docs that would be too flexible just using Google docs but not as 'scary' as GitHub. Oysters Autobio fucked around with this message at 01:48 on Jul 27, 2022 |
|
#
?
Jul 27, 2022 00:46
|
|
|
Oysters Autobio posted:I know years ago there was lots of ideas floating around about getting non-tech people to start using actual version control that didn't consist of Report2022_v1_fbls_Sallys_finalFINAL.docx but other than the little bit more appealing GUIs like GitKraken, did anyone ever actually develop some type of git-backed document management system for a document-heavy organization? 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? If you need document management, use a document management tool. There are tons out there and they all suck in their own special way, but using git would be 1000x worse.
|
|
#
?
Jul 27, 2022 03:20
|
|
|
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? Fixing a merge conflict for a doc with Git just sounds like a nightmare.
|
|
#
?
Jul 27, 2022 06:46
|
|
|
|
| # ? Apr 26, 2024 06:55 |
|
|
Tacos Al Pastor posted:Fixing a merge conflict for a doc with Git just sounds like a nightmare. Not the same but I remember being at a place where they'd silently lay off people pretty frequently. Me and someone else would just run a script that would grab the company directory from google sheets and convert each revision into a git commit and diff that to see who had vanished...
|
|
#
?
Jul 27, 2022 08:55
|
|