Re: Branches & directories

> On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> 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?
>
> You're missing (or, rather, ignoring) the fact that what is called a
> `branch' in git is exactly what is intended to be called a `branch' in
> git; it is not merely an incomplete or weak implementation of
> something.
>
> You're probably also missing the fact that I'm simply arguing the
> point that the term `branch' was a TERRIBLE choice, and your remarks
> and confusion have confirmed that. Other than that, most of what I'm
> saying has very little relevance to what you're trying to do; I was
> following a philosophical tangent inspired by this thread.
>
>>>>>> 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.)
>
> It doesn't make any sense to say `artifacts from one "pointer"'. You
> are now, unfortunately, just using the term `pointer' like the term
> `branch'; you are refusing to let go of the concept that the word
> `branch' alone has seared into your brain.
>
> As has been my entire point: You have been corrupted by the wrong
> choice of words.
>
>> 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?
>
> Perhaps `git clean' would be of use to you.
>
>> And I'm getting quite close with "git ls-files -io --exclude-standard
>> --directory". :-) The cobbling-together-of-components approach looks
>> promising. ;-)
>
> Hence what I said earlier:
>
>  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).
>
> However, please note that your solution is not completing the
> implementation of branches in git, but rather using git's branches to
> implement something entirely different (and which you think should be
> called `branches'). The terminology is the key point in the confusion.
> I dare say, had git's branches been instead called `pointers' or the
> like, then you would have just gone about the business of implementing
> your `branches' on top of them without thinking twice.
>
>>> 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.
>
> Git's power is its simple conceptual basis, and what you are calling
> low-level is in fact just the ability to deal within the language of
> those simple concepts.
>
> Git's weakness is that the most public interface shoehorns that simple
> conceptual basis into not just a more automated system, but into a
> weaker model that works well most of the time, yet fails and even
> corrupts the mind of the user when it comes to more interesting
> scenarios.
>
> What you call a leaky abstraction is not the `low-level' conceptual
> basis peeking through innappropriately. Rather, it is the falling
> apart of the shoddy `higher-level' facade.
>
>>>>> 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.