Re: Branches & directories

[Hilco Wijbenga <hilco.wijbenga@gmail.com>]

On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
> 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'.

:-) Again, we are going in circles. I *know* a branch is just a
pointer. So what? To me, that's just the implementation. Why is that
relevant? What am I missing?

>>>> 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).

I don't think that changing the way I think would be very effective. I
still have to get my work done. And I don't want build artifacts from
one "pointer" ;-) leak into the working directory of another "pointer"
just because I changed "pointers". (I'm sorry, "pointer" just doesn't
work for me.)

How is this normally resolved? What do the Linux kernel developers do
when changing or creating a branch? Do they do some sort of "clean"
first?

And I'm getting quite close with "git ls-files -io --exclude-standard
--directory". :-) The cobbling-together-of-components approach looks
promising. ;-)

> 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.

Quite possibly but it seems to me that this is too low level. I think
there are already too many places where Git's implementation leaks
into its API. E.g., anything explicitly related to the index.

>>> 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.