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