|
In the Github WebUI when you look at a branch, you can see how many commits ahead it is of master, and if you go through the pull request UI (even if you don't actually submit it) Github will tell you what files are in your branch compared to master. It won't include changes in master that haven't been introduced into your branch. As far as I can tell, I can use this git command to get that same data git diff --name-only origin/master... My understanding is that this is trip dot notation shows you every change starting with the first thing and ending at the last thing, or at your current point if you leave it blank. I can reverse it and do ...origin/master if I wanna see ways I'm behind master as well. When a pull request is merged Github will also tell you what changed when the PR was merged, and among other things will send that data in a webhook if you have that turned on. I think in plain language it's giving you all the files that have changed between this commit and the previous commit to the same branch (so generally from previous master to current master). What command can I run to find that?
|
#
¿
Jun 9, 2019 20:25
|
|
|
|
| # ¿ May 14, 2024 15:11 |
|
|
Well I think I answered my own question... When you've got the current master checked out (or any branch for that matter), I think you can find out what changed in it compared to to the last commit to the branch with git diff --name-only HEAD~1..HEAD. These seems to work both when your PR merged in all commits from the branch and when a squash & merge was done. Not sure that it matters but this works for me where I'm checking out the commit hash of a branch and not just checking out the branch, which is what Azure Devops (and presumably other CI systems) do. So even though HEAD points to a commit and not a branch it still seems to know branch that commit is in to be able to get the previous commits from that branch to do the diff. Also apparently HEAD~1 is the same as HEAD~ is the same has HEAD^ is the same as HEAD^1 but I'll be damned if I can understand why. FISHMANPET fucked around with this message at 04:25 on Jun 10, 2019 |
|
#
¿
Jun 10, 2019 03:31
|
|
|
So I think HEAD^! is another useful shortcut such that if you run git diff HEAD^! you'll only get changes from the current commit, which is probably generally the same as git diff HEAD~...HEAD but not exactly the same? I looked a little closer at some webhook data and I'm fairly certain it's doing HEAD~..HEAD based on this snippet:code:This quest is actually two fold. First, figure out what changed when code is merged into master after the fact or predict what will be changed (solved by HEAD~...HEAD and origin/master...HEAD). The second is I'm working on a Powershell project called BuildHelpers that has some little helper functions that are useful when you're inside a build pipeline. One of them is for getting the set of files that has changed in a commit, and it does it by doing git diff-tree --no-commit-id --name-only -r HEAD which as I've dug in is not a very useful command. By default you won't get anything from merge commits. It's basically only useful if you go from one revision in a branch to the next revision in that same branch, and will only tell you what changed in that last revision. But in an attempt to fix this and make it as backwards compatible as possible, I'm trying to find a somewhat equivalent command using git diff. I think the current behavior is so pointless to be called a bug, but I think HEAD^! is enough to basically get a functional equivalent.
|
|
#
¿
Jun 11, 2019 00:19
|
|
|
In my case I won't have the web hook. We currently have a process where the got commit fires off a web hook to an Azure Automation runbook that downloads files and deploys them based on what changed. I'm replacing this whole workflow with Azure Devops where I don't have access to that web hook data so I have to figure it out from git. Additionally, I want a "preview" of what the changes will be before a commit is made to master or even a PR so changed filed can be deployed to a test environment for testing. Since each file takes about a minute to deploy and we have 30 or 40 we can't just deploy every file every time.
|
|
#
¿
Jun 11, 2019 03:34
|
|
|
So I think maybe you're reading the quoted part such that you believe that how the commit was merged into dev will impact how it merges into master, but I think it's just saying how the merge into master will behave based on how you merge it. I don't fully understand the ff vs no-ff action but I think if you're always merging a single commit from dev into master you want to merge all commits, because squash and merge will make a new commit, which causes dev to be "behind" master
|
|
#
¿
Dec 9, 2019 04:30
|
|
|
I think you're fine to continue doing rebase for merges into dev, so that each feature that goes into dev is a single commit, then to merge that single commit into master and have them be identical, merge all commits into master (which will just be your single commit). Otherwise rebase and merge will make a new commit (I assume it does this even if there's a single commit but I don't think I've tried that) with a new hash that will be in master but not dev, making dev "behind" master even though the code is identical.
|
|
#
¿
Dec 9, 2019 06:26
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
I want to keep both repos, but I think that would destroy repoB?
|
|
#
¿
Sep 12, 2022 17:51
|
|
|
|
| # ¿ May 14, 2024 15:11 |
|
|
I will preface this by saying I do all my day-to-day git work in GitHub desktop, but it's really useful to go through some tutorials to be able to do everything you'd normally do via the command line. Git has kept a focus on backwards compatibility, to the point where some of the Git workflows don't really make any sense, and so things like GitHub Desktop (or I'm assuming your Eclipse plugin) abstract them somewhat. On a day to day basis it's easier to just use that abstraction, but it's useful to know what's happening under the hood so that when stuff gets messed up, or you need to do something outside of that tool, you're not completely lost.
|
|
#
¿
Oct 11, 2023 22:15
|
|