|
Has anyone tried using the latest version of Git Extensions with VS2010 on Windows 7? I'm not getting the Git Extensions menu in VS. I've reinstalled, repaired, and even went back to the previous version to no avail. I made sure the VS2010 plugin was selected each time when I did the installations. Anyone run into this also?
|
#
?
May 20, 2010 17:56
|
|
|
|
| # ? May 10, 2024 12:25 |
|
|
Pardot posted:I've given up the interactive rebasing, though, in favor of git merge --squash topic-branch from master. For someone who only recently started rebasing, can you explain the rationale behind this?
|
|
#
?
May 20, 2010 23:48
|
|
|
Came by a strange occurrence in SVN just now, I ran svn status -u [working directory] and got a warning back about an "illegal repository URL ''". I thought it would be getting the URL from the .SVN folder in the directory, but svn update and svn info both worked without issue. Does anyone know what's going on? Svn status is part of a script I need working.
|
|
#
?
May 26, 2010 09:47
|
|
|
When you do an svn info, what URL does it output?
|
|
#
?
May 26, 2010 11:22
|
|
|
I've got a project hosted on github, that I'm totally rewriting. Starting from scratch. What's the recommended course of action? I'd like to keep the currently functioning version as the latest version available on the project page for now and then when I've got the rewrite functioning make it the latest available version. This is probably a common occurrence, but I'm new to version control and git.
|
|
#
?
May 26, 2010 14:45
|
|
|
Thermopyle posted:I've got a project hosted on github, that I'm totally rewriting. Starting from scratch. Rewrite it from scratch, committing locally to do so. When you're ready, push your changes to GitHub. If you aren't comfortable having your work in only one place (I'm not), make a bare clone of your repository, preferably copy it to a different machine that you have access to, and push to that repository quite often.
|
|
#
?
May 26, 2010 15:56
|
|
|
Thermopyle posted:I've got a project hosted on github, that I'm totally rewriting. Starting from scratch. Fork it, write in new fork, then pull back to original once done. Alternatively, just branch.
|
|
#
?
May 26, 2010 15:58
|
|
|
Lysidas posted:Rewrite it from scratch, committing locally to do so. When you're ready, push your changes to GitHub. To easily copy your repo to another machine, create a Dropbox account, set up your Dropbox directory (or a subdirectory within there) as a remote destination, and then just push to Dropbox so everything is automatically backed up.
|
|
#
?
May 26, 2010 16:06
|
|
|
Thermopyle posted:I've got a project hosted on github, that I'm totally rewriting. Starting from scratch. Yeah, branching sounds appropriate here. Make a "rewrite" branch, get it to where you want it (push updates to github if you like), then merge it back into master and push.
|
|
#
?
May 27, 2010 00:24
|
|
|
Lysidas posted:Rewrite it from scratch, committing locally to do so. When you're ready, push your changes to GitHub. It may be as much a philosophical question as a practical one, but pushing to an extra repo to avoid branching in a situation where it seems warranted seems more like it's extra work than a shortcut.
|
|
#
?
May 27, 2010 01:34
|
|
|
Spengler posted:It may be as much a philosophical question as a practical one, but pushing to an extra repo to avoid branching in a situation where it seems warranted seems more like it's extra work than a shortcut. It absolutely is appropriate to make a new branch, and I guess I considered it basic enough that I didn't mention it in my post (oops). I didn't think Thermopyle wanted to push that new branch to GitHub yet; he did say that he didn't want his rewrite available on the project page and I interpreted that as "anywhere on the project page". Now that I think about this more, pushing the new branch to GitHub is probably what he wanted (or close enough).
|
|
#
?
May 27, 2010 14:38
|
|
|
Either way you are going to end up with a merge commit that removes all the old files and adds all the new files, why not just make it a separate project 
Vanadium fucked around with this message at 14:50 on May 27, 2010 |
|
#
?
May 27, 2010 14:46
|
|
|
Vanadium posted:Either way you are going to end up with a merge commit that removes all the old files and adds all the new files, why not just make it a separate project Because it's not a separate project.
|
|
#
?
May 27, 2010 22:51
|
|
|
Not only is it not a separate project, but if you keep it in the same tree (eventually), I can check out the commit previous to your merge commit and get the old version. I don't have enough experience with git to know if it's possible, but could you just change the HEAD of master to point at the rewrite branch's HEAD when you're done (instead of merging the branches), or would that be idiotic?
|
|
#
?
May 28, 2010 02:10
|
|
|
Yes, with something like pre:git checkout master git tag old-version git reset --hard new-version This makes pushing master a non-fast-forward and will pretty much require people who have cloned your project to re-clone, though.
|
|
#
?
May 28, 2010 13:03
|
|
|
I've got a project (under git) I'd like to release, but without it's entire history. I basically want to release just the last few commits publically. What's the best way to do this while still maintaining the history privately?
|
|
#
?
Jun 1, 2010 02:05
|
|
|
the talent deficit posted:I've got a project (under git) I'd like to release, but without it's entire history. I basically want to release just the last few commits publically. What's the best way to do this while still maintaining the history privately? If you're OK with no history, use git archive. Otherwise, I have no idea.
|
|
#
?
Jun 1, 2010 02:10
|
|
|
The closest I can think of is to maintain a separate copy of the repository, use rebase --interactive to squash all but the commits you want to keep, and synch that with your complete repository manually.
|
|
#
?
Jun 1, 2010 03:15
|
|
|
Detailed instructions here (this describes a superset of what you want to do): http://progit.org/2010/03/17/replace.htmlScott Chacon posted:For example, say you want to split your history into one short history for new developers and one much longer and larger history for people interested in data mining. You can graft one history onto the other by replaceing the earliest commit in the new line with the latest commit on the older one. This is nice because it means that you don’t actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHAs).
|
|
#
?
Jun 1, 2010 05:01
|
|
|
I've been tasked with importing our giant Subversion repository (with full project history) into Git. One problem is that there are some large binary files that should never have been checked in, and I'd like to clean that up so it's not part of the Git history. Would it be better to go ahead and import the Subversion repository, then use git-filter-branch to remove the offending files? Or should I remove them from Subversion before importing? (I'm not entirely sure how to do the latter in such a way that they're not present at all in the history.) Ideally, we want to have both Git and SVN available while we gradually migrate everyone to Git, so will need to be able to keep them in sync. I know how to do that using git-svn, but am not sure how that will be affected by using git-filter-branch. Can anyone offer any guidance as to which approach is least likely to cause problems, or offer other suggestions?
|
|
#
?
Jun 2, 2010 23:55
|
|
|
Unless you want to edit git-svn's binary rev_map files, filter-branch will break git-svn. I've done it, but wouldn't recommend it. Trying to have people use both systems at the same time is going to be problematic, as a repo meant for use with git-svn is going to look rather different from one meant to be a full conversion. Creating a good conversion of a repository is likely to involve a bit of history rewriting to match git's world view. You also won't want git-svn's ugly revision markers on all of the commit messages. Doing any of that will mostly break git-svn.
|
|
#
?
Jun 3, 2010 17:48
|
|
|
I've just started using git on a home project after using Perforce at work and svn at home for years... Part of the project is a web server component and a heavy weight client. For ease of iteration I'd like to have the web server component on the live server pull from a local repository but I don't want to have the client code on this public facing web server at all. Looking around I thought what I wanted was sub modules, so I set up something like: project_name \-server \-client This is incredibly awkward. It seems I now can't do a single commit in server & client code, the repositories are considered completely separate. And project_name isn't updated unless I manually add server / client for each change. And when I do that, the commit history of the changes inside client/server is lost. What I'd like is the equivilant of svn co http://repo/project_name/server . or a p4 client spec of //project_name/server/... //client_spec/ The requirements basically are: - No client code on the server - Atomic commit to changes in the protocol (Server & client go together) - Single changelog of all changes I guess even some kind of git local ignore would work where I could just say ignore client?
|
|
#
?
Jun 4, 2010 01:39
|
|
|
Hughlander posted:The requirements basically are: Submodules are pretty awkward if you don't know exactly how they work. They're designed mostly for when your project depends on another project, which you also want in your build tree (i.e. to track local changes to the "other project" and merge them back into upstream releases). This isn't your use case. It sounds to me like you just want one repository. Why do you have the requirement of "no client code on the server"? What harm are the files doing just sitting there? Alternatively, you can ditch the atomic commit & single changelog requirements and just make two separate git repositories. Or maybe someone knows a better idea.
|
|
#
?
Jun 5, 2010 01:50
|
|
|
Hughlander posted:sub modules I don't entirely understand what you want, but just creating a directory, adding it to gitignore and cloning your client repo into it should work fine. I'm doing something similar on one of my production servers to handle multiple sites with per-site differences and a shared codebase.
|
|
#
?
Jun 5, 2010 01:58
|
|
|
ColdPie posted:It sounds to me like you just want one repository. Why do you have the requirement of "no client code on the server"? What harm are the files doing just sitting there? Alternatively, you can ditch the atomic commit & single changelog requirements and just make two separate git repositories. I don't trust a public facing webserver not to be hacked, if it is I'd rather not have source code that doesn't need to be there on it. Atomic commits are far more important to me than not having the client source on the server. Mithaldu posted:I don't entirely understand what you want, but just creating a directory, adding it to gitignore and cloning your client repo into it should work fine. I'm doing something similar on one of my production servers to handle multiple sites with per-site differences and a shared codebase. I was under the impression that gitignore itself would be in the repository? Is why I had asked if there was a way of doing a local repository only gitignore while also taking the gitignore from the origin (I believe that's the right term) repository. Though I suppose I could just deal with merge issues on pull.
|
|
#
?
Jun 5, 2010 02:05
|
|
|
Hughlander posted:I was under the impression that gitignore itself would be in the repository? Is why I had asked if there was a way of doing a local repository only gitignore while also taking the gitignore from the origin (I believe that's the right term) repository. Though I suppose I could just deal with merge issues on pull. You can use .git/info/exclude
|
|
#
?
Jun 5, 2010 02:11
|
|
|
mr_jim posted:You can use .git/info/exclude Thanks, I missed that one line in the man page the 3 times I went over it  Looks like I got a bit of repository rework to do.
|
|
#
?
Jun 5, 2010 02:22
|
|
|
Is there an easy way to find out what version a repository was at at a given time on the command line? Say I wanted to update to the version for 4PM every day? Would I need to do an SVN log on the project and use a FIND command to get the last commit revision before that time? Or is there some existing function to do it?
|
|
#
?
Jun 9, 2010 17:46
|
|
|
BizarroAzrael posted:Is there an easy way to find out what version a repository was at at a given time on the command line? Say I wanted to update to the version for 4PM every day? Would I need to do an SVN log on the project and use a FIND command to get the last commit revision before that time? Or is there some existing function to do it?
|
|
#
?
Jun 9, 2010 18:01
|
|
|
Mine GO BOOM posted:svn up -r "{`date '+%Y-%m-%d 16:00:00'`}" Sorry, it says there's a syntax error, and I've not been able to find another example.
|
|
#
?
Jun 10, 2010 13:40
|
|
|
BizarroAzrael posted:Sorry, it says there's a syntax error, and I've not been able to find another example.
|
|
#
?
Jun 10, 2010 16:40
|
|
|
BizarroAzrael posted:Sorry, it says there's a syntax error, and I've not been able to find another example. I don't use subversion, but check out this section about revision dates in the subversion book. It lists all valid date formats. It seems you should swap the quotes and curly brackets, then Mine GO BOOM's suggestion should work.
|
|
#
?
Jun 10, 2010 17:21
|
|
|
I'm trying to convert an svn repo to hg...code:Edit: I just realized 819 and 818 are revisions. Why didn't it start at 932, which is the latest in the svn repo? Edit2: It's done a few more revisions, counting down. Really, really slowly. Is it typical for hg convert to process 1 revision every 5-20 seconds? epswing fucked around with this message at 04:51 on Jun 18, 2010 |
|
#
?
Jun 18, 2010 04:24
|
|
|
Yes. It has to grab each revision from subversion and subversion is really slow.
|
|
#
?
Jun 18, 2010 06:54
|
|
|
Finally got things converted and cloned and so forth. So my initial repo was created with 'hg convert' by hg 1.3.x, cloned to a central repo which is running hg 1.1.1, and I'm running hg 1.5.4 on my desktop. are there issues with running all these different versions?
|
|
#
?
Jun 18, 2010 21:47
|
|
|
molinari posted:I don't use subversion, but check out this section about revision dates in the subversion book. It lists all valid date formats. It seems you should swap the quotes and curly brackets, then Mine GO BOOM's suggestion should work. Got distracted and had to down tools for a bit, but this is exactly what I need, thanks.
|
|
#
?
Jun 22, 2010 16:22
|
|
|
Zhentar posted:AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you). ToxicFrog posted:The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens: Lysidas posted:I've seen this happen and I believe I have an explanation for it. I would guess that your repository contains files with CR+LF line endings (i.e. the actual content of the blob objects). I was very interested to see this commit when git pulling my clone of Git itself. Finn Arne Gangstad <finnag@pvv.org> posted:autocrlf: Make it work also for un-normalized repositories 
|
|
#
?
Jun 22, 2010 20:58
|
|
|
Mercurial (or DVCS in general) question. I have a few contractors writing code for me. I'm thinking of this architecture: code:I'm new to distributed version control, but I think this makes sense. Educate me! How does this sound? How should code get from them to me, i.e. should I be Pulling from them or should they be Pushing to me? Or using patches? Does it matter? Edit: I should add that my goal is to preview/test their work in my development environment before allowing it into the central repo, but if it does get into central I want their history preserved. epswing fucked around with this message at 04:25 on Jun 29, 2010 |
|
#
?
Jun 29, 2010 04:00
|
|
|
epswing posted:Mercurial (or DVCS in general) question. Looks pretty sane to me. This is basically how the system we use at my job works. You don't want them pushing to your repository, you should be pulling from theirs. Patches or pulling would both work, it just depends on whether email is easier than setting up the push/pull permissions, public repositories, or whatever.
|
|
#
?
Jun 29, 2010 04:32
|
|
|
|
| # ? May 10, 2024 12:25 |
|
|
ColdPie posted:You don't want them pushing to your repository, you should be pulling from theirs. Why is that? I ask because allowing them to push to me seems like a reasonable approach when dealing with a small number of people. Even with push_ssl = False and allow_push = *, can't I flip on hg serve, accept the push, and flip it off again? No ssl issues, no extra public/private keys (other than the ones required for them to pull from Central), they aren't required to forward a port through their router to allow hg serve to work on their machines (only I need to do this), no extra external repos. The only downside I see is that we have to both be at our machines at the same time, or work out a schedule ("My machine will be available to accept your push from 9-10pm tonight"). Please tell me if I'm being an idiot...but this seems viable for small groups, no? epswing fucked around with this message at 06:45 on Jun 29, 2010 |
|
#
?
Jun 29, 2010 05:32
|
|