|
Stringent posted:Yeah, but in the future that's how you should handle this, imo. Even before I fixed things, I'd think that's what would have happened. code:code:
|
#
?
Mar 28, 2018 14:30
|
|
|
|
| # ? May 31, 2024 03:43 |
|
|
Not sure if there’s a better way but you can revert a revert and then it will let you remerge the branch
|
|
#
?
Mar 29, 2018 05:15
|
|
|
Is there a git one-liner to rebase and squash all the outstanding commits? Currently I do an interactive rebase and then mark all the lines except the first as squash or fixup, but that is a bit tedious.
|
|
#
?
Apr 19, 2018 13:53
|
|
|
You can put certain content in your commit messages to affect an auto-rebase: https://robots.thoughtbot.com/autosquashing-git-commits
|
|
#
?
Apr 19, 2018 15:50
|
|
|
Cool, didn’t know about that. So in theory instead of: git commit -m wip I can do something like: git commit —fixup head And then the squash rebase will be automatic, eventually.
|
|
#
?
Apr 20, 2018 12:20
|
|
|
smackfu posted:Is there a git one-liner to rebase and squash all the outstanding commits? Currently I do an interactive rebase and then mark all the lines except the first as squash or fixup, but that is a bit tedious. There's git merge --squash for the simple case. I haven't used autosquash before but it looks pretty awesome for more complex workflows.
|
|
#
?
Apr 20, 2018 20:16
|
|
|
Are there any services that will automatically mirror a not-hosted-at-github repo to a hosted-at-github repo?
|
|
#
?
Apr 21, 2018 17:22
|
|
|
Thermopyle posted:Are there any services that will automatically mirror a not-hosted-at-github repo to a hosted-at-github repo? Wouldn’t most CI services do this? I only have experience with the CI components of VSTS, and can definitely do it with the tools built in there. I’ve heard good things about https://concourse-ci.org/ FE: I could mirror a non-vsts git repository to github with VSTS using the built in tools.
|
|
#
?
Apr 21, 2018 18:01
|
|
|
The Fool posted:Wouldn’t most CI services do this? I only have experience with the CI components of VSTS, and can definitely do it with the tools built in there. To be clear, the not-hosted-on-github repo is not mine nor do I have any sort of control to it. I'm trying to avoid the source repo disappearing because the main dev gets pissy or whatever. I was just hoping there was some simple dedicated service out there where I could enter the url to the source repo and a destination repo credentials or whatever and it'd do the work of periodically checking for new commits on the source repo and pulling them and then pushing them to the destination.
|
|
#
?
Apr 21, 2018 18:16
|
|
|
Tried something like https://github.com/new/import ? It won't automatically update with changes from the original source after you import, but for forking someone else's project as a safetynet for rage-deletes it should work?
|
|
#
?
Apr 21, 2018 19:17
|
|
|
Set multiple remotes, and alias “git push” to a pair of commands that pushes to both remotes?
|
|
#
?
Apr 21, 2018 19:19
|
|
|
Data Graham posted:Set multiple remotes, and alias “git push” to a pair of commands that pushes to both remotes? I was going to suggest something similar. Not sure you'd find a service to sync repos like you're describing. Importing, yes, but synchronizing is different.
|
|
#
?
Apr 22, 2018 01:48
|
|
|
In VSTS, and I assume other hosted CI solutions you can setup a build pipeline on a schedule that can pull from the repo in question and then push it to github.
|
|
#
?
Apr 22, 2018 02:01
|
|
|
I just finished a difficult merge... but now there are new commits to both branches. What's the best way to bring it up to date?
|
|
#
?
Apr 24, 2018 16:21
|
|
|
Sedro posted:I just finished a difficult merge... but now there are new commits to both branches. What's the best way to bring it up to date? Pull the new commits on the branch you merged into, then merge the other branch again: code:
|
|
#
?
Apr 25, 2018 09:37
|
|
|
tak posted:Pull the new commits on the branch you merged into, then merge the other branch again: You may need to do `git merge origin/the-other-branch` because pull will only merge upstream changes into the branch you're currently on.
|
|
#
?
Apr 25, 2018 09:41
|
|
|
Hello everyone this is going to be a longish post, I'm kind of a noobie at git/github and I thought I knew more than I did. I've started a new remote job and the project I'm working on has like one overarching project and then some subprojects so the folder structure is sort of like this:code:I created a branch, did some work, committed and then push origin'd it, but that created a branch under the Big_project repo on github. Then I kind of went rogue and changed the upstream url to the sub_project repo whiiiiich uploaded the entire Big_project into the sub_project repo on my branch. Luckily it's only 75Mbs, but that was a dumb move. This is academia so the expectation is kind of that I fix this myself. So I have two questions: 1) How do I fix this? 2) How should I have approached this from the beginning. The most that I can see is submodules, but I don't quite get it. EDIT: Okay I've deleted the branches and then just did a git init in the variation_sets, but it looks like I forgot to merge it, which in my defense I tried to do but it was giving me an error bollig fucked around with this message at 13:25 on Apr 25, 2018 |
|
#
?
Apr 25, 2018 12:23
|
|
|
When you are trying to run git rebase with a bunch of commits, each of which has a merge conflict is the process, as follows? > git rebase develop fix merge conflicts commit > git rebase —continue fix merge conflicts commit Push to remote Really having trouble with this today
|
|
#
?
May 3, 2018 22:38
|
|
|
Grump posted:When you are trying to run git rebase with a bunch of commits, each of which has a merge conflict is the process, as follows? Basically yes, what part of the process is causing issues?
|
|
#
?
May 3, 2018 22:42
|
|
|
I think my issue was that I wasn’t committing after resolving, but we’ll see when I get into work tomorrow
|
|
#
?
May 3, 2018 22:45
|
|
|
It won't let you do anything until you resolve the conflict and continue, or abort the rebase entirely. Status command tells you what your options are when rebasing or cherry picking.
|
|
#
?
May 3, 2018 22:46
|
|
|
What if you skip the patch and just fix all the merge conflicts in the last problematic commit?
|
|
#
?
May 3, 2018 23:23
|
|
|
If you skip the patch it won't be included.
|
|
#
?
May 3, 2018 23:25
|
|
|
Right but what if the commit after that deals with the same file? Would you then just skip to the commit where the file is most up-to-date?
|
|
#
?
May 3, 2018 23:32
|
|
|
That's not how it works. Skipping a patch means the changes in that patch will not be present at the end of the rebase.
|
|
#
?
May 3, 2018 23:36
|
|
|
If you don't want to deal with conflicts a bunch of times squash the branch first so its one commit, or just merge in the other branch and resolve it all in the merge commit.
|
|
#
?
May 4, 2018 00:06
|
|
|
bollig posted:Hello everyone this is going to be a longish post, I'm kind of a noobie at git/github and I thought I knew more than I did. I've started a new remote job and the project I'm working on has like one overarching project and then some subprojects so the folder structure is sort of like this: I'm confused - why you are running git init at all? That's for creating new repos. Submodules can kind of suck to work with. See if one of these StackOverflow answers helps.
|
|
#
?
May 4, 2018 00:06
|
|
|
Grump, are you doing this all through the console? I started off doing everything through the console but honestly using a UI like GitKraken just makes life so much easier. My opion is that it's not worth the hassle to not use it unless you're forbidden from using git UIs for some strange reason. Rebasing through GitKraken is as simple as selecting the branch you want to rebase on top of, then working through the conflicts in the diff view. Very easy and takes a few minutes at most.
|
|
#
?
May 4, 2018 01:45
|
|
|
I run the commands in the console and work out the conflicts in VS Code. Seems simple enough. I’m just finding it hard to figure out what the console is trying to explain sometimes. This is my first job working on a project that more than 2 devs are making changes to, so I’m having trouble figuring out the best way to pull down the develop branch from the project and merge with my feature branch in my forked project. It’s a work in progress honestly and my imposter syndrome is acting up big time. teen phone cutie fucked around with this message at 02:32 on May 4, 2018 |
|
#
?
May 4, 2018 02:29
|
|
|
Grump posted:Right but what if the commit after that deals with the same file? Would you then just skip to the commit where the file is most up-to-date? so that's not quite how git works - every commit you resolve is applying its own changes, not providing the most recent version of the file. So if (on the same file) commit A edited line 10-20, commit B edited lines 50-60, and commit C edited lines 130-150, and you skipped A and B during your rebase, C would only apply the changes to lines 130-150 , not 10-20 or 50-60. IMO don't rebase unless it's commanded by on high. People need to be less mad about merge commits.
|
|
#
?
May 4, 2018 18:23
|
|
|
I rebase my feature branches every morning because I'd rather keep my poo poo up to date and avoid a merge conflict down the road. I also don't want to merge branches into my feature branch because I don't want to carry commits that might be reverted later. My feature branches should contain just my commits. Rebase is dead simple. Also, I've used SourceTree in both OSX and Windows and refuse to use the cli because I'm 1000% more efficient and can typically fix poo poo that others mess up super easy in SourceTree. Just my opinion though.
|
|
#
?
May 4, 2018 21:48
|
|
|
Any reversions should be new commits anyway so you'd still carry them by rebasing.
|
|
#
?
May 4, 2018 22:25
|
|
|
Grump posted:When you are trying to run git rebase with a bunch of commits, each of which has a merge conflict is the process, as follows? > git rebase develop fix merge conflicts > git add fixedfile.py > git rebase --continue fix more conflicts, add fixes, continue rebase, until done > git push When fixing conflicts during rebase you do not commit yourself, leave the fixed files in the index. The only time you'd use 'git commit' during a rebase operation, I can think of, is when using the 'edit' action in an interactive rebase.
|
|
#
?
May 5, 2018 06:55
|
|
|
Just wanted to report back saying that I now understand how git rebase works and it’s not as scary as I once thought. Thank you
|
|
#
?
May 10, 2018 18:57
|
|
|
Yeah none of git is scary once you understand it. It (and other distributed VCS) is just different from older VCS in that only patches matter, nothing else exists.
|
|
#
?
May 10, 2018 19:23
|
|
|
The thing that really made Git click for me is understanding that it's essentially a filesystem where blobs are inodes and refs (branches/tags) are symlinks, and then the rest of the toolkit is dedicated to manipulating/merging/comparing the content. Spending a few hours spelunking around a toy repo with git cat-file demystifies pretty much everything about Git.
|
|
#
?
May 10, 2018 23:08
|
|
|
Yeah you can even browse around the .git folder and make changes directly there (don't, but you can). It's just files and symlinks.
|
|
#
?
May 10, 2018 23:45
|
|
|
For me what made git click was when I realized it was just a giant tree, where each commit is just a dot on the tree, and every named thing (branch/tag) is just a pointer to a dot on the tree. For me, the ability to visualize the DAG (as it were) was the point where I started being able to figure out how to do things on the command line beyond the basics.
|
|
#
?
May 11, 2018 03:12
|
|
|
Axiem posted:For me what made git click was when I realized it was just a giant tree, where each commit is just a dot on the tree, and every named thing (branch/tag) is just a pointer to a dot on the tree. For me, the ability to visualize the DAG (as it were) was the point where I started being able to figure out how to do things on the command line beyond the basics. Yeah this was what made it click for me too. Every time I did something with git and was all "wow this is actual real magic" my tech lead just replied "git is a graph and you are just doing things to the graph" and then one day I was like "oh right that makes sense" and now I am the office git guy 
|
|
#
?
May 11, 2018 13:28
|
|
|
|
| # ? May 31, 2024 03:43 |
|
|
Make everyone else download SourceTree so they can see the magic too. It's pretty easy to understand git when you can see what you are doing.
|
|
#
?
May 11, 2018 15:50
|
|