|
Wideshanks posted:Is there a way to use hg-style shortcuts for the unambiguous commands in git? E.g. type "git co" for "git commit" / "git stat" for "git status"? See alias in git-config(1). Here's some I use day-to-day: pre:[alias] cfix = commit -a --amend rebi = rebase --interactive rebc = rebase --continue cp = cherry-pick -x rebo = rebase origin bg = bisect good bb = bisect bad
|
# ? Feb 1, 2012 00:01 |
|
|
# ? May 10, 2024 09:29 |
|
ColdPie posted:See alias in git-config(1). Here's some I use day-to-day: Oh you sweet, beautiful bastard. Time to convert my bash aliases: alias cgh='cat .git/HEAD' alias ga.='git add .' alias gbv='git branch -v' alias gc='git commit' alias gcae='git commit --allow-empty' alias gcaem='git commit --allow-empty -m' alias gcof='git checkout -f' alias gl='git log' alias gl1o='git log -1 --oneline' alias glgo='git log --graph --oneline' alias grb='git rebase' alias grba='git rebase --abort' alias grh='git reset --hard' alias grhoh='git reset --hard orig_head' alias grl='git reflog' alias groh='git reset orig_head' alias gs='git status' alias gsb='git show-branch' alias gsbm9='git show-branch --more=999' alias gsl='git stash list' alias gsrha='git show-ref --head --abbrev'
|
# ? Feb 1, 2012 01:03 |
|
If you change your cgh alias to "git symbolic-ref HEAD", it'll work anywhere, not just the top level directory.
|
# ? Feb 1, 2012 01:30 |
|
ColdPie posted:See alias in git-config(1). Here's some I use day-to-day: You can also use tab completion for most git commands
|
# ? Feb 1, 2012 04:07 |
|
Man, when my company switched us to GIT, I really wish they actually hired someone who knows how to use GIT. It feels like the blind leading the blind here. There is a central 'master' branch (or repository or whatever) that is the latest, up-to-date code. Whenever I create a new branch to start working on a new feature I run code:
code:
If I try code:
quote:You asked me to pull without telling me which branch you want to merge with, and 'branch.new_branch_name.merge' in your configuration file does not tell me, either. My colleague handles this issue by creating a new branch and cherry picking his commits. He usually makes a single commit whereas I prefer 'Commit early, commit often' and I have several. I don't want to run cherry-pick dozens of times but I haven't had any luck with rebasing either. I have read both http://feeding.cloud.geek.nz/2010/07/cherry-picking-range-of-git-commits.html and http://stackoverflow.com/questions/509859/what-is-the-best-way-to-git-patch-a-subrange-of-a-branch but in both cases my commits do not appear on top of the latest commits: I still have to do git pull to get up-to-date which overwrites my commits.
|
# ? Feb 2, 2012 12:43 |
|
You can rebase master onto your branch.code:
There are a lot of entirely free books online for Git. http://progit.org is one.
|
# ? Feb 2, 2012 13:22 |
|
Rebasing generally isn't going to do a lot to avoid when conflicts happen though. Depending on when commits occurred, you may get lucky, but it certainly doesn't mean you'll never need to deal with them. nexus, one thing to keep in mind when working on branches that persist for longer than a day or so is that it's possible, and even recommended, to pull in changes from master periodically when you're working on your branch. If you do this, you'll reduce the odds of hitting conflicts when you have a huge amount of changes in your branch that need to be merged with a huge amount of changes in the master branch. I would personally start off each morning by running (from your branch): code:
Now, there's still a possibility that you're going to have merge errors (you almost certainly will at some point, at the end of the day no SCM is going to get around 2 people editing the same line of code). To see what's going on when you get a merge error, run git status. The list at the very bottom is the list of files you need to resolve. Once you've opened those, and resolved the conflict, just git add them and commit when all of your files are merged successfully.
|
# ? Feb 2, 2012 13:40 |
|
What that error message is saying is that git pull is ambiguous. It doesn't have any branch called new_branch_name in the remote origin, so it doesn't know what to merge in. Running git pull origin master should fix it. Of course, if you want to rebase instead of merging you can use git pull --rebase origin master.
|
# ? Feb 2, 2012 13:53 |
|
Has anyone managed to get a git server running on a Windows machine, and can you share the magic so I can give it a shot? My unix server/nas died a while ago and I haven't been able to replace it yet, so I've been trying to set up a local server on my windows machine to use in the mean time. I've found a variety of sources and recommended servers but haven't had luck getting it going yet. gitosis and gitolite both rely on being able to add a user to use as the filesystem, which either doesn't work in cygwin or would require me to create a dummy windows user account, which I would then not be able to su as anyway because su doesn't work. I found a stack overflow Q&A that suggested a server could be set up using msysgit and some SSH server/client program that I can't recall the name of, but that program has now become commercial software. At this point it looks like my best option is to set up an IIS daemon and install Bonobo.
|
# ? Feb 2, 2012 14:03 |
|
enki42 posted:
I ended up running 16 git cherry-picks anyway but it seems ok for now. I still need to make some minor fixes. Hopefully regular updating will help prevent this from happening again in future. Are there any other good GIT habits to have? Does 'commit early, commit often' still apply?
|
# ? Feb 2, 2012 14:34 |
|
Ephphatha posted:gitosis and gitolite both rely on being able to add a user to use as the filesystem, which either doesn't work in cygwin or would require me to create a dummy windows user account, which I would then not be able to su as anyway because su doesn't work. You could go with a small linode or a tiny rackspace vm.
|
# ? Feb 2, 2012 15:04 |
|
Or if it needs to be local then run a VM, ubuntu works pretty good on Hyper-V if you are using that, everything runs good on VirtualBox. Or just say gently caress that local bullshit and use ed: github != bitbucket wwb fucked around with this message at 22:44 on Feb 2, 2012 |
# ? Feb 2, 2012 15:40 |
|
Ephphatha posted:Has anyone managed to get a git server running on a Windows machine, and can you share the magic so I can give it a shot?
|
# ? Feb 2, 2012 16:02 |
|
Ephphatha posted:Has anyone managed to get a git server running on a Windows machine, and can you share the magic so I can give it a shot? It's likely that neither of these is the best option, but you could: - install cygwin (or msys?) opensshd and just access git over ssh; this doesn't offer the fine-grained control that gitolite does, but if it's a private repo it should tide you over - install a lightweight linux distro in a VM and run gitolite on that
|
# ? Feb 2, 2012 16:20 |
|
wwb posted:Or just ... use github, ... it is alot cheaper than github... I think you missed something here. I completely forgot about the VM possibility. I do want to expose this to the net so I can access the repositories from my laptop when I'm not at home, but that's easy enough once I've got the VM set up.
|
# ? Feb 2, 2012 16:21 |
|
Ephphatha posted:I think you missed something here. I chose bitbucket over github for the free private repos.
|
# ? Feb 2, 2012 22:39 |
|
Yea, I meant to say bitbucket. Fixed.
|
# ? Feb 2, 2012 22:45 |
|
Ephphatha posted:Has anyone managed to get a git server running on a Windows machine, and can you share the magic so I can give it a shot? Ghetto: CIFS export the git repo Works for me. (To sync notebook and PC) I also use Virtualbox shared folders to sync between w7 host and ubuntu guest.
|
# ? Feb 3, 2012 01:09 |
|
enki42 posted:I would personally start off each morning by running (from your branch): code:
|
# ? Feb 3, 2012 08:36 |
|
I botched my git config info on one computer, so my git commits were perceived by GitHub as made by another user (an old one I used to have). As a result, I have another person associated with some of my commits, which annoys me. I want to do these commits over again, but with a new name, but what's the beast way to do this? git reset --soft <hash of the last working commit> git push -f Followed by redoing the commits? I have mixed experiences with doing soft resets where the original changes weren't staged, so I want to make sure I get it right.
|
# ? Feb 6, 2012 12:14 |
|
ufarn posted:Followed by redoing the commits?
|
# ? Feb 6, 2012 12:27 |
|
Mithaldu posted:Make a new branch at the last good commit, then for each of the commits: Cherry-pick and commit --amend with a slightly different commit message. (An added space or such would be fine.) Or just use git commit -C=HEAD --amend --reset-author. I believe there's a way to use git filter-branch but I'm not sure.
|
# ? Feb 6, 2012 12:46 |
|
Suspicious Dish posted:Or just use git commit -C=HEAD --amend --reset-author. I believe there's a way to use git filter-branch but I'm not sure.
|
# ? Feb 6, 2012 13:18 |
|
There's no good reason to do this one commit at a time; it's a huge waste. Runcode:
|
# ? Feb 6, 2012 13:46 |
|
We use git for code and perforce for art assets. The problem with perforce is that users don't have a way to make incremental commits locally, as far as I can tell. Obviously, if an artist were savvy, they could just create a git repo for a project and commit to that as they work. There is nothing hard about that, right? I mean, there is nothing magical about version control that requires a programmer. If a user were really interested in improving their workflow then they'd bother to learn to use a tool of some kind... I'd like to get some people into the mindset that they will never lose a minute of work again with the right workflow (after I can get them to actually save their work). But what kind of tool can I recommend to an artist? It has to be something free and easy that they can simply use and commit to for small projects in arbitrary directories. I'm not trying to create a new company-wide paradigm, I just want something that any user can use individually. Dropbox etc. aren't suitable because we can't upload our assets externally.
|
# ? Feb 6, 2012 18:17 |
|
Lysidas posted:There's no good reason to do this one commit at a time; it's a huge waste. Run code:
|
# ? Feb 6, 2012 21:02 |
|
Looks good to me. Now that I think of it, you may also want to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL:code:
|
# ? Feb 6, 2012 21:41 |
|
Lysidas posted:Looks good to me. Now that I think of it, you may also want to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL:
|
# ? Feb 7, 2012 02:53 |
|
Upgraded from TortoiseHG 1.x to 2.x When there's a merge conflict, 1.x would launch kdiff3 with three columns on top (before any changes, the local changes, the remote changes) and one pane on the bottom showing the resulting file. Some lines in the bottom pane would contain <MERGE CONFLICT> which meant you had to choose code from one (or more) of the above panes. All good. Now, I'm seeing this Resolve Conflicts dialog The the files up top have unresolved merge conflicts. I select one, and click "mercurial resolve" which results in an error, as expected, because why else would the file be in the Resolve Conflicts window if mercurial could have automatically merged it. Good. (Why is that button even there?) But when I click on "tool resolve", the file is marked as resolved and just jumps to the lower listbox without launching kdiff3 as described above. How can "mercurial resolve" fail, and "tool resolve" succeed without launching the tool and me manually expressing how the merge should be resolved? epswing fucked around with this message at 23:11 on Feb 8, 2012 |
# ? Feb 8, 2012 22:47 |
|
epswing posted:Upgraded from TortoiseHG 1.x to 2.x I think it's like this: If there are conflicts (= changes from different branches in the same file) in some files, it launches the Resolve Conflicts dialog. At this point, it hasn't tried to resolve the conflicts. Then when you do tool resolve, it actually tries to resolve the conflicts itself. If they're trivial, hg can resolve them and it doesn't bother showing you a merge tool. (You can still launch one yourself with the '3-way Diff' button - which is something is ALWAYS do.) But if they're not trivial, it shows you your merge tool.
|
# ? Feb 9, 2012 12:16 |
|
Looks like something went wrong when I tried to enter the command. I was running git bash on Windows (and not running it as an administrator).code:
|
# ? Feb 9, 2012 14:11 |
|
I'm starting my first project with CVS (or Version Control in general) in a few days. It's an established project that's been going on for years. I've quickread a couple of tutorials and I think I get it, but I'm still concerned. How easy or hard is it to gently caress up? Do you have confirmations before you delete stuff or since it's geared towards developers it assumes you know what you're doing?
|
# ? Feb 9, 2012 14:35 |
|
poty posted:I'm starting my first project with CVS (or Version Control in general) in a few days. It's an established project that's been going on for years. I've quickread a couple of tutorials and I think I get it, but I'm still concerned.
|
# ? Feb 9, 2012 14:38 |
|
ufarn posted:Now what? Run gitk --all & to view the history in your repository. (I can never get any work done without having gitk open -- it's tremendously useful to see the history that you're adding to). It looks like git filter-branch succeeded in rewriting the history, but failed to clean up some of its internal state. Try removing the c:/(...)/.git-rewrite directory yourself.
|
# ? Feb 9, 2012 15:03 |
|
uXs posted:Then when you do tool resolve, it actually tries to resolve the conflicts itself. If they're trivial, hg can resolve them and it doesn't bother showing you a merge tool. Again, if they were trivial, "mercurial resolve" would have been able to resolve them. Ok, so when I click "tool resolve", and don't get a tool to manually merge the conflicts, that means it was done automatically. The 3-way diff looks like this: Is this telling me [local] changed a line to DateTime.Now, and [other] changed it to DateTime.Today, and [merged] (the middle pane) took [other]'s change and not [local]'s change? How can it assume that's what I wanted??
|
# ? Feb 9, 2012 15:23 |
|
Lysidas posted:Run gitk --all & to view the history in your repository. (I can never get any work done without having gitk open -- it's tremendously useful to see the history that you're adding to). I can remove the folder and all, but it looks like something failed or just wasn't applied. The affected files seem to have branched out somehow: Maybe that's just a result of the different e-mail associated. Then again, it appears I have made the same mistake at an earlier point where it didn't branch out.
|
# ? Feb 9, 2012 16:18 |
|
Here's a good question: what did you expect to happen when you changed your email address in those commits? Why do you think it looks like something failed or wasn't applied? (Also, there are no "files" that have branched out, those are commits.) Always keep in mind that you cannot change a commit1. As a consequence, you cannot modify the history in your repository. Your only option is to make new history with the changes you want, and then forget the old commits by removing or reassigning all references to them. You made new history with filter-branch, and git status indirectly told you that there are still references to the old commits: code:
However, I'd first redo the filter-branch with an earlier start commit -- the one before the first occurrence of the incorrect email address. You'll need to use the -f option since filter-branch is careful about keeping a backup of your old state, and it won't overwrite the previous backup by default. (This backup is the grey original/refs/heads/registration label in your gitk display.) _____________________________________ 1or any type of Git object: tags, commits, trees, blobs.
|
# ? Feb 9, 2012 19:17 |
|
Lysidas posted:Here's a good question: what did you expect to happen when you changed your email address in those commits? Why do you think it looks like something failed or wasn't applied? (Also, there are no "files" that have branched out, those are commits.) Is the `-f` option only for the push or for the re-entered command as well?
|
# ? Feb 10, 2012 00:34 |
|
ufarn posted:Thanks. Assuming things went okay, I have to re-enter the exact same command albeit with a different good_commit value? I just checked, and the value I entered the last time referred to a commit before the first wrongful commit. I can try stepping it one commit back, though. Both. git push -f means "push, and don't worry about altering (as opposed to appending to) the history in the remote repository". git filter-branch -f means "rewrite history in bulk, and don't worry about overwriting the previous backup of which commit this branch pointed to". EDIT: didn't respond to your other question. When you specify a range of commits such as A..B, you're telling Git "everything reachable from B minus everything reachable from A". This set of commits by definition doesn't include A. If you want to include A, you have to specify its parent (assuming it only has one) as part of the range -- either manually, or in the form A~..B. The ~ means 'parent', and there's a whole man page about specifying ranges of commits. Lysidas fucked around with this message at 01:03 on Feb 10, 2012 |
# ? Feb 10, 2012 00:54 |
|
|
# ? May 10, 2024 09:29 |
|
Not sure it went as planned. I had forgotten to delete .git-rewrite and grant git bash full permissions. This is what I got:code:
code:
|
# ? Feb 10, 2012 01:28 |