git mavens, shortcut please?

 

 

Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works and need something in style of ‘see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m’boots!' and so on.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
...now touch these wires to your tongue!

 
On Sun, Jun 19, 2016 at 7:58 AM, Eliot Miranda <[hidden email]> wrote:
git stage -u     (i.e. git stage --update)

> What's the one-liner to add and commit the modified files and ignore the untracked files?

git commit -a

>
> [hate the word "add" being used to mean "stage".  This thing was written by a sadist].
> _,,,^..^,,,_
> best, Eliot
>

 
On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote:
There's a *lot* of content out there for migrating from svn (and other
systems) to git.  This looks like a good 'I know how to do it in svn,
now how do I do it in git?' basics page: http://git.or.cz/course/svn.ht
ml and here's a version that might look nicer in hard copy form: https:
//www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/

I think Ben meant to post `git add -u` (there is no "stage" command,
but you can create aliases).

Long post follows, tl;dr/toc: a book recommendation; do not rely on
svn-to-git tables forever; a possible explanation for why add is
called add; a use case for staging (for those who might see it as an
unnecessary complication); remember the "stash" command; you might
like "bisect" for bug-hunting.

What documentation have you already read except for the manpages? I
liked the book mentioned on the git Homepage:
https://git-scm.com/book/en/v2
But I don't remember how good I knew git already when I read parts of
it. I found the Git Internals chapter to be particularly enlightening,
but I understand if you do not wish to deal with the internals just to
get going with it. :-)

Although SVN to Git migration guides and "translation" tables might be
what you look for in the beginning, you should definitely adjust to
Git's vocabulary for a happier life (at least happier on condition
that you work with Git).

Regarding the "add" for "stage": imagine that you do not track files
with git, but content (that's also how its database is built like). So
you "add" changes to Git's knowledge of your content.

The really nice part about the staging, by the way, is that it allows
you to commit only part of your changes, for smaller and more focused
commits even after you "went into the flow", fixed a hundred bugs, and
added ten features along the way, including that nifty utility
function that everyone ought to have on their branches (and want to
cherry-pick)... You can even can add individual lines from changed
files instead of the whole file (git add -p/--patch). I use it all the
time in my (non-Smalltalk) projects, but SVN cannot do that. I figure
it does not help so much with Smalltalk code, but could be handy for
all that C.

Also, if you ever happen to be working on something you do not want to
commit yet (even though you commit locally), but you have to switch
branches or merge something anyway (which svn update forces on you all
the time), you should remember the "git stash" command. It basically
puts aside local changes to tracked files for later retrieval. I would
say this is a must-know because Git won't in general let you perform
destructive operations on files with uncommitted changes (merge and
checkout are probably the most common ones), so you don't accidentally
lose any changes. Git is really quite good at not letting you lose
something, but it takes time to get used to it and appreciate that it
only wants to help. And you still have to know the commands to get
stuff back after you made a wrong decision. ;-) But remember that you
won't get something back you have never "added" to Git.

For the bug spotting part in tim's story, you might find the bisect
command interesting, when you have some time to read up about it. If
you are really proficient with that, you can make it automatically
search the history for a commit that introduced a bug you just
discovered. But I guess we would need some tooling to exploit that to
its fullest.

Well, I think that's enough text for today, sorry. ;-)

2016-06-19 7:37 GMT+02:00 Phil (list) <[hidden email]>:

 
On Sun, Jun 19, 2016 at 10:53 PM, Jakob Reschke
<[hidden email]> wrote:
>
> I think Ben meant to post `git add -u` (there is no "stage" command,
> but you can create aliases).

oh but there is ;)
see `man git-stage` ?
I was surprised to find it.
btw, git version 2.1.4

cheers -ben

 
2016-06-19 16:57 GMT+02:00 Ben Coman <[hidden email]>:
Oops, you're right! I had never seen that. Although it already exists
since 1.6.1... I stand corrected -- suspected a typo before.

git commit -a

will add all the modified files and open an editor where you can write the commit message. Once the editor exits it git will complete the commit.


git commit -am"Here is my commit message"


will add all modified files to the commit, make the commit message 'Here is my commit message' and then commit.


To configure a specific editor (e.g. emacs, vim,  textmate) that can be used when writing lengthier commit messages by one time per computer running

git config --global core.editor "emacsclient"

Eliot Miranda-2 wrote

Hi All,

    I find myself in this situation a lot:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   platforms/Cross/plugins/IA32ABI/ia32abi.h
        modified:   platforms/Cross/plugins/IA32ABI/x64ia32abicc.c
        modified:   platforms/Cross/plugins/IA32ABI/xabicc.c

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp

What's the one liner to add the modified files and ignore the untracked
files?
What's the one-liner to add and commit the modified files and ignore the
untracked files?

[hate the word "add" being used to mean "stage".  This thing was written by
a sadist].
_,,,^..^,,,_
best, Eliot

On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <[hidden email]> wrote:
>
> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works

I found these Atlassian tutorials really nice (and often refer to them)...
* https://www.atlassian.com/git/tutorials

Github Help "Fork a repo"  provides a scratch repo for you to practice
on without fear.
* https://help.github.com/

git - the simple guide (I only just bumped into this, looks good)
* http://rogerdudler.github.io/git-guide/

> and need something in style of ‘see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m’boots!' and so on.

