|
Thanks. It isn't working out as cleanly as I had hoped because Rails doesn't seem to like the way I did this, but I think I can make it work. Edit: just needed rake db:migrate as it turns out, everything else was as clean as I had hoped. Thanks again for the help. Sub Par fucked around with this message at 21:22 on Mar 25, 2013 |
#
?
Mar 25, 2013 21:20
|
|
|
|
| # ? May 11, 2024 10:57 |
|
|
wwb posted:Atlassian has released SourceTree for Windows -- an excellent GUI git client that blows just about any of the other windows options I'm aware of away. Been using this since they released it and it's nice, but actually ran into a legitimate case where Github's client is better. When you're forced onto Windows XP (  ), SourceTree doesn't work 
|
|
#
?
Mar 26, 2013 20:51
|
|
|
I am highly intrigued by the upcoming Changeset Evolution features in Mercurial. It seems like the perfect blend of git's "refactor history at will" and hg's "history is immutable (except when you install the right extensions)" philosophies. I like the ability to change history that has already been shared (as long as it's in the right phase) and have the changes propagate correctly. Granted that wouldn't really affect me since I pretty much work alone, but I like the idea of it. I also like the idea of marking changesets as obsolete rather than removing them entirely. I don't need to pollute the downstream history with my 37 commits instead of one nice commit, but it might be nice to have everything still in my personal history so I can maybe see what I was thinking. As much as I like hg, I do think the immutable history philosophy has some unintended consequences. Finding out about the Changeset Evolution (and also writing this post) have definitely made me re-examine my current workflow, and I now see how broken it is. With git, you're encouraged to "commit early, commit often" because you can just throw away any garbage and squash your bite-sized commits when you're ready to share your changes. With hg, immutable history encourages people to commit only when it's perfect, since who wants to have a permanent record of that stupid thing you tried or the 15 commits in an hour tweaking some CSS or whatever? Sure rebase and histedit exist, but their status as extensions makes them second-class citizens. Cleaning up after yourself history-wise should be as natural as branching and merging and committing in general, but the hg answer to "how do I clean up my history" seems to have been "don't". So then when idiots like me (who haven't used any type of VCS before, and definitely aren't familiar with git) come up with workflows, they do it wrong. In my case, when I was first reading up on hg, I saw that mq was a big cool thing that let you have mutable history, so when I need mutable history I've been using mq along with qrefresh and qfinish. Well, that leaves me the desired one big commit at the end, but it also means that while I'm working I only have one big commit and a bunch of uncommitted changes I don't yet want to save with qrefresh. Well, that's stupid. I'm sure mq is a useful tool, but I shouldn't be using it for this purpose. So from now on, it's commit like crazy and then rebase and collapse and histedit when it's time to share.
|
|
#
?
Apr 1, 2013 20:39
|
|
|
Personally I like the no editing history without jumping through hoops thing, and I don't find it to be a downside to not have perfect code on every commit but I'm probably in the lunatic fringe.
|
|
#
?
Apr 1, 2013 21:52
|
|
|
wwb posted:Personally I like the no editing history without jumping through hoops thing, and I don't find it to be a downside to not have perfect code on every commit but I'm probably in the lunatic fringe. I think it's practical and people who worry about commit histories are lunatics 
|
|
#
?
Apr 1, 2013 22:20
|
|
|
wwb posted:Personally I like the no editing history without jumping through hoops thing, and I don't find it to be a downside to not have perfect code on every commit but I'm probably in the lunatic fringe. Having come from SVN and Perforce, I consider mutable history to be a godsend. We exercise code reviews, which means that I commit my changes, send it out, incorporate feedback, send another review out, etc until accepted. I can then rebase everything to one commit and push that. No muss, no fuss, and a minimum of "whoops forgot this one thing" corrections. I can and will still do them, but no one will ever know.
|
|
#
?
Apr 1, 2013 22:45
|
|
|
Jethro posted:In my case, when I was first reading up on hg, I saw that mq was a big cool thing that let you have mutable history, so when I need mutable history I've been using mq along with qrefresh and qfinish. But otherwise, yeah, the problem with mq is that it's a bolt-on often used to make mutable histories is that itself isn't a first-class citizen and suffers from limitations, such as not being able to publish a patch stack without itself having an immutable history. When I first used mq, it felt fairly liberating, but what I failed to understand at the time was that I was still constrained by the inflexibility of the underlying system, and the real liberation didn't happen until I later moved to git. Since moving to git I've adoped a workflow where certain published branches are work-in-progress and known to have mutable histories that I rebase quite often. It's only when I finally merge that branch into a stable one that it's frozen in time. That's basically how I used mq, except that I can publish the work-in-progress branch and folks can see what's going on, even if it's subject to change or being purged. I'm firmly of the opinion that hg is an "easier" VCS, especially for folks coming from a svn background, until it's time to do tricky things with history. In contrast, git has conceptually more complicated primitive operations, but once understood, it's a lot more flexible.
|
|
#
?
Apr 2, 2013 00:00
|
|
|
Volmarias posted:Having come from SVN and Perforce, I consider mutable history to be a godsend. We exercise code reviews, which means that I commit my changes, send it out, incorporate feedback, send another review out, etc until accepted. I can then rebase everything to one commit and push that. No muss, no fuss, and a minimum of "whoops forgot this one thing" corrections. I can and will still do them, but no one will ever know. You can still do all that, just don't commit to your main branch until you've gone through the process. Compared to SVN/P4, branching is trivial so you can just create a feature branch to do the code review on.
|
|
#
?
Apr 2, 2013 15:08
|
|
|
ExcessBLarg! posted:One thing useful about mq that's not as easy to do with "git rebase" is "commenting out" a patch from the series file that you don't want applied now, but may want to reapply later. One important caveat: When you perform history editing operations in git, you aren't really editing history (assuming I correctly understand how git works). git is based on explicitly marking certain commits as "interesting" (i.e. by tagging or creating branches). When you rebase, you create new commits and move branches, but the old commits are, technically, still there. They are just no longer "interesting" (since they no longer have a branch pointing to them) so they will get garbage collected eventually. In hg, you can always see every changeset. So when you edit history with rebase or histedit (or commit --ammend), you really are removing the changesets as soon as you are done creating the new ones (unless you specify --keep). Re-writing history is seen as dangerous and destructive because, in hg, it is. This is another one of those things that I hadn't fully grasped until I started writing this post. So if hg is going to embrace history re-writing (as is right and good), it will need some concept of "changesets I no longer care about", which is what this does.
|
|
#
?
Apr 2, 2013 19:17
|
|
|
Speaking of Mercurial: I just added multithreading to my project, but, because I'm a living coding horror, it actually made everything slower despite properly utilizing all 4 cores  . Anyway, what I want to do is roll back to the last commit to work on the more important stuff, while retaining the multithreaded changes for when I want to revisit this later. Is this what named branches are for? This area of mercurial isn't quite clear to me yet so I'm not too sure what's the correct approach here would be.
|
|
#
?
Apr 2, 2013 20:34
|
|
|
Gounads posted:You can still do all that, just don't commit to your main branch until you've gone through the process. Compared to SVN/P4, branching is trivial so you can just create a feature branch to do the code review on. Right, and that's what I'm doing. The point is that when I'm done and I merge the branch back to master, I can squash everything into one commit, if I so please, so there's no "oops forgot a foobar" commit messages. Compared to SVN where the change history does include that information as metadata if you branch properly, it's much cleaner.
|
|
#
?
Apr 2, 2013 21:10
|
|
|
mobby_6kl posted:Speaking of Mercurial: So, commit your changes on the current branch. Then hg update your working directory to the last "good" commit before you started the multithreading. Your multithreading changes will still exist, but the files you're working on will look like they did before you started. Then you just continue on making changes and committing them like before. You might want to bookmark the multithreading commit just to keep track of it, or maybe clone your repository and do any future development of the multithreading in there.
|
|
#
?
Apr 2, 2013 22:21
|
|
|
Jethro posted:You might want to bookmark the multithreading commit just to keep track of it, or maybe clone your repository and do any future development of the multithreading in there. What's the difference between a bookmark and a tag? Is a bookmark mutable? I hate to bring up the "git is actually conceptually simpler in the end" bit, but if this were in git, I would spawn multithreading off into a named branch, and if I decided to fold it back into the mainline later you can just purge the branch from a published repo.
|
|
#
?
Apr 3, 2013 00:35
|
|
|
I would probably split that into a named branch but we do CI based on named branches as well so we might be odd in this respect. You can close the branches in any event so they don't have to stay alive forever.
|
|
#
?
Apr 3, 2013 01:37
|
|
|
Jethro posted:One important caveat: When you perform history editing operations in git, you aren't really editing history (assuming I correctly understand how git works). git is based on explicitly marking certain commits as "interesting" (i.e. by tagging or creating branches). When you rebase, you create new commits and move branches, but the old commits are, technically, still there. They are just no longer "interesting" (since they no longer have a branch pointing to them) so they will get garbage collected eventually. This is correct. Commits in git are immutable; "history rewrite" commands actually create completely new sets of commits and then rearrange branch pointers to point to the new commits. You can still view the old ones if they've been tagged or are referred to by non-rewritten branch pointers, or by using tools like the reflog. Fully orphaned commits (i.e. not referred to by any tags or branches) will eventually "expire" and be garbage collected. quote:In hg, you can always see every changeset. So when you edit history with rebase or histedit (or commit --ammend), you really are removing the changesets as soon as you are done creating the new ones (unless you specify --keep). Re-writing history is seen as dangerous and destructive because, in hg, it is. This is another one of those things that I hadn't fully grasped until I started writing this post.  mobby_6kl posted:I just added multithreading to my project, but, because I'm a living coding horror, it actually made everything slower despite properly utilizing all 4 cores In git I would just create a new branch for this (git branch multithreading), rewind master (git reset --hard last-good), and then at some future point, when threading was ready, merge it back into master (git merge multithreading). I'm not clear on how Hg branches are different from git branches beyond "they're different", though.
|
|
#
?
Apr 3, 2013 02:54
|
|
|
ExcessBLarg! posted:Are named branches something that hg requires you to keep around forever? quote:What's the difference between a bookmark and a tag? Is a bookmark mutable? quote:I hate to bring up the "git is actually conceptually simpler in the end" bit, but if this were in git, I would spawn multithreading off into a named branch, and if I decided to fold it back into the mainline later you can just purge the branch from a published repo. E: The hg wiki has a reasonable explanation of how branches work in hg http://mercurial.selenic.com/wiki/Branch E2: ToxicFrog posted:In git I would just create a new branch for this (git branch multithreading), rewind master (git reset --hard last-good), and then at some future point, when threading was ready, merge it back into master (git merge multithreading). I'm not clear on how Hg branches are different from git branches beyond "they're different", though. Jethro fucked around with this message at 18:49 on Apr 3, 2013 |
|
#
?
Apr 3, 2013 03:08
|
|
|
I would absolutely love it if when using a given open source library or application, I could see that the person in charge keeps on pushing broken and retarded changes to the public, rather than having a pristine history that someone spent days refining to look good and just be surprised by all of the dumb poo poo when I actually get to use it and try to upgrade.
|
|
#
?
Apr 3, 2013 13:43
|
|
|
MononcQc posted:I would absolutely love it if when using a given open source library or application, I could see that the person in charge keeps on pushing broken and retarded changes to the public, rather than having a pristine history that someone spent days refining to look good and just be surprised by all of the dumb poo poo when I actually get to use it and try to upgrade. Thing is, with a DVCS, just because there's broken poo poo in the history doesn't mean it was ever publically visible. I commit a lot of things that don't work yet because I still want a record of my work. It just doesn't get pushed to any public repo until it's tested and working.
|
|
#
?
Apr 4, 2013 02:52
|
|
|
I make at least one commit per minute while doing things since having uncommitted things makes me only slightly less twitchy than unsaved things. Most of these commits are eventually removed entirely, and those that aren't are completely rewritten at least once. I have no idea how I'd survive with a VCS without history editing. Actually, I do know. I'd use git for everything and write git-Dumb VCS bindings if they don't already exist.
|
|
#
?
Apr 4, 2013 09:34
|
|
|
I thought the whole point of source control is to have a record of mistakes and their solutions. Scrubbing it squeaky clean defeats the purpose. If you want to have easy access to 'good' code, use whatever feature your vcs makes available; branches, tags, whatever. What's the positive attributes of a 'clean' history? A sense of accomplishment?
|
|
#
?
Apr 4, 2013 10:54
|
|
|
As always, Linus has said this better than I'll be able to. EDIT: Though more detail can't hurt. It depends on what you mean by "mistakes". If it's a mistake in the sense of "this algorithm didn't work; here's why I switched to another", then that probably should be published. The idea is to get rid of a ton of "forgot this file", "oops revert what I shouldn't have committed", "intermediate bug fix #2" commits -- these are meaningless to someone who's examining the history later, either for a code review or to track down a bug. Lysidas fucked around with this message at 13:36 on Apr 4, 2013 |
|
#
?
Apr 4, 2013 13:32
|
|
|
If you don't keep the tree working or building at every intermediate stage when you push, that means "git bisect" or other such tools are pointless. If you do:
and then try to git bisect later, you can't test any of those commits except the last one. In that situation, I make a private branch, squash the compile fix against A, and then bisect against that, and then delete the branch when it's done. It's possible to do in git (not so sure about hg), but really annoying.
|
|
#
?
Apr 4, 2013 13:35
|
|
|
Committing on every keystroke is good when you are hacking away on a new feature or a bugfix or whatever, but when it comes time to share your work with other people (or even just go back and look at it yourself in a year) it all becomes just noise. You (most of the time, probably) don't want to collapse everything into one pristine commit, but cleaning up so that the history is understandable is a good thing.
|
|
#
?
Apr 4, 2013 14:11
|
|
|
KARMA! posted:I thought the whole point of source control is to have a record of mistakes and their solutions. Beyond that, the "purpose" of using a VCS on a specific project depends on the values of the project itself. Often its to facilitate sharing and collaborative development, to provide historical record of code, to enforce commit permissions/ACLs, etc. But not all projects use these features in the same way, or agree on the same set of values. Which is why the VCS concept has been rewritten so many times. KARMA! posted:What's the positive attributes of a 'clean' history? It's pretty well accepted that much of the utility of a VCS for knowledge sharing and historical anaylsis comes from having useful commit messages. There is such a thing as "useless commmit messages", or worse "useless commits" that don't really offer anything of value, or even provide negative value by introducing more noise into the history. When working with a VCS where commits are immutable (or more specifically, when commits are forever part of the source history with no means to purge and replace them), folks often wait on commiting a change/fix until a final solution is in place and it can be sufficiently well documented. However, in doing so, they often run into the problem where quick interim solutions they're hashing out for testing purposes, for which they can't be bothered to write a sensible commit message, has one of two fates: (i) committed into the source tree, where they're often of the useless commit variety and add noise, or (ii) aren't committed at all, often invoking the wish that "I had a VCS for changes to my changes". It's particularly the latter that encouraged the popularity of things like quilt, mq for Mercurial, etc. The role of history rewriting here is that you can commit freely and often the little stupid poo poo that's not likely to go anywhere, but the VCS still provides a mechanism for cheap versioning. Then when you're really done you can cleanup your hacks and push something that's sensible and useful to share to the world.
|
|
#
?
Apr 4, 2013 18:28
|
|
|
I need to get into Source Control for all of my website projects. We do website development/maintenance for a bunch of clients and currently have no source control in place. I would love somethign that can track them in a dev environment, and then come up with an automated build script that will roll out the updates. Can you give me some suggestions on how you would implement source control in this environment? We have a VPS, sites and such are running on cPanel. We have a development account, and add subdomains to it for each site we develop. Sites are usually coded using Notepad++ with the built-in FTP client editing everything live on the dev account. We build the sites there, and when it's time to release, we create a new account for the site, create a new mysql database under that account, copy the files from the dev subdomain to the new account's public_html, and export the database from the dev site and import it on the new production site. I'd love to implement some sort of source control so we can better keep track of changes we make, and then come up with some sort of deployment script that will mostly automate the transfer from the dev to the production environment. Any suggestions?
|
|
#
?
Apr 15, 2013 14:51
|
|
|
Maniaman posted:I need to get into Source Control for all of my website projects. We do website development/maintenance for a bunch of clients and currently have no source control in place. I would love somethign that can track them in a dev environment, and then come up with an automated build script that will roll out the updates. Can you give me some suggestions on how you would implement source control in this environment? You say "we". There aren't multiple people modifying the same site concurrently, are there? Since you're developing directly on the site, you'll probably need to do your source control actions on there as well via a shell account. Alternately, you'll need to have a local copy that you bring back to your machine after doing development which you can check into source. The best would be if you could develop on a local machine and do your source control locally. You make your changes, check them in, then deploy to dev via source control, and later to qa or prod.
|
|
#
?
Apr 15, 2013 22:26
|
|
|
So I have developed a feature, "A" off the "dev" branch. Let's say I make a PR for A and while it's being reviewed dev gets other commits/merges into it. I need to create a feature B that I branch off of A, however once A eventually gets merged back into dev I would like B to be based off dev instead of A so I can do local git rebases without affecting any commits that are part of origin/dev. I haven't done this yet but I'm thinking that once A gets merged into dev, I just go back onto the dev branch, create a new temp branch, "C" then merge the old B branch into C.
|
|
#
?
Apr 17, 2013 22:22
|
|
|
Strong Sauce posted:So I have developed a feature, "A" off the "dev" branch. Let's say I make a PR for A and while it's being reviewed dev gets other commits/merges into it. I just wrote a bunch of  that I realize actually boiled down to the same thing in git. Yes, this, but with rebasing.
|
|
#
?
Apr 18, 2013 01:47
|
|
|
Strong Sauce posted:I haven't done this yet but I'm thinking that once A gets merged into dev, I just go back onto the dev branch, create a new temp branch, "C" then merge the old B branch into C.
|
|
#
?
Apr 18, 2013 03:51
|
|
|
Strong Sauce posted:So I have developed a feature, "A" off the "dev" branch. Let's say I make a PR for A and while it's being reviewed dev gets other commits/merges into it. You don't really need to do anything with a 'C' branch. It helps to think of this kind of stuff if you remember that you don't really branch off a branch, but off a commit. Your 'B' branch isn't really branched off 'A', it's branched off a specific commit on the 'A' branch at the point that you branched it. So once the pull request is accepted and 'A' is on dev, the ancestor commit is on dev, and 'B' is already branched off of dev in a sense.
|
|
#
?
Apr 18, 2013 12:06
|
|
|
I've got a rather annoying conflict that prevents me from saving my work:quote:fatal: Reference has invalid format: 'refs/heads/master (laptop's conflicted copy 2013-04-16)' I use Dropbox to store my work, so some conflict has apparently emerged at some point - presumably when editing a single Markdown file. There are currently two ref heads, one "master", and one "master (conflict etc.)" file inside .git/. How do I resolve such a conflict?
|
|
#
?
Apr 18, 2013 15:38
|
|
|
What's the closest thing to SourceTree for Linux? I see people praising it all the time, but it's Windows/Mac only...
|
|
#
?
Apr 18, 2013 17:14
|
|
|
ufarn posted:I've got a rather annoying conflict that prevents me from saving my work:
|
|
#
?
Apr 18, 2013 23:04
|
|
|
I've made a thing for a client, meant to be real rough stuff job merely to test the waters on what he wants to do. Anyway I'm doing the project with bitbucket as the repository and he'd like to be able to access and modify files in the repo to customise what I've put together for him. That's easy enough, but I don't want to give him SSH access to deploy the changes, rather I just want to set up a cron job or something that will listen for changes to the repository, and when there are changes to the master branch, pull and then run a script to deploy the changes. What's the easiest way to do this?
|
|
#
?
May 19, 2013 04:01
|
|
|
You can set up a service hook at bitbucket to automatically POST a url of your choice when commits are pushed to it, and then you just have to run the deployment script whenever that URL is hit.
|
|
#
?
May 19, 2013 04:52
|
|
|
Cheers, definitely the easiest solution, good that I can put it behind basic authentication too. Did the trick.
|
|
#
?
May 19, 2013 11:08
|
|
|
So we switched over from a locally hosted subversion to github three months ago and my devs still hate the guts out of git. Rebase/squashing is arcane magic to them so I got all those merge commits and whatnot. I don't get what's so hard about git, I haven't had trouble using rebase. Is it really that hard or are my guys just lazy and too used to svn?
|
|
#
?
May 20, 2013 20:16
|
|
|
Git lets you have multiple workflows so you really just need to mandate one and demand everyone use it.
|
|
#
?
May 20, 2013 21:40
|
|
|
"Oh no, my history reflects what's actually happened, woe is me!"
|
|
#
?
May 20, 2013 22:07
|
|
|
|
| # ? May 11, 2024 10:57 |
|
|
Not sure if this question has been asked and answered yet. I didn't see it, though I admit that I just skimmed the thread. I have a git repo that I have a fabric script (really, a fabfile directory module) that uses a directory and its subdirectories to determine which stored procedures to deploy to a MySQL server. That directory is at the same level as the fabfile directory that operates on that data. The stored procedure stuff is to be maintained by the data group while the script itself is maintained by me (I handle releases). I want to keep my script separate from the stored procedures directory in repo history, that way I can version just the procedures and keep it separate from my versioning of the script. Basically I want to always use the most up-to-date version of my script but have the option of rolling back to previous versions of the stored procedures. I've come up with two options for this:
|
|
#
?
May 21, 2013 16:52
|
|