|
Only yse git submodules when you have to, never because you want to. They're just a pain and don't really give you that much.
|
#
?
May 21, 2013 17:01
|
|
|
|
| # ? May 17, 2024 21:25 |
|
|
As a general rule, git submodules are useful (but pretty awkward) for external deps that you want to have pinned to a specific version, while git subtree is useful for sharing files between multiple repositories entirely under your control. Neither of these really covers what you want.
|
|
#
?
May 21, 2013 17:11
|
|
|
Plorkyeran posted:As a general rule, git submodules are useful (but pretty awkward) for external deps that you want to have pinned to a specific version, while git subtree is useful for sharing files between multiple repositories entirely under your control. Neither of these really covers what you want. That's what I was wondering. So far it looks like maintaining two separate repos will be easier overall to manage and for the team responsible for the stored procedures. Though it does mean that I have to keep an eye on that second repo and make sure my script points at it (not horrible). The concern is if someone after me has to do the same thing, the best I can do is document the process and hope they get it right, or make it so that my deployment script also, at a minimum, clones the stored procedures into a directory outside of itself. Maybe clone the data repo to a temporary directory, change the working set to a specified version and deploy from there. We have another deployment script that does that, but I'm not sold on that idea.
|
|
#
?
May 21, 2013 19:50
|
|
|
Submodules have grown on me, though it's debatable as to whether that's stockholm syndrome. I like the fact that the submodule is tied to a specific commit, since it means that I know that a given commit works. I'd be the first to admit that they're a bit of a hack, but that describes git in general. Edison was a dick fucked around with this message at 20:36 on May 21, 2013 |
|
#
?
May 21, 2013 20:30
|
|
only
|
Marsol0 posted:That's what I was wondering. So far it looks like maintaining two separate repos will be easier overall to manage and for the team responsible for the stored procedures. Though it does mean that I have to keep an eye on that second repo and make sure my script points at it (not horrible). The concern is if someone after me has to do the same thing, the best I can do is document the process and hope they get it right, or make it so that my deployment script also, at a minimum, clones the stored procedures into a directory outside of itself. Maybe clone the data repo to a temporary directory, change the working set to a specified version and deploy from there. We have another deployment script that does that, but I'm not sold on that idea. Ultimately, if your solution requires that someone follow some directions and set things up manually, they will hate you forever, while if it is a fully automated janky mess that somehow manages to work on their machine the first time, they will at most roll their eyes when they see how it works.
|
|
#
?
May 21, 2013 20:58
|
|
|
Plorkyeran posted:Ultimately, if your solution requires that someone follow some directions and set things up manually, they will hate you forever, while if it is a fully automated janky mess that somehow manages to work on their machine the first time, they will at most roll their eyes when they see how it works. Agreed. I think I am going to make the script source-control aware. Probably clone the data repo to a temporary location to configure for deployment and then clean up afterward. It's clunky, but works. The only problem there is that office politics is preventing us from picking one source-control platform. Right now the data group is using git and the dev team is using Mercurial. Part of what I was hoping to do was make this agnostic and use hg-git to convert later (though with sub-modules, there would be a few more steps, so maybe not as straight forward as it seemed in my head). Thanks for the help.
|
|
#
?
May 21, 2013 21:15
|
|
|
Is there a cool way in git to keep around build artifacts on, like, a per-branch basis so that I can switch between branches without having to rebuild everything every time? Do I just keep around multiple working copies of the same repository?
|
|
#
?
May 23, 2013 07:33
|
|
|
Vanadium posted:Is there a cool way in git to keep around build artifacts on, like, a per-branch basis so that I can switch between branches without having to rebuild everything every time? Do I just keep around multiple working copies of the same repository? I would recommend investigating if your build-system can do out of tree builds. For example, with most autotools projects you can run the configure script in a different directory, at which point it should leave your source code untouched. However, if you checkout a different branch with git, it should leave untracked files alone, so your build artifacts should be left where they are. If you do decide you need multiple work trees, look at https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir. It's available in git.git even if it's not packaged for your System. Edison was a dick fucked around with this message at 08:17 on May 24, 2013 |
|
#
?
May 23, 2013 08:51
|
|
|
My problem is that switching branches touches files so make wants to rebuild everything. So if I work on one branch, then check out another and build that even in another build dir, and switch back to the first branch, I "need" to rebuild everything that's different in the second branch. That link seems to address that problem, cheers.
|
|
#
?
May 23, 2013 11:18
|
|
|
Edison was a dick posted:If you do decide you need multiple work trees, look at https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir. You might want to fix your link; it contains the . at the end, causing a 404 on github.
|
|
#
?
May 23, 2013 17:39
|
|
|
Volmarias posted:You might want to fix your link; it contains the . at the end, causing a 404 on github. Thanks, I just pasted the whole thing in, blame the forum's automatic link generation.
|
|
#
?
May 24, 2013 08:18
|
|
|
I am trying to make a submodule of a gist inside my GitHub repo, but I keep getting errors.code:Not much I can do about the auto-tagging in the example code.
|
|
#
?
May 26, 2013 14:43
|
|
|
What errors? All you should have to do is "git submodule add <url> <new local path>". The only weird thing is that you have to do it from the root of your repo.
|
|
#
?
May 26, 2013 16:34
|
|
|
I think it was due to some weird problem with the root repo: "fatal: You are on a branch yet to be born". Re-cloning the root repo and adding the submodule subsequently fixed it.
|
|
#
?
May 26, 2013 18:44
|
|
|
Is it possible to gently caress up an svn mkdir or possibly an svn cp so badly that the commit message on the first commit ever got changed? I'm trying to understand how this scenario that just happened to me could have happened: I use git-svn to work with our project. When I was onboarded, I actually took the time to fetch the entire history, and it worked quite well after that. Yesterday though, things got weird. Another guy's git repository broke when he tried to do a fetch, as it was complaining about bad hashes. Worried, I did a fetch, and although I didn't get that error message, git-svn did decide to fetch everything in the history all over again. When it finished, I checked to see what was happening, and found that I had a duplicate set of commits. They had the same timestamps, authors, everything, with one exception: In the original set of commits, the very first commit had the message "Re-org day". In the duplicate set of commits, which apparently git-svn now considers to be the canonical line, the very first commit had the message "Re-org daysvn mkdir http://ourserver/svn/ourproject/oursubproject". I expect that the reason git fetched everything was because the first commit no longer had the same hash, and that problem of course propagated forward. I just want to know if anyone can fathom a scenario where this was somehow caused by a major goof in issuing a mkdir command.
|
|
#
?
May 31, 2013 10:19
|
|
|
Find the commiter for that initial commit and ask them what happened. Alternately, if your svn server has admins, ask them if they did anything. I think it's clear this isn't your fault.
|
|
#
?
May 31, 2013 13:55
|
|
|
Question about branching and configuration: I have 2 named branches in HG: default and maintenance. Normal mainline development is happening in default, bugfixes on the currently released version happen in the maintenance branch. Because there can (and will) be database difference in both environments, I'll need different database and different configurations. So I'll need a different configuration in each branch. Problem is that when I merge between them, the differences have a tendency to be merged away. (Which is logical since that's what a merge is.) So either the maintenance or the default config will be overwritten. I have tried to just use a different solution configuration in Visual Studio, with config transformations. This works for running the application (I just need to switch the active configuration in VS, that's easy), but my integration tests that I run with NCrunch insist on only using the default or an explicitly set configuration. So for the tests I'll still need to have some configuration file somewhere that's different in each branch. Anyway, TL/DR: what would be a good strategy to maintain a different configuration in 2 branches that survives merging in both directions?
|
|
#
?
Jun 7, 2013 10:08
|
|
|
Using TFS and I keep running into this error, anyone have any idea what's up? I tried clearing the cache, but this is like the third time it's happened. "The local version table for the local workspace XXX:XXX@EMAIL.com could not be opened. The workspace version table contains an unknown schema version." It's incredibly annoying and hampering development time by quite a bit.
|
|
#
?
Jun 7, 2013 19:14
|
|
|
I have a few projects that I've been tracking with git locally. I have a server set up now. I'm the only developer, but that might change soon. I'm not really understanding bare repositories. Is it just the base directory for the entire git server or should I be setting one up per project?
|
|
#
?
Jun 7, 2013 20:37
|
|
|
I do one per project and it works fine.
|
|
#
?
Jun 7, 2013 20:42
|
|
|
git's branching model does not support multiple projects per repository. Bare repositories are just copies of the repository without a local checkout. One of the core ideas behind git (and DVCSs in general) is that there is no real difference between local repositories and repositories on servers.
|
|
#
?
Jun 7, 2013 21:17
|
|
|
uXs posted:I have tried to just use a different solution configuration in Visual Studio, with config transformations. This works for running the application (I just need to switch the active configuration in VS, that's easy), but my integration tests that I run with NCrunch insist on only using the default or an explicitly set configuration. So for the tests I'll still need to have some configuration file somewhere that's different in each branch. Keep the configuration in two files, one for each environment. Then switch the active configuration with an environment variable, or make it part of deployment process to copy the right file to location where it's expected by the application/tests (you probably shouldn't be using the same config for tests and application). Or just merge more carefully and reject the changes to the configuration. Or don't version the configuration at all.
|
|
#
?
Jun 8, 2013 15:16
|
|
|
Yeah, I didn't see any way out of putting the config in some file somewhere and versioning it. I have separate configs for app and test anyway, that's not the problem. (Tests are in different projects.) The problem is having separate configs for different branches. I added an explicit setting for the maintenance branch now, only for the test projects. That is a fairly easy setting to maintain so I think it'll work.
|
|
#
?
Jun 8, 2013 16:49
|
|
|
In git is there a way to have a commit that gets applied after the last commit whatever branch you're on and just sort of follows you around without ever being applied anywhere? Basically, I have a dev board with some peripherals missing that I need to comment out, and I don't want to crap up our main code with a bunch of #ifndefs just because of this one board I'm using. Right now I just have a tagged commit that has the needed stuff and when I switch branches I cherry-pick it. Then when I submit my code I just rebase, move that commit to the end, and then reset that branch up a commit. But this seems overly complex and I'm always afraid I'll fat finger something durning a rebase. Basically, I'd like this one commit to always appear in the working tree but not be part of a branch. I can't put the affected files in .gitignore because I make other changes to them.
|
|
#
?
Jun 8, 2013 19:43
|
|
|
I'm a newbie to Git, and also to Linux-style command lines. I'm using the "Git Bash" thingie to do my stuff on Windows. A few questions: 1) Is there a way to Git Bash make it respect Ctrl when moving the cursor, like the standard Windows command line? There, holding Ctrl and using the arrow keys jumps a word, just like in any other place in Windows. 2) Can you make the tab completion better? In "DOS", pressing tab cleverly cycles available file/directory names that match what you've typed. The Git Bash doesn't cycle and doesn't match files/dirs with spaces. 3) What's the best way of making aliases of sort for commonly used commands? For example, I'd like to be able to type a short command that expands to "git push -u origin master". A parameterized one, for example for "git commit -a -m "<message here>"" would also be nice. In "DOS" I'd probably solve it with batch files in a dir in my PATH.
|
|
#
?
Jun 8, 2013 20:32
|
|
|
Pilsner posted:1) Is there a way to Git Bash make it respect Ctrl when moving the cursor, like the standard Windows command line? There, holding Ctrl and using the arrow keys jumps a word, just like in any other place in Windows. bash uses the GNU Readline library for command-line editing. With a default Readline configuration, <Alt+F> and <Alt+B> move forward and back a word, respectively. quote:2) Can you make the tab completion better? In "DOS", pressing tab cleverly cycles available file/directory names that match what you've typed. The Git Bash doesn't cycle and doesn't match files/dirs with spaces. Completion is also handled by Readline. You can get the cycling behavior by putting TAB: menu-complete in your ~/.inputrc (this file may be named differently on Windows, I have no idea). quote:3) What's the best way of making aliases of sort for commonly used commands? For example, I'd like to be able to type a short command that expands to "git push -u origin master". A parameterized one, for example for "git commit -a -m "<message here>"" would also be nice. In "DOS" I'd probably solve it with batch files in a dir in my PATH. code:
|
|
#
?
Jun 8, 2013 21:07
|
|
|
Pilsner posted:1) Is there a way to Git Bash make it respect Ctrl when moving the cursor, like the standard Windows command line? There, holding Ctrl and using the arrow keys jumps a word, just like in any other place in Windows.
|
|
#
?
Jun 8, 2013 22:00
|
|
|
Thanks. I found out that putting: bind '"\t":menu-complete' In a .bashrc file in my user directory did the trick with tab completion. Sucks about Ctrl+Left/Right navigation not being available.  Alt+F and Alt+B? Who came up with that?  (I know, probably some guy 20 years ago).
|
|
#
?
Jun 8, 2013 22:10
|
|
|
Pilsner posted:Alt+F and Alt+B? Who came up with that? Most likely, Richard Stallman, and ~30 years ago. (readline borrows the emacs keybindings )
|
|
#
?
Jun 8, 2013 22:42
|
|
|
They stand for Forward and Back. Ctrl-f and Ctrl-b go forward and back a letter because arrow keys weren't ubiquitous like they are now (and might not even have existed? I'm not sure.).
|
|
#
?
Jun 8, 2013 22:45
|
|
|
evensevenone posted:In git is there a way to have a commit that gets applied after the last commit whatever branch you're on and just sort of follows you around without ever being applied anywhere? You might want to look into stashes. It's not completely automatic, but git stash will save your index and working tree to a specially named "stash commit", and git stash apply or git stash pop will take a stash (by default the most recent) and apply it to your current working tree and index. pop additionally deletes the saved stash (if it was able to successfully apply it). This means that your branch switching mechanism now looks like: code:You could probably set up an alias like git float that does this automatically, too.
|
|
#
?
Jun 8, 2013 22:49
|
|
|
Thanks; I used stash for a while and it seemed about the same. The hard part is more on the commit/rebase side of things where I have to make sure that none of my unwanted changes sneak into the index of the feature branch. I usually do several commits while working on something. So it's that same problem where those unwanted changes are parents of the wanted changes and I have to rebase to rearrange them.
|
|
#
?
Jun 8, 2013 23:10
|
|
|
evensevenone posted:Right now I just have a tagged commit that has the needed stuff and when I switch branches I cherry-pick it. Then when I submit my code I just rebase, move that commit to the end, and then reset that branch up a commit. But this seems overly complex and I'm always afraid I'll fat finger something durning a rebase. I've been doing the same sort of thing for a few years now, and while it does result in needing to do the occasional ninja force-push I think on the whole it might actually cut down on bad pushes, since it forces me to be in the habit of always checking exactly what I'll be pushing before pushing and I've found other problems while removing the commits that shouldn't be pushed quite a few times. I wouldn't object to a less stupid workflow, though. It seems like it should be possible to automate not pushing specifically marked commits.
|
|
#
?
Jun 9, 2013 00:25
|
|
|
Plorkyeran posted:You can skip a step and just remove the commit while rebasing. It's really kind of an odd use-case though, and it seems like a scenario where the tail is wagging the dog. Is it possible to refactor your code out to reference relevant changes in one particular file, and then use something like this to just ignore changes to that file?
|
|
#
?
Jun 10, 2013 05:52
|
|
|
Well, in a week or two I'm probably going just rewrite the code so it handles the missing hardware without cocking things up quite so badly. But it doesn't seem like that weird of a use case, and git stash gets like 80% of the way there. Honestly if it wasn't so easy to just accidentally delete a line during an interactive rebase and lose a commit forever I'd be happy. git sure gives you a lot of rope to hang yourself with.
|
|
#
?
Jun 10, 2013 06:31
|
|
|
evensevenone posted:Honestly if it wasn't so easy to just accidentally delete a line during an interactive rebase and lose a commit forever I'd be happy. git sure gives you a lot of rope to hang yourself with.
|
|
#
?
Jun 10, 2013 14:27
|
|
|
Apologies if this has been asked/answered already, I'm still reading through this thread. My company has a small team of web developers and no current version control set up. I'm looking to move us to using Git. From reading the Git book, and a little personal experience, I understand the basics of cloning a repository, making commits, branching and merging e.t.c. In our current workflow we have three copies of any site: the live, public-facing version; a staging/preview version for testing/client approval before deploying new features; and a development version for working on. I'm trying to get my head around doing this in Git. Is it as simple as creating a repository on the live site, cloning it for the staging and dev sites and pushing branches between them? For instance, developers would - clone/fetch the repo on the dev site - create branches and commit changes locally - push the branch to the dev repo - test - push the branch from dev to staging - test - push the branch from staging to live Is that how it works or am I misunderstanding something?
|
|
#
?
Jun 11, 2013 12:10
|
|
|
nexus6 posted:In our current workflow we have three copies of any site: the live, public-facing version; a staging/preview version for testing/client approval before deploying new features; and a development version for working on. Yeah, just look into deployment tools to make this less tedious. You might want to keep production code on a separate branch, too.
|
|
#
?
Jun 11, 2013 13:02
|
|
|
You could also just not have the production branch; when a the pre-prod tests are complete and you're going to to push to production, make a tag on the staging branch (i.e "push-06112013"), and just copy files over to production (or use some kind of deployment tool). The reason to have a seperate prod branch would be if you are making commits to it, which doesn't really make sense. If someone finds a problem in prod they should commit to their branch and go through the workflow and not just do a fix in the prod branch. Plus if you have tags you can roll back easily.
|
|
#
?
Jun 11, 2013 16:39
|
|
|
|
| # ? May 17, 2024 21:25 |
|
|
nexus6 posted:Apologies if this has been asked/answered already, I'm still reading through this thread. As mentioned before, you should strongly consider using a deployment mechanism instead of using Git as a deployment mechanism. It CAN be done but it's not really the best tool for the job.
|
|
#
?
Jun 11, 2013 17:52
|
|