Re: Git question: when using branches, how does git treat working files when changing branches?

[David Kastrup]

Alan Mackenzie <address@hidden> writes:

> Hello, David.
>
> On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote:
>> Alan Mackenzie <address@hidden> writes:
>
>> > It wouldn't work well for me.  The word "commit" has a meaning,

Slowly I am suspecting you are trying hard to make _both_ words in "git
commit" have a meaning.  Do you also try to make your mouse squeek by
removing the oil in its bearings?

>> > something like "hand over on a permanent basis".  When you make a
>> > "commitment", you are pledging your honour that you will stand behind
>> > what you have committed.
>
>> Nope, that's what git commit -s is for (Signed-off-by: footer).
>
> I was talking about the English word, not the use git makes of it.

It is a waste of time trying to teach a computer utility the meaning of
English by example.

Seriously, get a grip.  The meaning of talking to a computer lies in
what the computer does in consequence, not in how you say it.  You would
not write a program in C with array indices starting at 1 just because
the mathematical indices start at 1.

That you ascribe some particular meaning to "commit" in English common
language does not change one iota of what "git commit" does.

>> > What "commit" _doesn't_ mean is "temporarily store because there's
>> > nowhere better".
>
>> You are working with a distributed version control system.  It means
>> exactly that since you are working with your _private_ repository.
>> Anything non-trivial I push has actually seen a number of git commit
>> --amend and git rebase -i reorganizations so that what I end up
>> pushing is _polished_.
>
> It would be equally polished if you simply committed it when it was
> ready.  git commit --amend, and friends, don't polish code.

Sorry, but that's hogwash.  Unless you commit everything habitually in a
single humongous commit rather than in a sequence if individually
reviewable logical steps.  In which case you should change your habits
for the sake of reviewers and readers.

>> The most important tool of the mathematician and programmer is the
>> wastebasket, the most important tool of a distributed version control
>> system is local commits.
>
> A commit should have a meaning.  A repository filled up with commit
> messages like "Commit necessitated by git before switching branches."
> is not going to make thrilling reading at a later date.

You are _not_, I repeat _not_ listening.  I described exactly how you
later continue work.  You choose to ignore what I wrote in order to make
a point of Git using English differently from how you'd want to
interpret it.  That's nothing short of petulant.

>> You are not understanding your tool if you insist on using it like
>> CVS, and you are making life harder for yourself (since you need to
>> get everything right the first try) and everybody else (since you
>> won't get everything right the first try).
>
> Whether one commits after every single character change, or once when
> work is completed, or anything in between, the quality of the work
> depends only on the skill deployed in its implementation and the
> conscientiousness of its testing.

Part of the "implementation" is structuring your work into usefully
reviewable and understandable bits.

>> > Of course there are ways of undoing a commit if it was done by
>> > mistake.  But routinely to commit to something with the intention
>> > of repudiating it later is an abuse.  It is the sort of thing
>> > politicians do.
>
>> No.  No, no, no.  Absolutely no.  The commits in a distributed
>> version control system are yours only.
>
> They aren't.  If they were mine, I could chose to expunge an arbitrary
> commit from the repository, clearing both file content and the log of
> dross.

You certainly can do so with your own repository.  It doesn't happen
easily, but everything not reachable via branches is cleaned out after a
grace period of 3 months.  And of course you can speed this up to "right
now" in case you committed sensitive data or wagonloads of crud.

But even if you don't work with the full-steam cleanup tools, people
will have to actually know commit-ids in order to access stuff from your
repository that is no longer reachable, at least when they are working
with the standard communication channels without direct access to the
repository.

> Commits actually belong to the repository, which imposes stringent
> restrictions upon what can be done with them.

You are confused.  There is no restriction whatsoever to what you can do
to commits in _your_ repository.

>> It isn't an abuse of the creative process to make your first written
>> pages match the last written pages as if you exactly knew which words
>> you were going to write.
>
>> The sequence of commits is supposed to tell a story, not be a witness to
>> how you came up with the story.
>
>> Nobody wants to buy a book where the author handed in his wastebasket as
>> part of the manuscript.
>
> Nobody wants to buy a novel where "I woke up at 6:30, had a shower, got
> shaved, got dressed, had breakfast then went to work." appears three
> times in every chapter.

That's why you use git rebase -i and git commit --amend in order to fix
your submission before you submit it.

> Similarly, if I'm examining a git repository log, I don't want to have
> to ignore dross like "Commit necessitated by git ...." messages.  A
> commit should mean something.

Please learn to work with git rebase -i at the very least, even if you
refuse to learn about git commit --amend.

Your arguments are ridiculously wrong and based on juggling with words
rather than bothering to learn what they mean in the context of working
with Git.

Take a look at, say,
<URL:https://code.google.com/p/lilypond/issues/detail?id=4357#c33>.  Do
you want to tell me that you get a logical structure of commits like
that right at first try, without ever having to go back?

Do you think you are doing anybody a favor by dumping work like that in
a single commit, even when parts of that commit would have been
auto-generated and needed preparatory and conclusive work?

>> > If I were were to commit unfinished changes just for lack of somewhere
>> > proper to store them, inevitably some of these changes would find
>> > themselves becoming permanent, embarassingly so.
>
>> So read the stuff before pushing it upstream.  That's just common sense.
>
> I've pushed silly commits upstream before.

So you insist that once you have a silly commit, you do not want to fix
it?  But rather push it?  As a favor to whom?

> Commits like merges in my own repository.  There might be ways of
> avoiding these, but none of the documentation I've read has made it
> obvious how.

You rebase.

>> > Having continually to remember to cancel a commit each time I change
>> > branches would be an extra level of stress, of which there is already
>> > enough with git.
>
>> Why would you cancel a commit?  That does not make sense.
>
> I would want to cancel a "Commit necessitated by git before changing
> branches" type commit so as not to fill up the repository with dross.

I repeat: if you refuse to learn about git commit --amend as well as git
rebase -i, you don't have what it takes to participate in a meaningful
discussion about workflows.

> Like I said last night, I think I'm just going to use several
> repositories, each cloned from my main master, rather than several
> branches within one repository.  After all, I have a Terabyte of disk
> space.

You'll find that this comes with its own problems.  It has its place
(and you'll find the disk space impact pretty tolerable since Git
defaults to making hard links between cloned repositories on the same
drive), but it's not a one-size-fits all solution.  In particular if you
are working on several different angles to the same problem, being able
to merge, rebase, cherry-pick between approaches is useful and requires
your stuff to be in the same repository.

> Conceptually, working files are associated with a particular branch,
> not the repository as a whole, and git does not handle working files
> well.

Shrug.  man git-worktree should help you.

> I doubt any other VCS handles them any better.  (Is this what Michael
> Jackson, an author of a structured programming book, used to call a
> "structure clash"?)  Committing working files in an arbitrary state in
> order to swap branches is a workaround, not a feature.

Again, your insistence of interpreting Git's actions and related
workflows solely based on the common English meaning of parts of its
command names is plain silly.

> The bug it works around is the failure properly to associate working
> files with the pertinent branch.

At some point of time you should develop a theory as to why Git actually
managed to become the most popular version control system in spite of
the meaning of its commands not being obvious as soon as you can wave
around an English language certificate.

-- 
David Kastrup