On Sunday, 6 January 2013 at 22:45:27 UTC, Andrei Alexandrescu
wrote:
I do now after having read about it at the end of several
google searches.
I found the git documentation to be an excellent resource once
you're familiar with the basic concept of how git works. For
that, I found this quite insightful:
http://eagain.net/articles/git-for-computer-scientists/
I agree it is important to be fluent with git. I'm an okay user
but currently unfit for an admin. Probably Walter is at a
similar stage. I'm doing my best to improve my knowledge in the
limited time I have, and part of it is discussing git here. So
I hope you'll understand why I find it contradictory to be
reprimanded for doing so with the reproach that I should be
doing exactly what I'm doing.
Sorry, your post came across to me as you advocating that
everyone used a git command without having understood its exact
function.
Yes, that was exactly my intention.
But, why? If both histories contained conflicting changes, Git
will throw only some away. In some cases, this might result in a
broken codebase (the result might even compile, but git might've
thrown away some initialization code (only), and you may not find
out until it's too late).
I get these tidbits of commands - git idioms - all the time,
and I forget them because I don't use them frequently. I don't
see why it's a crime to want to define some macros for such
idioms instead of essentially putting that in a text file that
I'd be perusing now and then.
I just don't think it's that simple. The outcome of any command
can be affected by a number of factors, such as:
- Do you have any unstaged changes? Do you want to keep or
discard them?
- Do you have any staged but uncommitted changes? (ditto)
- Are there any untracked files that may conflict with the
operation? (ditto)
- Are there any local-only commits? (ditto)
- Which branch are you on?
- Does the branch track a remote-tracking branch? Is it tracking
the intended one?
- How is the behavior of the commands set up in the user's
.gitconfig?
So, the question is not as much "How do I get X done?", as it is
"How do I get to X from Y?"
For example, the commands I posted will only work correctly if
the current checked-out branch (i.e., HEAD) is "master",
otherwise it'll move some other branch to match the remote's
master. A hard reset throws away local changes - someone running
such a macro found in a repository's .gitconfig may result in
accidental loss of work.
FWIW, I work with git daily, and haven't found the need to set up
macros such as you describe. I use a "gg" alias to launch git gui
for interactive staging and reviewing, and the "git pullrequest"
script I posted here earlier.
That's pretty much what I wanted but was unable to find easily
by searching the net.
You could always ask on IRC ;)
