|
Mithaldu posted:TGit paired with Putty's pageant handles branching, diffing, logs, merging and most importantly, connectivity to remote repos with ssh keys completely transparently for you. Except it leaves pageant open, with a starting directory in wherever you first used it, which holds a file lock and prevents you from deleting/moving/renaming that folder. 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). I've had numerous operations mysteriously fail, and then succeed on the second try without doing anything differently. And other operations that failed for a good reason, but all TortoiseGit will give me is a pop-up dialog with a hex string in it.
|
# ? Mar 20, 2010 18:36 |
|
|
# ? May 11, 2024 16:27 |
|
Note in advance: I sort of assume that a developer working on windows knows how to administrate their own machine.Zhentar posted:Except it leaves pageant open, with a starting directory in wherever you first used it, which holds a file lock and prevents you from deleting/moving/renaming that folder. Zhentar posted:It will mark files as modified immediately after checking them out Zhentar posted:which will interfere with a lot of operations (no switching for you). Zhentar posted:I've had numerous operations mysteriously fail, and then succeed on the second try without doing anything differently. And other operations that failed for a good reason, but all TortoiseGit will give me is a pop-up dialog with a hex string in it. Zhentar posted:AutoCrLf handling is, at best, poor. As such, i never even noticed this being a problem at all.
|
# ? Mar 20, 2010 19:03 |
|
Mithaldu posted:I don't even know what this is supposed to mean. 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: - you check out a commit - git fucks up with the CRLF conversion somewhere - now git thinks all your files are modified because the line endings differ - you can't switch branches or anything because git thinks everything is modified even though it isn't Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.
|
# ? Mar 20, 2010 22:55 |
|
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: Must be an old and now fixed issue. I've used git across multiple platforms and versioning systems in projects of varying structures and nothing even remotely similar has happened. Thanks for explaining though.
|
# ? Mar 20, 2010 23:00 |
|
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: You can't git stash away the (non)changes?
|
# ? Mar 20, 2010 23:04 |
|
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: git reset --hard HEAD
|
# ? Mar 20, 2010 23:46 |
|
stash/reset might work if you realize what's happened immediately; however (at least back when this happened to me) the more common case was checkout, hack hack hack, status, oh dear it thinks everything is modified. And then you have to disentangle the real changes from the bogus ones before you can stash. These days I do most of my development on linux and all of it using LF linebreaks, so.
|
# ? Mar 21, 2010 00:42 |
|
ToxicFrog posted:stash/reset might work if you realize what's happened immediately; however (at least back when this happened to me) the more common case was checkout, hack hack hack, status, oh dear it thinks everything is modified. And then you have to disentangle the real changes from the bogus ones before you can stash. This wouldn't happen with my workflow, though it's not for everyone
That way, I can have the benefits of lots of small commits while I'm working something out, but master is one nice, linear history of what changed without all the back and forth of development.
|
# ? Mar 21, 2010 01:07 |
|
I only started using git a few weeks ago, so I've only used the current version of TortoiseGitOtto Skorzeny posted:You can't git stash away the (non)changes? I shall give that a try... And now I've got a shining example of TortoiseGit messages:
|
# ? Mar 21, 2010 02:26 |
|
Zhentar posted:I only started using git a few weeks ago, so I've only used the current version of TortoiseGit How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there. Edit: It's possible that the stuff in your repo has a directory set to read-only with the unix file flags and git tries to recreate that on windows and paints itself in a corner that way. This might even be a problem with git itself and not tgit, since all you're getting there anyhow is an error with the revert it does after saving to stash. The actual saving was fine. Mithaldu fucked around with this message at 10:36 on Mar 21, 2010 |
# ? Mar 21, 2010 10:33 |
|
Mithaldu posted:How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there. If what you are saying is true, shouldnt it be handled a little more sensibly by a front-end of git which is designed for windows users? At the very least it could pop up a dialog explaining to the user what you've just said here, which is more helpful than "Cannot reset index file revision to HEAD"
|
# ? Mar 21, 2010 17:52 |
|
Mithaldu posted:How the hell did you manage to gently caress up your system like that? I've been using it for a while now and never saw anything like what you got there. Looking at it it actually seems like you have some kind of permission problem with a directory being read-only there. Open handle can do it to; if so, Process Explorer can diagnose.
|
# ? Mar 21, 2010 18:18 |
|
tripwire posted:I can definitely feel where hes coming from though. I really don't know why people don't just use git's command-line interface. It's very easy to use and well-designed, and the error messages are much more helpful than whatever a wrapper would be able to guess at. Much easier than messing about with an additional layer between you and what's actually going on.
|
# ? Mar 21, 2010 19:10 |
|
Dammit guys, I'm almost still a newbie (realized i can branch just this thursday) to git and i can make sense of that message. And hell, it's not like the command line would be more useful since that message there is just the command line output copied into a message box. Taken apart: First it stored the current changes successfully into the stash THEN it did "git checkout-index" which failed BECAUSE it could not create "examples/findnameindexes.cpp" BECAUSE permission do do that was denied (likely by the file system) THUS the index file revision could not be reset to HEAD. So, in summary: Saving the stash went fine, but because of some permission problems it could not actually remove the saved changes from the working copy. Now, the permission problem could be either an inability to create "examples", due to read-only on the base directory; "findnameindexes.cpp" due to read-only on "examples" or because "findnameindexes.cpp" already exists and is not read-only. Since it's not trying to move or delete anything open handles are almost irrelevant, unless some amazingly dumb IDE has a read-only lock on "findnameindexes.cpp". However this is not a problem with git but with Windows and said IDE and if it is the case then git and tgit did all they could to report it. Figuring this poo poo out is not hard and all it takes is some common sense and reading comprehension. Seriously now guys. tripwire posted:If what you are saying is true, shouldnt it be handled a little more sensibly by a front-end of git which is designed for windows users? Additionally tgit is largely done by one man who is most certainly not slacking off: http://repo.or.cz/git-browser/by-commit.html?r=TortoiseGit.git As such, it's very possible that the author of tgit wasn't even aware that this could happen and had noone report it yet. Thanks. vvvv Mithaldu fucked around with this message at 20:45 on Mar 21, 2010 |
# ? Mar 21, 2010 20:04 |
|
Mithaldu posted:As far as i know (and i could be wrong) the only real way to get a gui frontend like this on git is to run the command line stuff and parse the resulting text. This means that the author has to do a poo poo-ton if matching and many possible combinations and situations that can be easy to overlook. Correct, and IMO this is one of git's biggest flaws; the lack of a "libgit" that programs can talk to directly makes it harder to write frontends for it relative to other VCSs, which in turn means frontend development for git tends to lag behind, limiting uptake among people who aren't fond of the command line interface.
|
# ? Mar 21, 2010 20:30 |
|
Mithaldu posted:Now, the permission problem could be either an inability to create "examples", due to read-only on the base directory; "findnameindexes.cpp" due to read-only on "examples" or because "findnameindexes.cpp" already exists and is not read-only. There were 14 other files in the same folder that had no issues. I didn't have the file open in any program. This one particular file was, for no apparent reason, deleted. I was able to restore the file by reverting the the folder afterwords. Since I hadn't made any changes to the file, I don't know if anything would have been lost. Considering that I have never had SVN delete files on me, this didn't exactly convince me to hop on the Git train.
|
# ? Mar 21, 2010 21:03 |
|
gently caress. Just switched to newest SVN, which seems to create a new problem when updating. I run svn from the command line and it wants user input every time it finds a file in conflict. I want it to leave the local changes alone and move on with the update without input, is that svn update --non-interactive?
|
# ? Mar 23, 2010 11:10 |
|
BizarroAzrael posted:gently caress. Just switched to newest SVN, which seems to create a new problem when updating. I run svn from the command line and it wants user input every time it finds a file in conflict. It should show you a list of options like (df) diff-full, (tf) theirs-full, (mf) mine-full and (i) ignore (or something like that, I'm going off memory). Just type "i" or whatever the option is for "deal with this later." Edit: But to answer your question, I believe yes, it's --non-interactive.
|
# ? Mar 23, 2010 11:48 |
|
musclecoder posted:It should show you a list of options like (df) diff-full, (tf) theirs-full, (mf) mine-full and (i) ignore (or something like that, I'm going off memory). Just type "i" or whatever the option is for "deal with this later." This update takes place overnight, as part of a larger process, so it needs to be automated. Might not be as bad as I thought though, it seems to do merges fine in the tests I've done, so it's a handful of exceptions. And it deals with unversioned files blocking versioned ones, which I used to have to work around.
|
# ? Mar 23, 2010 12:07 |
|
Problem: Error: Checksum mismatch while updating Error: '[filename]'; expected: Error: '71467c5d444b7e4869609f5993ad077b', actual: '0b590ed77b36a502b78885db58340307' Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout. Cleanup on the whole project didn't make a difference, and a new checkout is undesirable, can anyone tell me what happened here? The prior update stopped when it couldn't move a temp file over an existing one. The .tmp was left in the directory, though I don't know where it came from and why it wasn't coming from the repository. Would deleting the offending directory and doing an SVN update to restore it sort it out?
|
# ? Mar 25, 2010 11:40 |
|
BizarroAzrael posted:Would deleting the offending directory and doing an SVN update to restore it sort it out? I don't know. But you can move the file, try it, and move it back if it doesn't work.
|
# ? Mar 29, 2010 04:59 |
|
In hg, I want to see all the files that were changed from revision 40 to revision 41. I don't want to see the diff contents, I just want to know which files were changed. Currently, I do:code:
code:
|
# ? Apr 7, 2010 00:15 |
|
code:
|
# ? Apr 7, 2010 01:30 |
|
Or with hg 1.4 or newer:code:
code:
|
# ? Apr 10, 2010 07:50 |
|
Hey guys, If you remember I posted a question a while back about setting up a code versioning system at work. It then resulted in a few pages of debate, which I was not expecting. Well, I was hesitant at first about using a DVCS over an SVN, but after all the praise given to DVCS's and the sound arguments you guys put forward, I decided to give it a shot. All I have to say is wow, you were right. We're now using Mercurial and TortoiseHG, its easy to use, merging repositories is simple and conflicts are a breeze to resolve, even for an amateur like me. Thanks for all the assist goons, I would have made the wrong choice without all your help. Plus it was really entertaining to see you take apart SVN's so thoroughly.
|
# ? Apr 13, 2010 15:18 |
|
Knackered posted:Long ago, I was going to say something about your original post: Knackered posted:I was thinking of using a simple SVN over GIT/Mercurial. Since I'm in this thread, I may as well share some useful information too: 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). 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). If core.autocrlf = true, Git will translate everything to a CR+LF line ending on checkout. However, since it would be committed with LF line endings instead of the CR+LF in the current commit, it's marked as modified (even after a git reset --hard or git stash). I believe that the best way to fix this is to commit the changes, thereby fixing the line endings in the actual repository. This will have detrimental effects on git blame, though. I'm sure you could fix the line endings in all previous commits with git filter-branch, but that can be quite disruptive (see the documentation on recovering from an upstream rebase) Off the top of my head (i.e. I haven't had to do this in a while and I'm on a Linux machine now), I've found this sequence of operations to fix most CR/LF problems except for the one that I described above: code:
|
# ? Apr 13, 2010 18:01 |
|
I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN?
|
# ? Apr 14, 2010 15:44 |
|
HFX posted:I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN? The short answer: create a new branch (like git branch old) before running git svn rebase. I'm not sure if you should make new commits on the old branch, though. Repeated rebases of the same commits might not be handled correctly (though they seemed to be in my quick test).
|
# ? Apr 14, 2010 18:36 |
|
So I have to work with CVS and I was hoping to leverage git for this but I keep having problems with git cvsexportcommit. For example, I have a commit that touches a few files and I want to apply it to the cvs repository, right. Ok, here goes:code:
Then I took a look at the .cvsexportcommit.diff file git created and sure enough, the first diff starts on line 33. But the patch looks fine to me: the lines are just as expected. No one else has modified the file since the changes I've made. code:
Anyone got an idea how to fix this? I don't see why the diff doesn't have the correct line endings, that makes no sense. The source files are CRLF, why would diff change that? That's completely unhelpful.
|
# ? Apr 14, 2010 19:53 |
|
Lexical Unit posted:I'm running git from Mac OS X and developing on a Windows VM. This seems like a very bad idea, and I'm not surprised in the slightest that you're having problems. Are you using Git over a network mount, or something like that? I recommend installing msysgit in the Windows VM and using Git from there. If you're using it on OS X, you're probably well-versed in the command line and won't mind a sub-par GUI (though I really like SmartGit, and it just hit version 1.5). You should probably make sure that the repository's core.autocrlf value is set to false. msysgit sets that to true by default for new or cloned repositories, but Git on OS X won't. Your Git repository probably contains CR+LF line endings, and that combination can cause problems (as I mentioned a few posts ago).
|
# ? Apr 15, 2010 01:38 |
|
I'm getting lots of failed svn updates when there is a file on the repository and one by the same name on the working copy. I thought this issue was dealt with in 1.6.5, and even tested it, but it's still happening. Maybe it's unable to merge the filetypes in question, but it should still deal with that. Can anyone suggest what I need to do to make SVN work in spite of itself? Do I need to script something to move the files out of the way on the working copy side again?
|
# ? Apr 15, 2010 09:30 |
|
Okay I'm git-stupid and really stuck. I'm working with a project that other people are doing work in their won git forks on. Someone has several branches they want me to merge back. The problem is some of the branches have work on files that are completely removed so 'git merge branch1 other-remote/branch2' won't work because files are modified in other-remote/branch2 that no longer exits in branch1. It's work that I can just reject, so is there a way to merge all the changes for files that exist and just reject stuff that references files that no longer exist?
|
# ? Apr 15, 2010 21:58 |
|
NotShadowStar posted:Okay I'm git-stupid and really stuck. It was pretty easy for me to resolve, actually. I just put together a quick test repository which did it. I ended up with this: pre:[andrew@archand gittest]$ git merge other CONFLICT (delete/modify): b deleted in HEAD and modified in other. Version other of b left in tree. Automatic merge failed; fix conflicts and then commit the result. [andrew@archand gittest]$ git status # On branch master # Changes to be committed: # # modified: a # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # deleted by us: b # # Untracked files not listed (use -u option to show untracked files) [andrew@archand gittest]$ git rm b b: needs merge rm 'b' [andrew@archand gittest]$ git status # On branch master # Changes to be committed: # # modified: a # # Untracked files not listed (use -u option to show untracked files) [andrew@archand gittest]$ git commit [master 61a4207] Merge branch 'other' [andrew@archand gittest]$ vim a # successfully received other's changes [andrew@archand gittest]$ ls a [andrew@archand gittest]$
|
# ? Apr 15, 2010 22:11 |
|
I simply didn't think about marking the file as removed on the working branch. Thanks, this git stuff is way too meta for me still.
|
# ? Apr 15, 2010 22:23 |
|
NotShadowStar posted:I simply didn't think about marking the file as removed on the working branch. Thanks, this git stuff is way too meta for me still. While it's not directly related to your issue, you might understand git better if you take a look at `git help gitcore-tutorial`. It's got a bunch of info about how git works underneath. Everyone should really read it, it'll help you understand what's going on (for one tiny example, how to effectively use git-reset and why it works that way).
|
# ? Apr 15, 2010 22:34 |
|
Also check out chapter 9 of pro git. It's written by githubber Scott Chacon. I've only skimmed it and the whole book looks good, but ch 9 has all those diagrams I've seen him use at the ruby conferences and such which were a big help for me.
|
# ? Apr 15, 2010 23:23 |
|
Lysidas posted:This seems like a very bad idea, and I'm not surprised in the slightest that you're having problems. Are you using Git over a network mount, or something like that? Lysidas posted:I recommend installing msysgit in the Windows VM and using Git from there. If you're using it on OS X, you're probably well-versed in the command line and won't mind a sub-par GUI (though I really like SmartGit, and it just hit version 1.5). Lysidas posted:You should probably make sure that the repository's core.autocrlf value is set to false. msysgit sets that to true by default for new or cloned repositories, but Git on OS X won't. Your Git repository probably contains CR+LF line endings, and that combination can cause problems (as I mentioned a few posts ago). However, I figured out a workaround for this issue. Here it is in case anyone is interested: code:
|
# ? Apr 15, 2010 23:38 |
|
Pardot posted:Also check out chapter 9 of pro git. It's written by githubber Scott Chacon. I've only skimmed it and the whole book looks good, but ch 9 has all those diagrams I've seen him use at the ruby conferences and such which were a big help for me. Similarly the talk by Chris Wanstrath at DjangoCon (it's up on djangocon.blip.tv) is a good resource for the conceptual identity of git. Scott also gave a talk at pycon, avialable at pycon.blip.tv, that's good (it's about DVCS in general).
|
# ? Apr 16, 2010 00:11 |
|
Oh I've read piles of stuff on git. The man pages are the typical overly technical man page that already assumes you know everything, and the rest of it is just way different from svn. I'll get it eventually since I'm working more and more with github and have actual projects to do instead of abstract concepts.
|
# ? Apr 16, 2010 02:45 |
|
|
# ? May 11, 2024 16:27 |
|
If instead, you want a good approach of how you can use git day-to-day, I recommend http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html and all the links in the notes section. I've given up the interactive rebasing, though, in favor of git merge --squash topic-branch from master.
|
# ? Apr 16, 2010 09:01 |