Uwe Brauer writes: >>>> "Arne" == Arne Babenhauserheide <[email protected]> writes: > > > Uwe Brauer writes: > > >> git log --graph --decorate --pretty=short | git name-rev --stdin | more > > … > >> Resulting for example for the auctex repository in > >> > >> * commit eb2d64bede8587c864c3031f233a0ae87c3f3a03 (master) (HEAD, > origin/master, origin/HEAD, master) > >> | > >> * commit 17d1a5d71f9fb6adbb90e17dbf223f3bf1e2f92a (master~153) > >> |\ Merge: f9efa73 1950012 > >> | * commit 1950012155d539f05c393dae3d6e93548bbc57b2 > (remotes/origin/simplify-TeX-parse-error~136) > >> | |\ Merge: b4ff376 4b21d3f > > >> So the () after the HASH indicate to which branch a commit belongs. > > > What happens here if I create a branch which starts at 17d1a5d. Which > > branch will 17d1a5d belong to? > > > From what I have read, > https://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/ > I think 17d1a5d would belong to the new branch > and to master.
I now tested this (see next part) and git simply chooses a branch to show based on some criterion. > >> * commit eb2d64bede8587c864c3031f233a0ae87c3f3a03 (master) (HEAD, > origin/master, origin/HEAD, master) > >> | > >> | * commit XYZ (foo) (HEAD, origin/master, origin/HEAD, master) > >> |/ > >> * commit 17d1a5d71f9fb6adbb90e17dbf223f3bf1e2f92a (master~153 or > foo~1?) <--- this is the question > > I think both From what I see in the blog post it would pick one. I don’t know which criteria is used. But I can test that… Here’s what I get when I start committing on master, then switch to a branch foo and finally merge foo into master: * commit 48ccc26e9a464df0a2e838d2338e472acede0c1e (master) (HEAD -> master) |\ Merge: 97ec8a6 cf1d596 | * commit cf1d596586a52f5902c498a2107ab3eb3f65685c (foo) (foo) | | | * commit 2787987c70c00e54d21f3ae8a8bd4ff9c55102c5 (foo~1) | | * | commit 97ec8a605921aeca0fce5ca691bbbe3ea9213ef7 (master~1) |/ | * commit 41beb6704c82243ff0f15ab74075d05c24f5fecb (foo~2) As you can see, the root is misattributed to foo. So felipec simply got lucky that he picked an example where this command actually provides the same info as named branches, but the result can easily be false. This graph is generated from the following commands (then trimmed): git init foo cd foo echo 1 > 1 git add 1 git commit -m 1 echo 1.1 > 1 git add . git commit -m 1.1 git checkout -b foo master~1 echo 1.2 > 1 git add . git commit -m 1.2 echo 1.2.1 > 1 git add . git commit -m 1.2.1 git checkout master git merge foo echo 1.2.1/1.1 > 1 git add . git commit -m "1.2.1/1.1" git log --graph --decorate --pretty=short | git name-rev --stdin > > What happens if origin removes the branch simplify-TeX-parse-error (as > > is the common action when a github pull request is merged)? > > Oh this I don't know, good point. (I only use git via the hg-git plugin) From what I see, the information is then gone. Felipec relies on convention to avoid that (people writing the merged branch into the merge commit). That’s a crutch to avoid being bitten by a weakness of the tool he uses. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
_______________________________________________ Mercurial mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/mercurial
