|
22 Eargesplitten posted:I'm in Git Bash on windows and after that message came up, it won't respond to my typing. I did this the first time I tried to commit anything and just exited out and did it again correctly, but I'd like to know how to get out of it without doing that. Right. This is vim which should be the default editor for git, if you want to learn how to use it then Google 'vim'. You can change it to notepad or whatever you like with git config --global core.editor "path-to-editor"
|
#
?
Feb 4, 2016 23:47
|
|
|
|
| # ? May 12, 2024 18:14 |
|
|
22 Eargesplitten posted::wq did it, thanks. I assume you mean the history is extremely messy. If it's really bothering you, you can get your local history however you want it and then force-push to overwrite the server copy. But don't do this if anyone else is tracking that branch for anything; it will totally bork the workflow of every single person who relies on it other than you. Rewriting public history is generally considered Extremely Bad Form.
|
|
#
?
Feb 4, 2016 23:54
|
|
|
GrumpyDoctor posted:I assume you mean the history is extremely messy. If it's really bothering you, you can get your local history however you want it and then force-push to overwrite the server copy. But don't do this if anyone else is tracking that branch for anything; it will totally bork the workflow of every single person who relies on it other than you. Rewriting public history is generally considered Extremely Bad Form. Sorry I wasn't clear. I've got a bunch of redundant and unnecessary files that make the filesystem stored in Github look awful and make it difficult to navigate. I sorted it out locally, and want to fix it on git. But if I try to push the fixed files to github, it says that the push has been denied because the repository contains work that I do not have locally. Do I need to start an empty folder, connect it to the repository, pull, rm -rf, and then push the new version to Github?
|
|
#
?
Feb 5, 2016 02:20
|
|
|
22 Eargesplitten posted:Sorry I wasn't clear. I've got a bunch of redundant and unnecessary files that make the filesystem stored in Github look awful and make it difficult to navigate. I sorted it out locally, and want to fix it on git. But if I try to push the fixed files to github, it says that the push has been denied because the repository contains work that I do not have locally. Git commits are immutable. When you rewrite history (e.g. amend commits, rebase, filter-branch), you actually throw out the old commits and create new commits in their place with new hashes. If you rewrote history, you have to force push.
|
|
#
?
Feb 5, 2016 02:37
|
|
|
I must be misunderstanding something. I don't want to change past commits, I just want to put in a new commit without some of the folders and files that aren't necessary anymore. I don't mind older commits having all of them. I haven't rewritten anything at this point, and I don't want to take anything out of current commits, I just don't want to bring some stuff over into the new commit.
|
|
#
?
Feb 5, 2016 02:46
|
|
|
22 Eargesplitten posted:Sorry I wasn't clear. I've got a bunch of redundant and unnecessary files that make the filesystem stored in Github look awful and make it difficult to navigate. I sorted it out locally, and want to fix it on git. But if I try to push the fixed files to github, it says that the push has been denied because the repository contains work that I do not have locally. 22 Eargesplitten posted:I must be misunderstanding something. I don't want to change past commits, I just want to put in a new commit without some of the folders and files that aren't necessary anymore. I don't mind older commits having all of them. I haven't rewritten anything at this point, and I don't want to take anything out of current commits, I just don't want to bring some stuff over into the new commit. It sounds like what happened is that someone did some work on the remote repository, which you don't have mirrored locally. This occasionally happens to me even on my solo projects, where I'll have done some work on one computer, and then pushed it to github, and then I'll have forgotten to do a fetch/merge on a second computer before doing work on that second computer. If you think that's what happened, the easiest fix is to do a git pull --rebase. This will find the most recent common ancestor of the work on your computer and the work on the remote computer, pull down the changes from the remote, and then apply your changes (i.e. deleting the extraneous files) on top of the remote's changes.
|
|
#
?
Feb 5, 2016 03:19
|
|
|
Yep, I just needed to pull to get it synced up and then push again. But now I've got another problem. When I commit, it doesn't move the head to the newest commit. And when I try to push to github, it goes through the normal ssh username/password thing but doesn't update anything. It says I'm currently in detached head mode, does that have to do with it? I pulled the most recent version, deleted all of the files and replaced them with the updated files / file system, is that where I broke it? E: I cherry picked the one commit that was detached from the head and that fixed it. I'm glad git is so resilient to me fumbling around. Another question, can github be searched for file names or project names? I'd like to be able to link stuff in a github made for this account, but I don't want to make it easier to doxx me than it probably already is. I use my real name for my github repository name currently. 22 Eargesplitten fucked around with this message at 21:32 on Feb 8, 2016 |
|
#
?
Feb 8, 2016 21:18
|
|
|
22 Eargesplitten posted:Another question, can github be searched for file names or project names? I'd like to be able to link stuff in a github made for this account, but I don't want to make it easier to doxx me than it probably already is. I use my real name for my github repository name currently. They have a search mechanism. And if its public external search engines will find it, too.
|
|
#
?
Feb 9, 2016 05:38
|
|
|
22 Eargesplitten posted::wq did it, thanks. Read the docs for 'git reset', specifically, 'git reset HEAD~' and 'git reset --hard HEAD~' (be careful with this one).
|
|
#
?
Feb 9, 2016 07:20
|
|
|
I'm leaving a 100% mercurial shop (and my last place was also mercurial) to a 100% git shop. Are there guides on making this switch without loving up badly? Or at least the key differences, I only really know of branches being pointers and the fun that brings with remotes.
|
|
#
?
Feb 12, 2016 00:59
|
|
|
Cancelbot posted:I'm leaving a 100% mercurial shop (and my last place was also mercurial) to a 100% git shop. push and fetch do the opposite things in git, commit needs the -a flag to behave like mercurial, and there are no command-line shortcuts by default. I use the following .gitconfig: code:
|
|
#
?
Feb 12, 2016 01:28
|
|
|
I haven't really used Mercurial for five years, but the biggest difference when I went from Mercurial to Git was the practice and degree of history rewriting. For quite some time history rewriting was a limited, if not impossible practice in Mercurial. It's a fundamental distinction between Mercurial and Git that dates back to their original design, with Mercurial adopting a diff-based structure (revlog) for its internal storage on the basis that the primary purpose of the tool is to preserve revision history, although many folks used the mq extension as a means of local rewriting/reordering of private changesets. In Git, commit history modification is a fundamental feature supported by core commands (e.g., commit --amend, rebase -i, reset, etc.), so the equivalent of managing a patch queue is to maintain a set of local commits at the top of history, rebasing them on remote changes. In general, local history rewriting (rebasing, squashing commits) is an encouraged practice with Git, since one of the fundamental points of revision control is to communicate changes to others, in addition to preserving their (public) history. So it's probably best to think of the funny/"dangerous" git commands as analogous to those of the mq extension. If you've never used mq (or rebase, or whatever) then you may want to read up on the benefits of local history rewriting in the first place. The other two major differences is the distinctions between named branches (Git's branches function like Mercurial bookmarks, and are not encoded in revision history), and Git's explicit distinction between remote and local branches.
|
|
#
?
Feb 14, 2016 19:53
|
|
|
ExcessBLarg! posted:I haven't really used Mercurial for five years, but the biggest difference when I went from Mercurial to Git was the practice and degree of history rewriting. In Mercurial, commit has an --amend flag just like Git, and newer versions of Mercurial support limited history editing with the histedit extension. Otherwise these are all excellent points, particularly the fact that rewriting local history to remove cruft is encouraged (and even expected, depending on the project) in Git.
|
|
#
?
Feb 14, 2016 20:24
|
|
|
Ah that's great stuff! They tried to introduce rebasing and squashing where I currently work and it caused so much consternation due to not being "mercurial-like" that I didn't bother looking it up for a while. But it makes a lot of sense especially when you're pull request driven and need to make sense of the many little commits you often do in DVCS systems. The other thing I've had to pay attention to is leaving master alone except for merging into; as much as I buy into feature toggles/branch by abstraction the vast majority of software teams I know of use feature/PR based approaches. But the branching stuff with git is so lightweight its not a problem to work that way.
|
|
#
?
Feb 15, 2016 11:59
|
|
|
How do people do code review in a svn system? Mailing patches around seems terrible, especially if you are doing continuous integration. My last project we were using RTC (Rational something something) which I found very confusing in the big picture but did have a very clear concept of change sets that were tied to a work item and needed to be reviewed before being committed.
|
|
#
?
Feb 16, 2016 14:03
|
|
|
Before distributed version control became popular, folks would email patches to someone with commit rights. It wasn't great, but it wasn't so bad either as it forced everyone (submitter, committer) to review the diff itself, and generally time would be taken to ensure the patch was high quality (squashed, good commit message, no unrelated changes, etc.). In my experience, though, when everyone does have commit rights in a centralized system, code reviews just aren't done. Fundamentally reviews are post commit and you have to slog through multiple not-well-done commits, and there's a lot more inertia to making post-review changes because it's "already in SVN".
|
|
#
?
Feb 16, 2016 16:16
|
|
|
The correct answer is to use something like Gerrit or Phabricator, which gives you a workflow similar to github PRs (except much better, because github PRs are basically babby's first code review tool).
|
|
#
?
Feb 16, 2016 17:13
|
|
|
We do commits in feature branches, and when a feature is done someone else reviews the work + merges it into default.
|
|
#
?
Feb 16, 2016 17:38
|
|
|
uXs posted:We do commits in feature branches, and when a feature is done someone else reviews the work + merges it into default. Yeah this is basically the right way to use GitHub.
|
|
#
?
Feb 16, 2016 18:54
|
|
|
I've got a situation where I'm trying to maintain a repository for two OSes--SunOS and RHEL, in this case. 95%+ of the code and scripts and stuff is the same between the two. I figure I can set up a git repo with linux and sun branches, but that would mean doing two merges for every commit that applies to both branches. Does anyone have any experience with this sort of problem that they can enlighten me with?
|
|
#
?
Feb 25, 2016 21:10
|
|
|
Ciaphas posted:I've got a situation where I'm trying to maintain a repository for two OSes--SunOS and RHEL, in this case. 95%+ of the code and scripts and stuff is the same between the two. I figure I can set up a git repo with linux and sun branches, but that would mean doing two merges for every commit that applies to both branches. Does anyone have any experience with this sort of problem that they can enlighten me with? Assuming Git: Can't you put the common code in a separate repository and have distribution-specific repositories that use submodules to pull in the common code?
|
|
#
?
Feb 25, 2016 21:32
|
|
|
Normally you try to have a single set of code that can be configured at compile time or even run time to support any of the supported target platforms.
|
|
#
?
Feb 25, 2016 21:34
|
|
|
Ralith posted:Normally you try to have a single set of code that can be configured at compile time or even run time to support any of the supported target platforms. I was just assuming that the code was substantially different, so much so that doing it via precompilation would be difficult to maintain.
|
|
#
?
Feb 25, 2016 21:39
|
|
|
Ithaqua posted:I was just assuming that the code was substantially different, so much so that doing it via precompilation would be difficult to maintain.
|
|
#
?
Feb 25, 2016 21:43
|
|
|
Ralith posted:Normally you try to have a single set of code that can be configured at compile time or even run time to support any of the supported target platforms. Unfortunately there are things like shell scripts using builtins that, no matter how I slice it, just have to be different between the two systems. Process monitoring stuff comes to mind right now. As to the actual C++ code, some of the differences already use directives and such, but most don't, and those aren't gonna be worth the effort to refactor for the timeframe I have to do this for (a couple months at best). Ithaqua posted:Assuming Git: Can't you put the common code in a separate repository and have distribution-specific repositories that use submodules to pull in the common code? Git, yes, sorry. That might work, though I've never used submodules before so there might be some faff. The other half of that problem is that, as part of moving from Sun to Linux, we're moving off of Clearcase (  ) so adapting to things like submodules might be a bit much for the rest of my team. And me for that matter 
|
|
#
?
Feb 25, 2016 21:57
|
|
|
Git submodules will work if all the common code is confined to a common directory inside the platform specific code, otherwise you have to go with branches or separate repos with a shared remote. Submodules also kind of suck for making sure that everyone fetches and pushes from all repos, so it does require some discipline, but much of it can be scripted to make it easier. If you go the branch route, the easiest way to do it is to have all the common code on a "common" (or master) branch, and platform specific code on separate "sun" and "linux" branches into which you regularly merge changes made to the "common" branch. But this means you have to switch to "common" to make any changes to common code, then switch to each branch to merge those changes in. The upshot is that auto-merges will largely just work so you won't have much in the way of merge conflicts to resolve. The downside is that you have to switch branches all the time, and if people lack the discipline to commit common changes to the "common" branch, you'll find yourself frequently with changes on one of the two platform-specific branches that have to be cherry-picked back into "common" and merged onto the other branch. Whatever you do though, don't merge from a platform-specific branch to "common", that will ruin your day. The other approach is to pick a platform that you'll primarily support, say "linux", and merge changes from "linux" back into "sun". So long as most of the changes are to the common code, merging won't be a big deal, but anytime you do merge platform-specific changes you'll want to do a manual merge as an auto-merge will incorrectly leak "linux" code into the "sun" branch. Hence, this approach is riskier, but if you basically don't have much in the way of platform-specific code and can deal with the "sun" branch lagging behind, it can be made manageable. Honestly, though, the best option is to have one branch and conditionally-compile platform-specific code. Even with shell scripts, you can usually have a "foo-linux.sh" and "foo-sun.sh" which are called by a master "foo.sh" after determining which OS you're on.
|
|
#
?
Feb 25, 2016 22:53
|
|
|
What's the fastest way for me to go from seeing a file in my Windows file browser, to having the file's SVN path on my clipboard? I'm doing a lot of requirements tracing and it involves filling out a huge spreadsheet with SVN paths
|
|
#
?
Feb 26, 2016 00:15
|
|
|
ExcessBLarg! posted:Honestly, though, the best option is to have one branch and conditionally-compile platform-specific code. Even with shell scripts, you can usually have a "foo-linux.sh" and "foo-sun.sh" which are called by a master "foo.sh" after determining which OS you're on. This is probably what we're gonna end up doing really, yeah. Figured I'd explore the alternatives, though, since we're not gonna have to support more than two platforms for more than a year. (I hope. Server hardware purchasing is such a bitch around here like that.)
|
|
#
?
Feb 26, 2016 01:06
|
|
|
Here's quite a git pickle! Every time I commit / push, I seem to create an entirely new history of every single commit to the repo. Backstory: Created a repo w/ README, pushed to bitbucket. Hooray. Worked on said, made 12 commits, things look lovely, I pushed. All good so far. Yesterday: Co-Worker clones repo. Makes a change to the .gitignore, pushes. I pull change, make one other change to a different file and push. A git status says I'm 12 commits ahead of remote and that I need to push. Odd, but I'm tired, so I push. Today: I made one change to a file, commit and push (co-worder has not touched anything in the meantime). For fun, I immediately git status again, and now I'm 25 commits ahead of remote....  code:
|
|
#
?
Mar 3, 2016 21:55
|
|
|
Are https://xxxxxx@bitbucket.org/zzzzz/yyyyyyy.git and origin the same place? Why are you passing a full url to push?
|
|
#
?
Mar 3, 2016 22:10
|
|
|
Dylan16807 posted:Are https://xxxxxx and origin the same place? Why are you passing a full url to push? Yes they are. No real reason I guess... I just up-arrowed from my initial push and so had the full URL there. Could that be the cause?
|
|
#
?
Mar 3, 2016 22:17
|
|
|
If you push and pull using a URL git won't update any of your remotes even if that remote happens to be for the same place, so if you never actually fetch origin then origin/master will never update.
|
|
#
?
Mar 4, 2016 00:36
|
|
|
Plorkyeran posted:If you push and pull using a URL git won't update any of your remotes even if that remote happens to be for the same place, so if you never actually fetch origin then origin/master will never update. Because I'm a git idiot (gitiot?) you are saying that because I put the URL in to my push, the code went up, but the remote didn't sync because of it because a fetch never happened to my local. So, how do I un-gently caress the multiple sets of commits? I certainly can live with it being there, I just want to learn me more git.
|
|
#
?
Mar 4, 2016 05:02
|
|
|
Lumpy posted:Because I'm a git idiot (gitiot?) you are saying that because I put the URL in to my push, the code went up, but the remote didn't sync because of it because a fetch never happened to my local. git fetch origin
|
|
#
?
Mar 4, 2016 06:25
|
|
|
necrotic posted:git fetch origin Well that was easy. Thanks to you and Plorkyeran!
|
|
#
?
Mar 4, 2016 16:52
|
|
|
I'm trying to keep a protocol definition in-sync between the vastly different projects that access it (embedded, iphone, android and django backend). What's the preferred way to sync one or two files between multiple repos? Submodule is clunky, is there anything better?
|
|
#
?
Mar 9, 2016 03:29
|
|
|
If you can spare 5 minutes to read the documentation, submodules work great these days. The interface has been substantially cleaned up from when they were first introduced.
|
|
#
?
Mar 9, 2016 03:53
|
|
|
Cross -posting from the general questions thread, since I accidentally posted there instead of here:Slanderer posted:We're using SVN here (and I'm running TortoiseSVN on my machine), and I'm trying to figure out how to do something extremely stupid. There's an XML file I need to occasionally commit changes to, except I cannot commit any changes to a specific line in the file (the line identifies the hardware debugger I'm using, which is different than what the rest of the team uses). There is no nice solution to it, since the file is parsed by an embedded development IDE has no concept of local settings. I'm wondering if there is a way to prevent myself from committing changes this single line in the XML file. Would I have to do some nonsense with hook scripts that run before and after a commit that change the line in the file back to the default value and then back to my setting again? Any thoughts?
|
|
#
?
Mar 11, 2016 01:41
|
|
|
Slanderer posted:Cross -posting from the general questions thread, since I accidentally posted there instead of here: I think based on the information you have given me, youbare on the right track with hooks.
|
|
#
?
Mar 11, 2016 06:42
|
|
|
|
| # ? May 12, 2024 18:14 |
|
|
Yeah, hooks like you describe sound like a pretty reasonable solution, considering the limitations of your tools. Might be worth complaining to whoever maintains the IDE, just so they know they've got a problem.
|
|
#
?
Mar 11, 2016 21:10
|
|