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