It would be nice to add these two:
Oh shit, someone checked-in huge file that shouldn't be in repo.
Oh shit, this folder I had been working on should have been in its own repo.
Some bad Git situations and how I got myself out of them
341–350 of 352 posts
Re: Some bad Git situations and how I got myself out of them
#342A somewhat lesser known git trick that's pretty much a strict improvement - use `--force-with-lease` for force pushing instead of `--force`. What this does is check what's on the remote branch and compare it with what you think is on the remote branch, and only do the force if they're the same thing. So if someone pushes a commit, the force push errors out instead of silently overwriting it. Basically every single ti…
I also can't think of a situation where you'd want to force push to a branch that others might be committing to.
Re: Some bad Git situations and how I got myself out of them
#343A somewhat lesser known git trick that's pretty much a strict improvement - use `--force-with-lease` for force pushing instead of `--force`. What this does is check what's on the remote branch and compare it with what you think is on the remote branch, and only do the force if they're the same thing. So if someone pushes a commit, the force push errors out instead of silently overwriting it. Basically every single ti…
I also can't think of a situation where you'd want to force push to a branch that others might be committing to.
If they're not committing to it, --force-with-lease is the same thing as --force, so it doesn't cost you anything.
Re: Some bad Git situations and how I got myself out of them
#344I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…
Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that y…
I had a look at the tool, watched the screencast and was impressed. Then I saw, at the very bottom that this is for Macs. The disappointment...
Re: Some bad Git situations and how I got myself out of them
#345Here lonely girl looking for fun with the guys http://u.to/i_g3Dw
Re: Some bad Git situations and how I got myself out of them
#346Re: Some bad Git situations and how I got myself out of them
#347Earlier quoted context omitted.
It's easier to figure out the various workflows you need (most teams need very few - work on feature, sync code, commit/push/issue PR, release) and then scripting them. I noticed that git errors on my team were almost eliminated when we started doing that - especially once I started adding sanity checks to the git workflows. It also allowed members of the team who previously struggled with git to contribute much more…
> It's easier to figure out the various workflows you need Fine, that might be cheaper than properly training your employees. Of course, if your employees aren't training themselves out of genuine interest that's really the only option. But then once something goes wrong you'll have to resort to "oh shit" websites and hope that you can the exact issue that you're having, since you really don't understand what's going…
I tended to find that a few things were likely to go wrong and simply changing the git workflow scripts to account for those things was enough.
If things went wrong, people could come to me. That often resulted in me fixing their problem and fixing the script to ensure that kind of problem didn't happen again - after which people stopped coming to me because they didn't have problems.
Basically it was like releasing software.
>I submit this must be because people came out of the course without really understanding the tool.
I submit that not everybody needs to be an expert in the tool. Non-programmers can actually help a lot with writing stuff that needs to be version controlled with code - e.g. writing test scripts, updating translations, various configurations, etc.
Re: Some bad Git situations and how I got myself out of them
#348Earlier quoted context omitted.
What are the superior foes in your opinion ? I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git. In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.
Can you justify git>subversion or are you just following the sheep? Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time. BTW: Mercurial still beats them all.
for me the biggest advantage is working in my own repository and then pushing the changes upstream. I can develop features independent of other features. If there is a bug I can fix it, merge it into the productive branch and carry on working on other features.
I know that many people don't like it, but I can fix up commits in my local repository and push the change upstream in one.
With SVN I wasn't able to do this, so it was a big pain if you had to fix a bug if you were in the middle of a big feature, or if you had an experimental feature you wanted to clean up and release a month later.
Re: Some bad Git situations and how I got myself out of them
#349Earlier quoted context omitted.
This looks like an awesome way to learn git, and many would probably love to continue with it - but many others too would prefer to move to the CLI. I used to use a GUI for git, but now I just find them cumbersome; by their nature requiring me to switch window for less.
I actually used to think similarly before I found git up -- although to me it wasn't about switching window context away from the terminal but rather switching away from the text editor. I imagined that the ideal place for featureful visualization/interaction with the repo would be in the text editor/ide. In reality though -- i really like having the separate window -- it's always there, does one thing and does it we…
That's interesting. On Linux?
I'm using mac at the moment, and the awful window management (and inability to properly change it - all wm apps just handle resizing and moving within existing spaces and margins) just makes me more motivated to do everything in full-screen tmux, to simulate a decent wm - as long as everything is CLI-based!
(I tried Arch on it for a while, but ended up deciding the firmware difficulties - in particular the battery draining quickly and CPU running hotter - weren't worth it; I traded i3 for full-screened tmux.)
Re: Some bad Git situations and how I got myself out of them
#350Earlier quoted context omitted.
This is why rebase is so, so much better than merge. And it's infinitely better for bisecting, too. Simple, completely linear history for origin/master is just so powerful in many that aspects that I'm constantly baffled why merging seems to be the flow mostly being talked about. Now someone usually comes and says that merges are superior for long running branches. Which may be true in some aspects, but when you have…
For those of us who are uneducated / haven't seen this before: how do you use rebase to merge a separate branch? Are you suggesting you just `git rebase my-branch` from master / develop? How do you coordinate this with multiple team members. Merges appear to work better when you have multiple team members with separate feature branches that may have some overlap (conflicts may occur, but those can be handled as they…
First off, see [0] for a very helpful insight into the rebase command's syntax.
With multiple team members (each on their own feature branch), I encourage what I call the "pitchfork" approach [1], where the feature branches get stacked up into an integration branch to preview what the master branch would ultimately be when all the feature branches are merged in via pull requests.
A key part of building and recreating the pitchfork structure is git rerere [2].
[0] http://matthew-brett.github.io/pydagogue/rebase_without_tear...
[1] https://gist.github.com/dkaminski/c8e59221bea74ab1fea615a468...