Re: Branches & directories

[Michael Witten <mfwitten@gmail.com>]

On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>> Isn't a branch simply a way to track changes separately?
>>>>
>>>> Well, what does that mean, really? You can certainly use branches to
>>>> help you achieve that goal.
>>>
>>> It means my commits are chained together separate from, say, master.
>>
>> Well, that's not what a git branch provides in general.
>
> Er, so what *does* a Git branch provide then?

I think my other replies (including the link) repeat myself quite enough.

A branch is just a pointer. That's it.

Quit saying `branch' to yourself. Start saying `pointer' or
`reference' or `commit label' or even `special tag'.

>>> I feel like we're talking in circles. I get (and even agree with) what
>>> you're saying but I don't see how it changes the concept of a branch.
>>>
>>> In any case, what I'm more interested in is knowing whether we can
>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>> changes) to a branch.
>>
>> No, because a branch doesn't IN ANY WAY provide the structure for that
>> kind of thing.
>
> Obviously, we'd need to expand that structure.
>
> I tried (ab)using git stash to get what I want but it ignores
> untracked/ignored files (not a big surprise, of course). It seems the
> functionality is almost there. If I could just combine git checkout
> with git stash (and have it work with untracked/ignored files) in a
> script or alias, I'd be a happy camper. I'll have to give it some more
> thought.

This cobbling together of git's components for this purpose is
actually a fairly frequent story on this list. Either git does indeed
need something more substantial as a `branch', or people (meaning you)
need to change the way they think (and I'm not sure which solution
would be best, honestly).

If there is a change, then what is currently called a `branch' should
be renamed explicitly to `pointer' or a `reference' or something like
that.

>> Of course, you could use what git calls a 'branch' in
>> order to implement what you imply is a 'branch', but git's concept of
>> a branch and your concept of a branch are not at all the same concept
>> (which is why the term 'branch' is so unfortunate).
>
> You've completely lost me. You may very well be right but all I see is
> that you're pointing out how branches are implemented in Git.

That last sentence and your earlier sentence:

> Obviously, we'd need to expand that structure.

vindicate everything I've said about the choice of nomenclature. The
term `branch' is a TERRIBLE choice.