Re: Hey - A Conceptual Simplication....

From: Jason Sewall <jasonsewall@gmail.com>
Date: Nov 18, 2009, 13:31 UTC
Message-ID: <31e9dd080911180531r1f693d7bi3d9408ef8219cce0@mail.gmail.com>
In-Reply-To: <005a01ca684e$71a1d710$54e58530$@com>

On Wed, Nov 18, 2009 at 7:55 AM, George Dennie <gdennie@pospeople.com> wrote:

Show 7 quoted lines

>
> In particular, why is Git not treating the entire working tree as the
> versioned document (qualified of course by the .gitignore file).
>
> Instead, Git is treating a manually maintained list of files within the
> working tree as the versioned document, this list being initialized and
> manually amended by the "Git add/rm/mv" commands, etc.

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?

Show 10 quoted lines

> The result is conceptual complexity and rather counter-intuitive behavior.
> For example, adding and renaming files outside of Git is not considered
> editing the version until you subsequently do a "Git Add ." Contrast that
> with editing or deleting files outside of Git. Yet adding and renaming files
> and folders is a significant part of substantive projects, especially in the
> early stages and experimental branches.
>
> Granted, this is not a big deal functionally, but what is being lost is
> conceptual simplicity (and consistency, in my book) and conceptual
> simplicity is a key value point, if not THE key.

In fact, it's a big deal in functionality, but the utility is in being able to to specify exactly what I want to be part of each commit. One of git's great features is the ability to specify *exactly* what you want to be part of each commit, down to the line. This means that each commit can be extremely fine grained and represent specific bug fixes and or features.

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.

Show 6 quoted lines

> Also can we augment checkout to totally CLEAN the working directory prior to
> a restore. If necessary we can augment .gitignore to stipulate those files
> or folders that should be excluded from the cleaning. This suggestion is in
> recognition of the fact that if you  are not versioning the file, it is
> typically trash; which becomes the case when the entire working treat is
> treated as the versioned document.

This is even worse. It's already pretty easy to trash your working directory by reflexively typing git checkout -f, and you want to

> Consequently, I recommend the following new commands:
>        "Git commit -x"   -- performs a "Git add ." then a "Git commit"
>        "Git checkout -x" -- that clean the working tree prior to perform a
> checkout

I see that Jan has replied with some loaded guns, *ahem* aliases. Go ahead and use them, but I recommend you look at the diffs in git.git or some other repository that takes advantage of making commits as compact as possible, and learn how to use git add -p.

Jason