Re: Hey - A Conceptual Simplication....

[Jakub Narebski <jnareb@gmail.com>]

"George Dennie" <gdennie@pospeople.com> writes:

> Thanks Jan, Jason, Jonathan, and Thomas for your response, your thoughts and
> concerns are enlightening....
 
> Jason Sewell wrote...
>
> > If you have a bunch of debugging code sitting around in your working tree
> > after you've tracked down a problem, you don't want to commit all
> > of those printfs, etc. - you want to commit the fix. This has
> > ramifications from making diffs of history cleaner to making git
> > bisect actually useful.
> 
> One of the concerns I have with the manual pick-n-commit is that you can
> forget a file or two.

I don't think that this concern is valid.  

The files which make project are those defined in Makefile or
equivalent project file, _not_ all files (or even all files of
specific type / extension) that do happen to reside in given
directory.  And those files whould be known to git, either added when
importing project into git, or added when they were created.  And if
they are known it is enough to use "git commit -a" to pick all
changes.

So I don't see how you can 'forget a file or two'.

Are those *theoretical* concerns, or is it something that happened to
you doring using git?

> Consequently, unless you do a clean checkout and test
> of the commit, you don't know that your publishable version even compiles.
> It seems safer to commit the entirety of your work in its working state and
> then do a clean checkout from a dedicated publishable branch and manually
> merge the changes in that, test, and commit.

That's what

  git stash --keep-index

is for.  

That, and continuous integration repository, with it's hooks.

> 
> It seems the intuitive model is to treat version control as applying to the
> whole document, not parts of it. In this respect the document is defined by
> the IDE, namely the entire solution, warts and all.

Yes, and IDE has project file which defines which files are in
project, just like version control system has it's tracked files.

> When you start
> selectively saving parts of the document then you are doing two things,
> versioning and publishing; and at the same time. This was a critical flaw in
> older version control approaches because the software solution document is a
> file system sub-tree.

Atomic commits are important, but the distinction between tracked
files, (untracked) ignored files, and files in "limbo" state (neither
tracked nor ignored) is orthogonal to having atomic commits.

> Jason Sewell wrote...
>
> >  Isn't fastidiously maintaining a .gitignore file to contain
> > everything you *don't* want in the project more confusing than
> > explicitly specifying things you *do* want in the project?  
> 
> This is git ignore for "cleaning prior to a check" and git ignore for
> "adding to index" and is not an either or. You would specify what you don't
> want to version tracked as normal but you can also stipulate what you don't
> want to be deleted during a clean restore (which should otherwise completely
> wipe the folder prior to restoring a specific commit). This would permit
> embedding non-version elements within the version tree for whatever reason
> you find necessary.

And this is supposedly easier to use?  I don't think so.

> Thomas Rast wrote...
>
> > That would require supernaturally good maintenance of your
> > .gitignore to avoid adding or (worse) nuking files by accident.
> 
> On the contrary, the approach would all but eliminate the possibility of
> loss of data since you would not manually (and therefore error prone-ingly)
> pruning until after a commit. In fact, one might default automatic commits
> (if required) prior to checkouts or at least an alert system when
> uncommitted changes exists.

What?  I cannot understand you here.

I think that automatic pruning of non-versioned files is _more_ error
prone than manual deleting of files.  And much more error prone that
just keeping non-ignored and non-tracked files.

-- 
Jakub Narebski
Poland
ShadeHawk on #git