Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Branches: Intuition and Reality

jvns.ca

Post reply on HN
Print view View original

211–220 of 281 posts

Re: Git Branches: Intuition and Reality

#211

Post by chlorion »

hnarn wrote: post #180
alex_smart wrote: post #156

Earlier quoted context omitted.

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

That does not sound right at all, I’m pretty sure there’s a warning when you try to checkout a branch that would override local unstaged changes. I might be wrong but I’d like some proof.

In some repo you have, make some changes to files that are tracked. Git status will show you "changes not staged for commit: ". Run "git checkout .", and check the status command again, it will be in a clean state.

>git status

    On branch feature/redacted
    Changes not staged for commit:
      (use "git add ..." to update what will be committed)
      (use "git restore ..." to discard changes in working directory)
 modified:   redacted.py

    no changes added to commit (use "git add" and/or "git commit -a")
>git checkout .

    Updated 1 path from the index
>git status

    On branch feature/redacted
    nothing to commit, working tree clean

Re: Git Branches: Intuition and Reality

#212

Post by zaphar »

dayjaby wrote: post #198
zaphar wrote: post #184

Earlier quoted context omitted.

There absolutely can be. Merge commits have multiple parent commits for example. It's definitely a graph not just a tree.

Parent comment was about disregarding merge commits.

You can't disregard merge commits. It's part of the structure.

Re: Git Branches: Intuition and Reality

#213

Post by baronswindle »

hackernews1134 wrote: post #210
paulddraper wrote: post #79

Earlier quoted context omitted.

Merging branch A into branch B does two things: 1. Create a new merge commit with two parents: the commit pointed to by A and the commit pointed to by B. 2. Set branch B to point at the new merge commit. This is a non-linear history; when comparing some commits there isn't a "before" or "after."

If I checkout the merge commit and then do a ‘git log -n 5’, which parent pointer is followed to show the previous commit logs? A or B or Both / all if it is more than a 2-way merge?

As I recall, it shows commits from both parents in order of the committed date.

Re: Git Branches: Intuition and Reality

#214

Post by Aeolun »

Reading this it seems to me that it should be incredibly easy to create an alternative version of the git client that stores the lineage per branch and can inform people if they’re doing things they probably shouldn’t.

Re: Git Branches: Intuition and Reality

#215

Post by andrybak »

chrnola wrote: post #100
andrybak wrote: post #58

Earlier quoted context omitted.

> Git doesn't have the concept of "main is special" Technically, there is special handling for both "master" and "main" in Git in fairly obvious, but I'd argue in a not very important way. When you merge two regular branches, the commit message is `Merge branch 'source' into destination`. But not if destination is `master` or `main` – the `into ...` part is omitted for those merge commits. But this is just for backwa…

There’s some special handling for FETCH_HEAD too (i.e. which branch on a remote is considered the default).

> which branch on a remote is considered the default

You probably mean this place in code: [1]. It uses function git_default_branch_name from refs.c [2], which uses config variable `init.defaultBranch` I've mentioned above. But if it and other look-ups fail, it does fall back to a hard-coded "refs/heads/master".

[1] https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394

[2] https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705

Edit: removed mention of a deprecated Git feature to avoid confusion.

Re: Git Branches: Intuition and Reality

#216

Post by Kuraj »

cpeterso wrote: post #160
mr_mitm wrote: post #121

Earlier quoted context omitted.

When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main .

By following this metaphor, a trunk would be the original commit, whereas branches are the tree branch tips.

Re: Git Branches: Intuition and Reality

#217

Post by OJFord »

skrebbel wrote: post #101
riperoni wrote: post #44

While the explanation is right in some sense, it misses a few points. Branches are pointers to a commit and that pointer is refreshed when a new commit is created. One could say they are a wandering tag (without explaining a tag for now). The actual chain of commits that represent what we see as branch comes from the commits themselves. Those commits point back to their parent commit. And then one can see why no bran…

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that git branches are branches in exactly the same way that the first element of a linked list in C “is” the linked list. Git was made by C people and they’re used to referring to entire data structures by way of some root element. I mean that doesn’t make me disli…

I don't see the problem?

Real natural tree branches grow.

If you move the branch to point somewhere else, then it's better/more accurately said that you changed the name to refer to a different branch. We can think of branches as the chains of commits; it's the names we give them that 'wander' both as we commit and if we move them to a different branch. But merging (as it were!) the concepts of branches and names for their tips is convenient, and often equivalent/inconsequential.

Re: Git Branches: Intuition and Reality

#218

Post by Kuraj »

MauranKilom wrote: post #60

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…

Nah I do that too. I also amend and push --force to my private branch a lot to make the git history easier to follow for whoever is going to do a code review.

Re: Git Branches: Intuition and Reality

#219

Post by CuriousCosmic »

ndriscoll wrote: post #164
CuriousCosmic wrote: post #146

Earlier quoted context omitted.

It actually does but it's very much in alpha/active development (under the umbrella of OpenSSF with the intent of being integrated into mainline git eventually). https://github.com/gittuf/gittuf

Git itself doesn't run a persistent process and I don't see how it'd make sense to prevent a user from making arbitrary changes to their local repo, so this sounds like just another server like GitHub, Gerrit, Gitlab, etc. that already have those features.

This provides a mechanism for any client to identify and reject changes from any given remote that are non-compliant with the policy committed to the repo.

So this is something that servers would certainly be able to use but it is also something that operates at the client level. And you could use it in environments where nobody uses the big hosted git platforms (github, gitlab, gitea, etc). So you could still use this in environments where you fetch changes to a project over ssh from a friend or cocontributor's dev machine. Or via basic, barebones read only https or ssh hosting.

i.e. this is access control that works independent of centralized servers.

Re: Git Branches: Intuition and Reality

#220

Post by lmm »

mr_mitm wrote: post #121
skrebbel wrote: post #101

Earlier quoted context omitted.

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that git branches are branches in exactly the same way that the first element of a linked list in C “is” the linked list. Git was made by C people and they’re used to referring to entire data structures by way of some root element. I mean that doesn’t make me disli…

When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

Well yes if you disregard the thing that makes it not a tree then it is a tree. But you can't disregard that!
Post reply on HN