On 21 August 2011 19:05, Michael Witten <mfwitten@xxxxxxxxx> wrote: > On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >> On 21 August 2011 17:07, Michael Witten <mfwitten@xxxxxxxxx> wrote: >>> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>>> On 21 August 2011 16:06, Michael Witten <mfwitten@xxxxxxxxx> wrote: >>>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>>>>> On 21 August 2011 13:53, Michael Witten <mfwitten@xxxxxxxxx> wrote: >>>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga >>>>>>> <hilco.wijbenga@xxxxxxxxx> 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. Thanks for sticking it out. :-) That all makes sense. I think it's all pretty clear now. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html