There is a mac app that is relevant to this article: http://mac.github.com/
Git Is Simpler Than You Think
111–120 of 122 posts
Re: Git Is Simpler Than You Think
#112I wonder what would happen if we'd take the git object model, totally as-is, and redesign a coherent set of commands to manipulate them. With simple and consistent switches, good command names (if at all possible), closely related to the concepts in the object model.
Would that be very different from what git is now? My underbelly says yes, but really I'm not knowledgeable enough to tell. Any ideas?
Re: Git Is Simpler Than You Think
#113If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
You're kindly assuming people never enter the wrong command by accident.
Undoing a commit, for example, is very common and necessary, especially for beginners.
Re: Git Is Simpler Than You Think
#114If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
You're kindly assuming people never enter the wrong command by accident. Undoing a commit, for example, is very common and necessary, especially for beginners.
The easiest way to undo a commit is to treat git just like you would Subversion or Mercurial: Use 'git revert $COMMIT_ID' to reverse the generated commit, or simply fix things by hand and commit again.
Sure, you can edit the broken commit, if you value a pretty commit history. But again, this requires understanding git well enough to predict the effects. What happens if you run 'git commit --amend -a' after pushing the original commit? What if another user already pulled? How will you fix the resulting mess?
If you can answer these questions, then you'll have no problems editing history. If you can't, then you may be signing up for a lot of pain.
Re: Git Is Simpler Than You Think
#115Earlier quoted context omitted.
I found git to make a lot more sense personally after reading http://eagain.net/articles/git-for-computer-scientists/ . The git parable is also very good.
So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type: git merge master git branch master from the tip of my experimental branch, and master will be moved up to the tip of the tree?
I'm still just getting the hang of git, but I've found this best practices[1] tutorial the most handy to just get started. I needed to play around at this basic level before any of these other more complicated comments started to make sense. Check it out, it's very short.
[1] http://ariejan.net/2009/06/08/best-practice-the-git-developm...
Re: Git Is Simpler Than You Think
#116Earlier quoted context omitted.
Yes I'm with you with this wccrawford. Git is not simple. Git internals may be simple hacks for hackers but git usage is another story. It does have neither understandable nor compatible terminology. Because it's simple bash scripts but distributed and decentralised it has a steep learning curve. No, no git is not simple. It's really complicated.
Git is mostly not bash scripts anymore: [~] 0 (jon@snowball2) $ file /usr/lib/git-core/git-status /usr/lib/git-core/git-status: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped
Thank you. I was misdirected by the article. And I have not peeked at the git source ever.
Re: Git Is Simpler Than You Think
#117Earlier quoted context omitted.
Not at all. Where did you come up with that? That would merge in any commits in master not already in experimental and the next command would fail because a branch 'master' already exists. To do what you are describing you would do this (or something similar: git checkout master; git merge experimental
Thanks, obviously I'm missing some concept somewhere.
The checkout command moves you off the experimental branch and back onto the master branch.
The merge command then takes the commits in experimental that aren't in master and puts them into master.
Re: Git Is Simpler Than You Think
#118Earlier quoted context omitted.
If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".
It only "messes up revision history" if you do your development on your remote tracking branch that multiple people are pushing to. If you keep your remote tracking branch clean (e.g. master), you can pull into master whenever you want, merge your changes from a local branch, and push it right back out. Done this way, you never have to use pull --rebase (which will rewrite local history). This workflow actually works…
My workflow is like this:
- Create a feature branch off of development. - Commit lots of times until that's ready. - Switch back to development. Do "git merge --squash featurebranch" This introduces all the changes from the feature branch as uncommitted changes. View the diff to ensure it's exactly what I wanted, and commit them with a single, coherent commit message.
Re: Git Is Simpler Than You Think
#119Earlier quoted context omitted.
Thanks, obviously I'm missing some concept somewhere.
The checkout command moves you off the experimental branch and back onto the master branch. The merge command then takes the commits in experimental that aren't in master and puts them into master.
Thanks, I think I may have been misusing
git branch [some name]
Re: Git Is Simpler Than You Think
#120Earlier quoted context omitted.
Totally agree. We switched from SVN to Mercurial around 6 months ago and I have to say I am annoyed that I have to spend so much time messing around with the tool rather than coding.
You can say the same with almost any non-trivial development tool. Vim, emacs, Eclipse, VisualStudio, etc all require time spent "messing around with the tool rather than coding. Another fallacy is that "writing code" is the only "useful" thing one can do. Creating clean logical history and good commit messages (or other documentation) does not invole writing code, but that doesn't mean it is not important.
Where did I say that that coding is the only useful thing?
The point I was trying to make is that tools are productivity aids and if a tool gets in the way and distracts you from your main activity (or activities) too much it can be counter productive.
I use both Eclipse and VisualStudio and find those tremendous! A good tool hides unnecessary stuff from you and works in a clear predictable way. A tool is bad for me when it does the opposite.