On Sat, 22 Apr 2017, Michael Felt wrote:

>> Oops, that's a mistake. I believe I just fixed and pushed a fix for this
>> after this email. Normal builds or make dist should not need roffit
>> (anymore).

> Thanks, so I should do "rebase" of my master,

A rebase means that you move one or more of your local changes to another
"merge point" in history. If you don't have any local commits, you don't need
to rebase (and really, you can't since a rebase implies local changes) but you
just need to get the latest commits from remote.

Then you can just 'git pull' in your cloned tree.

> and then copy that (which is where I would make a local branch).

Okay, I realize I'm throwing a lot of git language and commands at you here
now but you'll find that it is more convenient to do these things once you
learn the basic ways git enables you to do this. But I'm also fully aware that
git can have a pretty steep learning curve.

There's usually no need to copy anything. In a typical work flow case where
you want to change/try out stuff, you create a local branch with git:

  git branch my-cool-features

then checkout that branch and work in that:

  git checkout my-cool-features

and commit things as you go in that branch. Once you're ready to share that
work with the world you can push it to your forked git repo or if the branch
is done, you just remove it again with 'git branch -D my-cool-features'.
Everyone working a lot with git ends up with a whole series of local branches
in various stages of maturity... =)

Now, if you instead want to just checkout a remote branch, such as one that
we're working on right now, you can click the "view command line instructions"
link in a pull request to see how to get that into your local tree. For
example PR #1438 is in a remote branch already so you can just:

  git checkout -b bagder/build-curl.1-oot origin/bagder/build-curl.1-oot

to checkout my branch I made for that PR!

To go back to your clean master, you just switch over to that again: 'git
checkout master'

> One of my concerns (read worries) is being in sync when reporting a bug.
> When the target is constantly moving - hard to be sure if it will still
> appear (the same way).

Ack. You can always do 'git describe' in your (master) branch to see which
commit you're at. Do 'git status' to see the status of your local tree (and if
in master it should say that you have no local unpushed commits). Then you can
always do 'git pull' to sync your master tree from remote.

If in doubt, compare your 'git log' (which shows all commits in a linear
fashion) with what https://github.com/curl/curl/commits/master shows.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html