{"thread":{"id":"45909","subject":"[noob] is this normal behavior","startedAt":"2017-05-09T13:03:26Z","lastAt":"2017-05-10T17:27:25Z","messageCount":3,"participants":["Harry Putnam","Igor Djordjevic"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"319196","messageId":"868tm6w5bz.fsf@local.lan","threadId":"45909","inReplyTo":null,"subject":"[noob] is this normal behavior","fromName":"Harry Putnam","fromEmail":"reader@newsguy.com","sentAt":"2017-05-09T13:02:56Z","receivedAt":"2017-05-09T13:03:26Z","isPatch":false,"sender":{"key":"reader@newsguy.com","avatar":null},"body":"Setup: Running openindiana (hipster) a solaris 11 open source branch\n       git 2.12.2\n       \nI've recently moved from mercurial to git mainly because git appears\nto receive the most development and the heaviest use.\n\nI'm using git with hold over behavior developed from my time using cvs\nlong ago.\n\nI keep a hierarchy of directories and files that mirrors the structure\non the OS where git is installed [just where ever tracked files are\nlocated on OS] not the entire structure.\n\nI keep a git repo on the same OS that is created by rsyncing  the\nBUFFERED hierarchy into a git repo\n\nMany of the BUFFERED files are symlinked to there places in the OS\n\nSome are not because certain files being symlinked seemed to cause\npermissions type problems on the OS.  In those cases they are\nperiodically copied to the BUFFER hierarchy \n\nSo, not to get too tangled up in explaining my setup... tracked files\nchange in the buffer area or new files are created there.\n\nPeriodically I rsync the files in BUFFER over the files in git repo\n\nAnd record the changes thru normal git operations\n\ngit status\ngit add (when needed)\ngit commit\n\n,----\n| Aside:\n| While I would welcome comments or suggestions about using a setup like\n| this, that is not the subject of this post.\n`----\n\nThis is my most recent attempt at learning and using git but I have\ndone a few tries before.\n\nI'm noticing behavior I do not recall seeing in earlier attempts.\n\nrsyncing the buffer over the git repo is now producing a result where\n`git status' shows any changed or added files as modified or new but\nall need to be added before a commit can take place, not just the new\nones.\n\nShouldn't files that changed but are already being tracked just show\nup as modified and not need adding?\n\nThat is, if I have the file ~/.bashrc, which is really a symlink to\nBUFFER/OS/export/home/reader/.bashrc\n\n  And is tracked in git repo as REPO/OS/export/home/reader/.bashrc\n\nWhen;\n  BUFFER/OS/export/home/reader/.bashrc\n\nis edited.\n\nThen  rsynced like below:\n  BUFFER <root of rsync is here> /OS/export/home/reader/.bashrc\nover\n  GITREPO <root of rsync> /OS/export/home/reader.bashrc\n\nThereby changing the repo file in place\n\nSince that file is already being tracked; shouldn't `git status' show\nthat file as modified but ready to be committed instead of a file that\nis modified but needs to be added before a commit can happen?\n\nAnother side of this is that a `git diff FILE' only works before an\n`git add .' operation is done.\n\nThat is, if I run `git diff FILE' AFTER `git add' .. no diff is\nreported, even though it is not committed yet.\n\nSo, for example: if I'm committing and in the vi buffer of the commit\nand want to see a diff of FILE to aid my log notes.\n\n git diff FILE will report nothing whatever.\n\nIs that expected behavior?\n\n"},{"id":"319224","messageId":"03ef09e8-62a1-b6bb-041a-bad83dc353f4@gmail.com","threadId":"45909","inReplyTo":"868tm6w5bz.fsf@local.lan","subject":"Re: [noob] is this normal behavior","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-05-09T20:25:27Z","receivedAt":"2017-05-09T20:25:42Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Hi Harry,\n\nBoth behaviours you report are normal, specifically:\n\nOn 09/05/2017 15:02, Harry Putnam wrote:\n> Shouldn't files that changed but are already being tracked just show\n> up as modified and not need adding?\n> ...\n> Since that file is already being tracked; shouldn't `git status' show\n> that file as modified but ready to be committed instead of a file that\n> is modified but needs to be added before a commit can happen?\n\nNo, it shouldn`t - even though the file you`ve modified is already \nbeing tracked, it doesn`t have to mean you want the modification \ninside your very next commit, and Git doesn`t force that upon you.\n\nThat is where index (or \"staging area\") comes in handy, allowing you \nto `git add` only the changes you actually want to commit now, \nleaving the others for later decision.\n\nYou don`t even have to add all the modifications inside the single \nfile at once, for example by using `git add --patch`[1] you can \nselect just some of the them, fine tuning what gets committed and when.\n\nWith some precaution/steps needed not to commit broken project states \nby accident, and some discipline not to overdo it, this allows you to \nfully focus on the actual work you do, making logically unrelated \nchanges in place as you see fit, on the go, and only later organizing \nthem into logically grouped commits, through diligent use of `git add`.\n\n> Another side of this is that a `git diff FILE' only works before an\n> `git add .' operation is done.\n> \n> That is, if I run `git diff FILE' AFTER `git add' .. no diff is\n> reported, even though it is not committed yet.\n> \n> So, for example: if I'm committing and in the vi buffer of the commit\n> and want to see a diff of FILE to aid my log notes.\n> \n>  git diff FILE will report nothing whatever.\n> \n> Is that expected behavior?\n\nYes, that is as expected - in the form you`ve given, `git diff` shows \nthe differences between your working tree and index (staging area), \nso only changes you haven`t added yet. Once you `git add` the changes \nfrom the working to the index, there are no more differences to show, \nso no diff is produced.\n\nIf you want to see the added changes, what will be included in the \ncommit if you make it, you can use `git diff --cached`, as per \ngit-diff[2] documentation (--staged can also be used instead, being a synonym \nfor --cached, but maybe easier to remember, relating it to \"staging \narea\").\n\nThat option shows differences between the staging area (index) and \nthe specific commit - with none provided, it implies your currently \nchecked-out position (referred to as HEAD), usually being your \nlatest/previous commit, which is exactly what you`re interested in.\n\n\nAs a side note, if you think you don`t need it, you can skip staging \narea and commit all the modifications/deletions without a need of \nadding them first by using `git commit --all`, as per git-commit[3] \ndocumentation.\n\nJust pay attention that untracked files are not affected, you still \nneed to add them first to tell Git to start tracking them, including \nthem in the next commit, but that seems to align nicely with your \nexpectations already.\n\nI personally find the staging area to be one of the greatest Git \npossibilities, but I do understand beginners getting confused by it, \nas admittedly I once was myself.\n\n\nIn the end, you may want to ask questions like this on Git users \nmailing list[4] on Google Groups, being a a nice place for beginners \nto get answers to their concerns.\n\n[1] https://git-scm.com/docs/git-add\n[2] https://git-scm.com/docs/git-diff\n[3] https://git-scm.com/docs/git-commit\n[4] https://groups.google.com/forum/?fromgroups#!forum/git-users\n\nRegards,\nBuga\n"},{"id":"319282","messageId":"86h90sy64v.fsf@local.lan","threadId":"45909","inReplyTo":"03ef09e8-62a1-b6bb-041a-bad83dc353f4@gmail.com","subject":"Re: [noob] is this normal behavior","fromName":"Harry Putnam","fromEmail":"reader@newsguy.com","sentAt":"2017-05-10T17:27:12Z","receivedAt":"2017-05-10T17:27:25Z","isPatch":false,"sender":{"key":"reader@newsguy.com","avatar":null},"body":"Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:\n\n[...] snipped detailed reply\n [To Anyone who lands here on a search: Please read Igor D's full\n answer in this thread... ]\n\n> Just pay attention that untracked files are not affected, you still \n> need to add them first to tell Git to start tracking them, including \n> them in the next commit, but that seems to align nicely with your \n> expectations already.\n>\n> I personally find the staging area to be one of the greatest Git \n> possibilities, but I do understand beginners getting confused by it, \n> as admittedly I once was myself.\n\nThank you sir for such a full and complete answer.  Adds to by\nunderstanding in a big way.\n\n"}]}