I'm replying to this one message specifically because you will need to redo some of the work you did on one of the previous commits.. On Sat, Dec 28, 2013 at 4:06 AM, Daniel James wrote:

On 28 December 2013 03:36, Rene Rivera wrote:

...

And now that I did a commit to attempt to steamroll over the upstream changes.. And to let the pull do a merge.. The merge fails. How the hell

do

...

I fix this? And how is it that I have yet to come across anything in git that is a *single* command :-(

You can checkout a file from any commit using 'git checkout ref -- path', in this case I think you need:

git checkout HEAD -- tools/regression/src/regression.py

I didn't get a chance to try that.. Instead I did a reset (I tried 3 different ways with Egit). It was a hard reset.. Then followed by reverting the commit that was causing me problems.. Unfortunately this removed all the changes in the commit. Instead of the one file I wanted to revert. I have no idea how to revert *just* *one* *file*. I then found out when trying to do the merge that git had decided to irreparably delete changes I had made that somehow my local commit had not saved. I only saved myself as I had older copies of the deleted files. I'm close to totally giving up on this whole thing as I'm running out of free time.. As in I'm seriously considering giving up on managing Boost testing.. This is not worth the amount of stress involved in using git.. Especially as my daughter screams at me for attention. Bye. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On 12/28/2013 06:21 PM, Jonathan Wakely wrote:

On 28 December 2013 21:10, Rene Rivera wrote:

...

I didn't get a chance to try that.. Instead I did a reset (I tried 3 different ways with Egit). It was a hard reset.. Then followed by reverting the commit that was causing me problems.. Unfortunately this removed all the changes in the commit. Instead of the one file I wanted to revert.

That's because a Git commit tracks the state of the entire repository, not of individual files.

...

I have no idea how to revert *just* *one* *file*.

You can make a single file in your workspace contain the contents of a specific revision with "checkout"

git checkout <commit> -- <file>

e.g. to change the file 'foobar' to its previously committed state:

git checkout HEAD^ -- foobar

(HEAD is the current revision, HEAD^ is the previous one).

That alters the file in your workspace, it doesn't alter the index or committed tree, so "git status" will show the file as having uncommitted changes.

...

I then found out when trying to do the merge that git had decided to irreparably delete changes

Git didn't decide to do that - it was probably you by doing a hard reset. That's a sharp tool that should be used carefully.

...

I had made that somehow my local commit had not saved.

If your commit didn't save it then that's because you didn't commit the changes.

...

I only saved myself as I had older copies of the deleted files.

Anything which has been committed at some point can be retrieved (at least until it gets garbage collected a few weeks later).

"git reflog" will allow you to find the commit IDs of "lost" commits, and generally show you what you've done recently to alter the state of your repo.

But changes that were never committed can be easily lost, via careless use of "reset" or other commands that explicitly throw away uncommitted changes.

I am interested in this. Other than the hard reset, which tells git to overwrite the working directory and index, I did not think that git would ever throw away uncomitted changes, whether they are in the working directory or the index. Would you please be specific about any situations where git will overwrite the working directory/index without the user being aware ?

On 29/12/2013 08:16, Cox, Michael wrote:

On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener wrote:

...

I am interested in this. Other than the hard reset, which tells git to overwrite the working directory and index, I did not think that git would ever throw away uncomitted changes, whether they are in the working directory or the index. Would you please be specific about any situations where git will overwrite the working directory/index without the user being aware ? Just about any git command with a (-f | --force) option, e.g.

git checkout -f HEAD git submodule update -f etc.

Anytime you use a -f option you're telling git, "I know what I'm doing", whether that's true or not. The only one that goes against this is: git checkout my_modified_file which doesn't require a "-f", and overwrites your local modified file (without warning) with the version that is in the repository.

Ok, so that was only a single file lost... but: git checkout . does that to the whole directory, and, of course, is completely different to: git checkout which doesn't do anything harmful. Phil

On 12/30/2013 08:23 AM, Beman Dawes wrote:

On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards

...

On 29/12/2013 08:16, Cox, Michael wrote:

The only one that goes against this is: git checkout my_modified_file which doesn't require a "-f", and overwrites your local modified file (without warning) with the version that is in the repository.

Ok, so that was only a single file lost... but: git checkout . does that to the whole directory, and, of course, is completely different to: git checkout which doesn't do anything harmful.

That's truly horrible!

I tried "git checkout my_modified_file" myself to make sure I understood you correctly, it wiped out the changes without the slightest hint or warning that anything was amiss.

https://svn.boost.org/trac/boost/wiki/GitCautions has been updated accordingly.

Does anyone know the rationale for not requiring -f or --force? Or could this be a bug in the git checkout implementation?

I'd bet a large finite amount it's not a bug. The rationale would be that you told git to check out a specific file or directory, so git assumes you meant it. FWIW, I have: [alias] stat = status --short --branch --untracked-files=normal in my ${HOME}/.gitconfig, and my fingers are in the habit of typing "git stat" at the command prompt whenever my brain hasn't fully processed the results of whatever I last did. (I find "git status" too noisy.) This usually leaves a blatant "you have modified/untracked files on this branch!" signal still on the screen which my brain mostly notices before I finish typing "git checkout ." (or, more frequently, "git reset --hard" or "git clean -fd ." which are destructive of all modified and untracked files, respectively). That, and frequent use of "git add -u" to store unready but valuable changes in the index, makes data loss rare and usually recoverable. Peter

On Fri, Dec 27, 2013 at 10:36 PM, Rene Rivera wrote:

On Fri, Dec 27, 2013 at 9:02 PM, Rene Rivera wrote:

...

When I attempt to do an update of the boost superproject I get and error:

Froggy:develop grafik$ git pull error: Your local changes to the following files would be overwritten by merge: tools/regression/src/regression.py Please, commit your changes or stash them before you can merge. Aborting Froggy:develop grafik$

I know I've made changes. I also know I don't want to throw away my changes. I also know that I don't want to merge the upstream changes to that one file. Hence.. How do I do a pull and have git ignore the upstream of only that file? (i.e. throw away the upstream changes because I know that my changes supersede them)

And now that I did a commit to attempt to steamroll over the upstream changes.. And to let the pull do a merge.. The merge fails. How the hell do I fix this? And how is it that I have yet to come across anything in git that is a *single* command :-(

I used to run into those sorts of problems when I first started using git, but as I gradually learn to use the strengths of git they happen less and less often. Some suggestions: * It took me awhile to realize that any changes much above the typo level happen best on a branch created for the purpose. That branch may well be private, too. Working of a branch of develop, not develop itself, and that's particularly true for the super-project or other multi-developer projects. * Consider stashing, as stashing may well have been the next best option after branching. Stashing is an easy way to move work out of the way. A branch can be created and the stashed changes applied to it, leaving develop ready for a pull. Or the stash just restored after the pull, if for some reason a branch isn't desired. * Consider using the merge strategy option, as specifying "-s ours" might have been the next best option after stashing. * It took me awhile to realize that many two and three command sequences I was executing could be done in one command with one or two command line options. It is a bit easier using one of the graphic git clients because the options are presented on the dialog box so I don't have to remember them. For getting started, using several individual commands allows the results to be checked step-by-step. HTH, --Beman