git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Branches & directories

From
HWHilco Wijbenga <hilco.wijbenga@gmail.com>
Date
Aug 22, 2011, 00:47 UTC
Message-ID
<CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com>
In-Reply-To
<CAMOZ1BtOkwVbC3RyJVQb7K1DRMnJf3_omn7zrkzoE48Ayu7HBg@mail.gmail.com>
On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
Show 23 quoted lines
> 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?

Show 24 quoted lines
>>>> 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.

Show 14 quoted lines
>>> 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.
Previous: Michael WittenNext: Hilco Wijbenga
Message 17 of 52 in “Branches & directories”
  1. Hilco WijbengaAug 17, 2011
  2. Evan ShelhamerAug 17, 2011
  3. Junio C HamanoAug 17, 2011
  4. Hilco WijbengaAug 17, 2011
  5. Jonathan NiederAug 18, 2011
  6. Hilco WijbengaAug 21, 2011
  7. Michael WittenAug 18, 2011
  8. Michael J GruberAug 18, 2011
  9. Michael WittenAug 18, 2011
  10. Jonathan NiederAug 19, 2011
  11. Hilco WijbengaAug 21, 2011
  12. Michael WittenAug 21, 2011
  13. Hilco WijbengaAug 21, 2011
  14. Michael WittenAug 21, 2011
  15. Hilco WijbengaAug 21, 2011
  16. Michael WittenAug 22, 2011
  17. Hilco WijbengaAug 22, 2011
  18. Hilco WijbengaAug 22, 2011
  19. Michael WittenAug 22, 2011
  20. Hilco WijbengaAug 22, 2011
  21. Kyle MoffettAug 22, 2011
  22. Hilco WijbengaAug 22, 2011
  23. Kyle MoffettAug 22, 2011
  24. Hilco WijbengaAug 22, 2011
  25. Kyle MoffettAug 22, 2011
  26. Hilco WijbengaAug 22, 2011
  27. Restoring timestamps (Re: Branches & directories)Jonathan Nieder, Aug 22, 2011
  28. Hilco WijbengaAug 22, 2011
  29. Jonathan NiederAug 22, 2011
  30. Hilco WijbengaAug 23, 2011
  31. Hilco WijbengaAug 23, 2011
  32. Enrico WeigeltOct 2, 2011
  33. Hilco WijbengaOct 2, 2011
  34. Michael WittenAug 23, 2011
  35. Robin RosenbergOct 2, 2011
  36. Ronan KeryellOct 2, 2011
  37. Matthieu MoyOct 2, 2011
  38. Hilco WijbengaOct 2, 2011
  39. Hilco WijbengaOct 2, 2011
  40. Jeff KingOct 3, 2011
  41. Hilco WijbengaOct 3, 2011
  42. Jeff KingOct 3, 2011
  43. Matthieu MoyOct 3, 2011
  44. Jeff KingOct 3, 2011
  45. Matthieu MoyOct 3, 2011
  46. Jeff KingOct 3, 2011
  47. Junio C HamanoOct 3, 2011
  48. Jeff KingOct 3, 2011
  49. Hilco WijbengaOct 3, 2011
  50. Robin RosenbergOct 3, 2011
  51. Hilco WijbengaOct 3, 2011
  52. Hilco WijbengaOct 2, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.