Okay Spot.  Here is a proposed recipe. This is for those having having
write access to the official repository and cloned that to work in.
I'll follow up with an adaption for forked repos tomorrow.

1. Go to https://github.com/OpenSmalltalk/vm

2.  Click the green <Clone or download> button.
     (If you've already set up your SSH keys, click "Use SSH".)
     then copy the url to the clipboard.

3. Clone to your local machine
    $ git clone #paste url from the clipboard here
    $ cd vm
    $ git remove -v
origin [hidden email]:OpenSmalltalk/vm.git (fetch)
origin [hidden email]:OpenSmalltalk/vm.git (push)
or...
origin https://github.com/OpenSmalltalk/vm.git (fetch)
origin https://github.com/OpenSmalltalk/vm.git (push)
...depending on ssh or https clone respectively

4. Create a branch to work on...
    $ git fetch    #updates all branches to latest
    $ git checkout -b SomeBug Cog

5. Edit, compile, test cycle.  Commit often along the way.
    * make required changes
    $ git stage -u
    $ git diff ; git diff HEAD
    $ git commit -m "SomeBug - part way there"
Repeat as necessary

6. Ready to submit.  Clean up *local* history (since we committed quite often)
    $ git rebase -i    # Squash inconsequential commits. Rebase is
okay before publishing.
    Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/
            https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview

7. Catch up to official Cog branch
    $ git fetch     # updates origin/*
    $ git log HEAD..origin/Cog    # review other updates
    $ git diff origin/Cog   # review other updates
Depending on whether the final history should be linear (more like SVN??)
    $ git rebase origin/Cog   # rebase okay since not yet published
or show the branching...
   $ get merge origin/Cog
...might depend on whether its a small fix or a larger feature added.

8. Submit for review
    $ git push    # to server
You will see...
           fatal: The current branch SomeBug has no upstream branch.
which is because the SomeBug branch only exists locally, not on the
github server. The following creates the branch on the "origin" server
and sets things so subsequently this branch only requires "git push".
    $ git push --set-upstream origin SomeBug
    * On github, from the <Branch> pulldown button, select your SomeBug branch.
    * Click <New pull request> button.  For more detail refer...
       https://help.github.com/articles/using-pull-requests/

(In the meantime, work on some other branch)

7. Reviewers can download PR to test locally as described here...
https://help.github.com/articles/checking-out-pull-requests-locally/
(though I've not done that since I've not been on the receiving side
of a pull request before)

8. Respond to reviewer comments. Edit, compile, test, resubmit.
    $ git checkout SomeBug
    * make required changes
    $ git stage -u
    $ git commit -m "changed per feedback "
    $ git push    # Pull request auto updated
(Repeat as required)

9. Pull request acceptable.  Optionally (and some policy discussion
required) squash changes from review period.
   $ git rebase -i
   $ git push -f
Note this does rewrite the history of the published SomeBug branch,
but presumably the branch is thrown away after integration so no real
foul.  But forcing pushing may be risk for accidentally doing it to
the Cog or master branches.  (btw, has the force protection on those
two branches been tested?)

10. On github, integrator accepts pull request.

11. Delete branch.

Whoops, correction down below...

On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman <[hidden email]> wrote: !>     $ git remove -v

sorry, this should have been $ git remote -v

 
Update for people working from a forked repository...
(btw a tip, try using tab completion for repo names:)

On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman <[hidden email]> wrote:
> On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <[hidden email]> wrote:
>>
>> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works

> 1. Go to https://github.com/OpenSmalltalk/vm

1b. Click the <Fork>  button in the top right.
       You'll then be looking at  https://github.com/YOURNAME/vm


3b. Additionally, set up quick reference to the upstream repository
    $ git remote add OpenSmalltalk https://github.com/OpenSmalltalk/vm
    $ git remote -v
OpenSmalltalk https://github.com/OpenSmalltalk/vm (fetch)
OpenSmalltalk https://github.com/OpenSmalltalk/vm (push)
origin [hidden email]:bencoman/vm.git (fetch)
origin [hidden email]:bencoman/vm.git (push)


> 4. Create a branch to work on...
>     $ git fetch    #updates all branches to latest
>     $ git checkout -b SomeBug Cog

4. Instead, now do...
    $ git fetch OpenSmalltalk
    $ git checkout -b ABug OpenSmalltalk/Cog
Good to create server repo straight away to avoid later "no upstream
branch" error
    $ git push -u origin
    $ git branch --all   # oldTrunk & plugin branches not shown for clarity
* ABug
  Cog
  master
  remotes/OpenSmalltalk/Cog
  remotes/OpenSmalltalk/master
  remotes/origin/ABug
  remotes/origin/Cog
  remotes/origin/HEAD -> origin/Cog
  remotes/origin/master


7. Instead now do...
    $ git fetch OpenSmalltalk
    $ dit diff OpenSmalltalk/Cog
    $ git rebase OpenSmalltalk/Cog
or...
    $ git merge OpenSmalltalk/Cog


cheers -ben

 

Hi Tim--

> Actually, calling all git mavens - please, please, point the rest of
> us to some documentation that might possibly be understood by humans.

     Definitely read the fine documentation others have mentioned, but
also try one of the decent visual interfaces for git, such as SourceTree[1].


-C

[1] https://www.sourcetreeapp.com

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)