|
peepsalot posted:I think maybe you are misinterpreting the info there. I agree with that, it seems to be saying it will point to the same place in the git tree. A way I thought of is to run a script as a git hook, and check to see if the target line is in the commit, updating if it is. But now that I'm thinking through it that seems fragile unless you can be sure it runs every time or walk the tree if other things have happened since.
|
#
?
Dec 15, 2019 03:29
|
|
|
|
| # ? May 30, 2024 21:35 |
|
|
Chrome is slowly rolling out a feature that lets you embed text in a link, and the browser will automatically scroll to that text and highlight it. So your problem might be solved soon, if other browsers adopt it.
|
|
#
?
Dec 15, 2019 10:39
|
|
|
Another github question. There was a user that committed some changes which caused a regression on an project I contribute to. I wanted to contact them to see if they had some ideas for fixing it. I used the the "git blame" on github which shows their full name, but its not a link to their user profile like most other users on here. I've also found their corresponding user profile, but if I try to @username in an issue comment, it doesn't produce a link so I suspect it won't notify them. Is there some kind of privacy setting on profiles that completely prevents others from contacting you? Seems rather inconvenient that there's no way to follow up on this user's changes. edit: Nevermind, I think the @ actually works, just some weird interface inconsistencies that were confusing me. peepsalot fucked around with this message at 21:32 on Dec 16, 2019 |
|
#
?
Dec 16, 2019 21:09
|
|
|
Git commits only get linked to github accounts via the person explicitly adding the email address to their account.
|
|
#
?
Dec 16, 2019 21:39
|
|
|
In case anyone is still able to edit the OP, I'm surprised the Pro Git book is not the first resource linked for Git. It serves very well as a progressive beginners' guide to Git. https://git-scm.com/book/en/v2 If you want to work in my team, you read and learn up to and including chapter 3, then we can teach you the rest on the job.
|
|
#
?
Dec 16, 2019 22:01
|
|
|
peepsalot posted:I think maybe you are misinterpreting the info there. There's no guarantee that the specific function, symbol, or whatever you want a permalink to will even continue to exist as new commits are made, so linking to a specific commit as well as a specific place in the source is the only way this can work in the general case. Even if it does still exist it may change so dramatically that it longer illustrates whatever you wanted the documentation for, which IMO is even worse than pointing to outdated code.
|
|
#
?
Dec 16, 2019 23:52
|
|
|
Hippie Hedgehog posted:In case anyone is still able to edit the OP, I'm surprised the Pro Git book is not the first resource linked for Git. It serves very well as a progressive beginners' guide to Git. Then struggle with git in the real world for a little while, then read chapter 10.
|
|
#
?
Dec 17, 2019 04:36
|
|
|
ToxicFrog posted:There's no guarantee that the specific function, symbol, or whatever you want a permalink to will even continue to exist as new commits are made, so linking to For example within markdown you can define an anchor anywhere like this: <a name="coolthing"></a> Then provide a link to that within the markdown like this: BTW, checkout my [cool thing](#coolthing) Clicking the link will scroll that section into view. You can link to anchor targets within the same document or in some separate markdown document even. Its a widely supported HTML/browser feature. There's no particular reason you can't extend this idea to source files in some way, especially when the source is being presented through a web application like github. I was picturing something where you could define similar anchor in a code comment: // <a name="coolsourcecode"></a> ... or whatever other syntax within the comment could be chosen to denote an anchor target, doesn't particularly matter. Different comment delimiters could even be supported dependent on file extension ( .c => "// ..." or "/* ... */", .py => "# ..." , etc.) Anyways, for something like that to work, the github page which displays the source files would need to support such a feature by parsing files for those anchor definitions and inserting a corresponding actual HTML anchor among the side gutter or something. In this scenario, simply re-arranging functions or adding/removing lines wouldn't necessarily break anything as long as your leave those anchor targets as part of your comments near to the code section you're trying to link. Yeah you can still theoretically remove an anchor from your source at any time, but that would be dumb if you're relying on it as a link target from your docs etc. And even if you did remove one, the link would still at least go to the top of the source file, just wouldn't scroll any specific line into view. Its completely feasible for a feature like this to work fairly well. But I understand if github hasn't considered or bothered with such an idea, just was hoping maybe they had. peepsalot fucked around with this message at 06:15 on Dec 17, 2019 |
|
#
?
Dec 17, 2019 06:12
|
|
|
peepsalot posted:Well my original question wasn't really referring to "permalinks". The wording I used was "anchor". The line numbers in source files are links in githubs viewer so in theory there's nothing stopping you from putting a specially formatted comment in your source and writing a commit hook to scrape the resulting github views for the comment and generating the link yourself, then auto update the corresponding markdown accordingly.
|
|
#
?
Dec 17, 2019 07:19
|
|
|
I have a personal Github account with a variety of repositories, both public and private, and with some of them only relevant in a personal sphere, others potentially relevant with work. I do not log in to personal accounts on my work machine—at least, in a way that would give the people who have remote access to my work machine any ability to themselves see or log in to my personal accounts, assuming they have full and complete access up to and including potentially keylogging and network sniffing everything. (While I do not think that they do this, I don't want to be in a position where them choosing to do this for whatever reason would compromise my personal accounts) However, I would like to have access to some (but not all) of the private repositories in my personal Github, on my work machine. Including the ability to push as myself, so that the commits show up on my Github account's "activity" and are otherwise indistinguishable from commits made from my work machine. My work machine and home machine are both macOS devices. Going over HTTPS seems like a bad idea, because then I'm either a) caching my creds in the keychain, or b) typing them in a lot, both of which seem like ways of handing over the creds to the entire account, giving my work access to repos I don't want them to have access to. I would be able to get an SSH key on the computer, but then that's still access to all of my repositories, protected pretty much only by obfuscation (they don't know the repo exists, so they couldn't grab my ssh key and clone it easily, unless they guessed correctly or found out about its existence through other means). What I would like is either an SSH key or a username/password that still is me for the purposes of Github but is limited in its access scope. Is this possible? Is there actually a much simpler way of solving my underlying problem?
|
|
#
?
Dec 26, 2019 04:09
|
|
|
It's a bit of a workaround, but you could make a third account which your personal account gives owner permissions on the select few private personal repositories, then just store that SSH key in that account only. You can also generate a password-protected SSH key but IME that can cause weird issues occasionally because some tools just do not expect it. As far as commits looking like they came from your account, AFAIK git and github only cares about the user.email field when determining who committed (and user.name for the display name of the committer), so you can do git config --local user.email "personal@email" in each of the personal repositories, and set it to the email of your primary personal account. Linear Zoetrope fucked around with this message at 04:29 on Dec 26, 2019 |
|
#
?
Dec 26, 2019 04:21
|
|
|
Axiem posted:I have a personal Github account with a variety of repositories, both public and private, and with some of them only relevant in a personal sphere, others potentially relevant with work. The level of paranoia you're showing is weird, like you know you're doing something bad and you're trying to avoid getting caught. Don't do personal work on company property or time. Although it's difficult to enforce, a lot of companies claim ownership of anything done using their equipment.
|
|
#
?
Dec 26, 2019 04:31
|
|
|
New Yorp New Yorp posted:The level of paranoia you're showing is weird, like you know you're doing something bad and you're trying to avoid getting caught. This, but also if you want to contribute to your own work from a separate account why not just make another account and fork those repos and pr your changes into them?
|
|
#
?
Dec 26, 2019 04:50
|
|
|
Axiem posted:I would be able to get an SSH key on the computer, but then that's still access to all of my repositories, protected pretty much only by obfuscation (they don't know the repo exists, so they couldn't grab my ssh key and clone it easily, unless they guessed correctly or found out about its existence through other means). Notwithstanding the "should you be doing this on company time" question, you can put a passphrase on your SSH private key. That way, the key at rest cannot be used by itself to get access to GitHub.
|
|
#
?
Dec 26, 2019 05:18
|
|
|
New Yorp New Yorp posted:The level of paranoia you're showing is weird, like you know you're doing something bad and you're trying to avoid getting caught. I just don't think my employer should know about my personal life, especially when my personal life intersects political activism. I'd rather not potentially get fired for advocating the company I work for get taxed more, for instance  quote:Don't do personal work on company property or time I don't, and I don't want to! That's actually part of why I want the separation, so that I don't actually have access to actual personal projects on work computers! The repos I'd want to share are things like dotfiles and configuration things, which ultimately aren't too much of a pain to straight copy over, but it's kind of annoying maintaining two different dotfiles repos and when I update my `.vimrc` in one of them to have to remember to go update it in the other, and hopefully keep the commit message similar enough to remember what I did and why The MUMPSorceress posted:This, but also if you want to contribute to your own work from a separate account why not just make another account and fork those repos and pr your changes into them? Wouldn't that affect the contribution graph etc? That is, those commits would be attributed to my "work account" not my "actually me" account? (I guess if it's all just keyed on email that wouldn't matter, huh? Hm.)
|
|
#
?
Dec 26, 2019 05:22
|
|
|
Why can't you connect to your home pc using SSH (tunneled over HTTP or w/e if you need to) and do the work there?
|
|
#
?
Dec 26, 2019 05:53
|
|
|
Axiem posted:I just don't think my employer should know about my personal life, especially when my personal life intersects political activism. I'd rather not potentially get fired for advocating the company I work for get taxed more, for instance OK so this might sound crazy, but it sounds like your use case doesn't so much need version control but a thumb drive. If you have a bunch of random config files for ides and editors and poo poo that you just want to have available at both home and work, just put them on a thumb drive and back them up to github every once in a while. Way simpler than trying to do sekrit ops poo poo. You can even get really small thumb drives that fit on a keychain or on a wallet.
|
|
#
?
Dec 26, 2019 08:57
|
|
|
The MUMPSorceress posted:just put them on a thumb drive and back them up to github every once in a while. My work computer policy bans thumb drives :facepalm: It’s sounding like I can’t do what I was wondering, which is fine. I’ll just muddle through like I have been.
|
|
#
?
Dec 26, 2019 19:42
|
|
|
Axiem posted:Wouldn't that affect the contribution graph etc? That is, those commits would be attributed to my "work account" not my "actually me" account? (I guess if it's all just keyed on email that wouldn't matter, huh? Hm.) If you're not working on them during work hours you won't be making any commits so who cares?
|
|
#
?
Dec 26, 2019 22:27
|
|
|
If you're looking for some magic way to get access to your repo in such a way that someone else with full access to the machine can't also get access, that sounds like it would violate the laws of physics. If you're just looking for a way to get your config files out of a git repo, I'd just bite the bullet and make a second github account for just those config files, and keep it separate from your actual code that you don't want touching your work computer. I will say that we run Github Enterprise at work and even with that things like this are kind of difficult, for example I can share a repository to an account, and I can make a Personal Access Token for that account, and I can set scopes on that PAT, but I can't do things like "only read on this specific repo" it's just repo access or not, and the PAT has whatever access the user does to all the same repos. In theory it would be nice if in your case you could make a PAT and grant it access to only your repo(s) with configs but that just doesn't exist.
|
|
#
?
Dec 26, 2019 23:38
|
|
|
FISHMANPET posted:In theory it would be nice if in your case you could make a PAT and grant it access to only your repo(s) with configs but that just doesn't exist. Yeah I'm really longing for this, it seems like a no-brainer feature.
|
|
#
?
Dec 26, 2019 23:42
|
|
|
If you look at the scopes you can assign a PAT it screams "we didn't design this, we just let teams throw up a scope whenever they needed one." https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes
|
|
#
?
Dec 26, 2019 23:45
|
|
|
FISHMANPET posted:If you're just looking for a way to get your config files out of a git repo, I'd just bite the bullet and make a second github account for just those config files, and keep it separate from your actual code that you don't want touching your work computer. This is ultimately what I went with. It works. quote:In theory it would be nice if in your case you could make a PAT and grant it access to only your repo(s) with configs but that just doesn't exist. Yeah, that was basically what I was wanting, but if it’s not there, then it’s not there. I’ll survive
|
|
#
?
Jan 1, 2020 02:24
|
|
|
So let us say we have this set of git commits in origin/master:code:code:code:
|
|
#
?
Feb 25, 2020 21:05
|
|
|
Sounds like you're already set. I'm not sure what you're trying to do. If your reverts left the code in a good state, why would you not just write your new code in new commits based on HEAD and get on with life?
Hippie Hedgehog fucked around with this message at 22:57 on Feb 25, 2020 |
|
#
?
Feb 25, 2020 22:55
|
|
|
Hippie Hedgehog posted:Sounds like you're already set. I'm not sure what you're trying to do. If your reverts left the code in a good state, why would you not just write your new code in new commits based on HEAD and get on with life? Because the "bad" commits add a new feature, which didn't exist in the last "good" commit. Most of the work done in the two "bad" commits is worth preserving, and it would be easier to start from the bad state and fix that then do all the work again from the good state.
|
|
#
?
Feb 25, 2020 23:06
|
|
|
Revert the reversion and work off that.
|
|
#
?
Feb 25, 2020 23:41
|
|
|
Revert the reverts and work locally off that, but squash everything into a single commit once you've got it in a good state. Don't be pushing bad commits to master.
|
|
#
?
Feb 26, 2020 02:11
|
|
|
The short answer is you should have done all the previous things in a branch  It took like a million years too long for me to learn my lessons but now I always do everything in a new branch, even on simple personal things.
|
|
#
?
Feb 26, 2020 03:03
|
|
|
Lumpy posted:Because the "bad" commits add a new feature, which didn't exist in the last "good" commit. Most of the work done in the two "bad" commits is worth preserving, and it would be easier to start from the bad state and fix that then do all the work again from the good state. It depends on a lot of different factors as to whether this is suitable, but you could just reset the head back to commit 4 and force push. For example, I'm basically the only developer on a lot of things I work on, and I work in feature branches, so doing this would be ideal because it removes the now-redundant stuff and doesn't break anything since no one else is working on those branches. But if this is on your master branch or your shared dev branch or something, probably not a good idea to do this, and you'll need to revert the reverts.
|
|
#
?
Feb 26, 2020 05:43
|
|
|
Create a new branch with head at 4, then reset master's head to 2.
|
|
#
?
Feb 26, 2020 14:06
|
|
|
Jabor posted:Revert the reverts and work locally off that, but squash everything into a single commit once you've got it in a good state. taqueso posted:The short answer is you should have done all the previous things in a branch I have repeatedly show this person exactly how to do those things, but.....  Thanks for the input all. As a test-writing, branch-working, commit squasher, I've not had much experience dealing with this.
|
|
#
?
Feb 26, 2020 14:47
|
|
|
Restrict pushing to master so they have to use branches.
|
|
#
?
Feb 26, 2020 20:08
|
|
|
Install Gerrit and institute a code review process. Only give the lead developers +2 permissions on master.
|
|
#
?
Feb 26, 2020 21:57
|
|
|
necrotic posted:Restrict pushing to master so they have to use branches. This. If they can't follow a process willingly then you'll need to remove the choice for them.
|
|
#
?
Feb 26, 2020 22:23
|
|
|
You could also create a new working branch at 4, do whatever, and then when you're done rebase 2 --onto 6.
|
|
#
?
Mar 4, 2020 02:02
|
|
|
Hippie Hedgehog posted:Install Gerrit and institute a code review process. Only give the lead developers +2 permissions on master. What a coincidence - I just started a new job that has just had (somewhere in the week or two before I started) Gerrit added to the process. The vocal supporters weren't really able to clearly explain to the team what problem it is solving and mostly fell back to 'I hated it at first, too, but after a few months it grew on me' and 'yeah it's a lot of rebasing.' Can someone...give a slightly better insight?
|
|
#
?
Mar 4, 2020 20:32
|
|
|
Cuntpunch posted:What a coincidence - I just started a new job that has just had (somewhere in the week or two before I started) Gerrit added to the process. The vocal supporters weren't really able to clearly explain to the team what problem it is solving and mostly fell back to 'I hated it at first, too, but after a few months it grew on me' and 'yeah it's a lot of rebasing.' What are you comparing it to? Completely unadorned git?
|
|
#
?
Mar 4, 2020 21:08
|
|
|
Cuntpunch posted:What a coincidence - I just started a new job that has just had (somewhere in the week or two before I started) Gerrit added to the process. The vocal supporters weren't really able to clearly explain to the team what problem it is solving and mostly fell back to 'I hated it at first, too, but after a few months it grew on me' and 'yeah it's a lot of rebasing.' What are you using Gerrit for? Isn't it for review-ing commits and automatic builds and stuff? How were people reviewing other people's commits before?
|
|
#
?
Mar 4, 2020 21:29
|
|
|
|
| # ? May 30, 2024 21:35 |
|
|
Volguus posted:What are you using Gerrit for? Isn't it for review-ing commits and automatic builds and stuff? How were people reviewing other people's commits before? I thought it was super narrowly scoped to just code review. Which as far as I can tell, makes it strictly inferior to basically every other Git hosting platform out there, but I've never used it so maybe I'm missing something about it.
|
|
#
?
Mar 4, 2020 21:37
|
|