ninetydegrees (90d)☕ (
ninetydegrees) wrote in
dw_dev_training2012-08-28 11:00 am
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
Git: more newbie questions
1) If you're working on bug A on branch A then want to work on completely unrelated bug B on branch B, do you need to stash you changes on A checkout develop then create branch B?
Answer: yes, but see comments about using git commit and git commit --amend in your workflow.
2) When can you use git diff? Before add only? Because otherwise it gives me nothing and I have to use git status -v.
Answer: possibly with git diff --cached or git diff HEAD^ HEAD (untested)
3) Oh I feel so stupid for asking this but how do you get out of git diff or git log on PuTTY? Ctrl+C and Ctrl+X don't work.
Answer: the magic key is 'q' and this is related to PAGER and not PuTTY
4) If you're working on bug A on branch A and have reached a point where you want to do some more work but be easily able to revert to where you were before, what is the best route? Several commits? Creating a subbranch A1 (is that possible?)? Is that where merge is useful? I'm having the hardest time understanding how merge can be used concretely.
Answer: several commits is indeed the best route; the concept of 'subbranches' isn't valid.
5) In git config, is there a way to reset the value of core.editor to whatever is the default on your computer (without naming the editor)?
Answer: yes, with git config --global --unset core.editor
Answer: yes, but see comments about using git commit and git commit --amend in your workflow.
2) When can you use git diff? Before add only? Because otherwise it gives me nothing and I have to use git status -v.
Answer: possibly with git diff --cached or git diff HEAD^ HEAD (untested)
3) Oh I feel so stupid for asking this but how do you get out of git diff or git log on PuTTY? Ctrl+C and Ctrl+X don't work.
Answer: the magic key is 'q' and this is related to PAGER and not PuTTY
4) If you're working on bug A on branch A and have reached a point where you want to do some more work but be easily able to revert to where you were before, what is the best route? Several commits? Creating a subbranch A1 (is that possible?)? Is that where merge is useful? I'm having the hardest time understanding how merge can be used concretely.
Answer: several commits is indeed the best route; the concept of 'subbranches' isn't valid.
5) In git config, is there a way to reset the value of core.editor to whatever is the default on your computer (without naming the editor)?
Answer: yes, with git config --global --unset core.editor
no subject
git checkout -b bug/a
#fixing bug A
#oh, I now have to work on B
git commit
git checkout -b bug/b
#fixing bug B
git commit
git checkout bug/a
#fixing bug A (end)
git commit --amend
commit --amend should only use for local changeset, and not on already pushed somewhere else changesets to maintain consistency.
Side note: if you clutter your branch with unmerged changes, for example doing a git pull in A to rebase against master for example, you won't be able to leave A easily. git merge --abort will help.
(2) You can try stuff like git diff --cached or git diff HEAD^ HEAD
(HEAD^ is HEAD minus a version)
(3) This isn't a PuTTY-related question, but a PAGER one.
Some commands are sent to more (or less), softwares to allow to browse up and down contents.
To quit, the key to use is 'q'.
(4) I would do several commits, this produce a clean interface.
You will even be able to merge all these commits into one with git merge when you leave the branch.
By the way, subbranch isn't a valid concept: branches aren't path of codes, but more bookmarks indicating the changesets to work with.
You'll get more information on the concept of branches in the following document:
http://eagain.net/articles/git-for-computer-scientists/
(5) I think in this case the default value would be your EDITOR environment variable (echo $EDITOR).
So your question become "how to remove core.editor setting from git config?".
I'm not sure for this one, but I would try git config --unset core.editor.
no subject
Back to English:
Re: git config --unset core.editor
I'd tried that actually but it didn't work.
git config
A scope (--global/--system/--local) should probably be added.
To get all the settings:
* git config --global -l
(will read ~/.gitconfig)
* git config --system -l
(system-wide /etc file, if it exists ; in FreeBSD this is /usr/local/etc/gitconfig)
* git config --local -l
(settings for the current repository)
The following test worked fine, with --global:
Re: git config
no subject
no subject
Half the fun for me so far has been making mistakes and trying to figure out how to fix them; sometimes it's ridiculously easier than it used to be and sometimes you have to Google things a bit (also ridiculously easy).
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Guess I'll take the plunge and move my Hack over today *g*