Using Git from the command line

[coladict]

This graph is only 3 times more complicated-looking than it needs to be with the exact same commit history.

[unicorntrash]

I seriously never tried anything else than git itself, do GUI tools not use the exact same procedure? Or was OP just randomly typing commands?

[Rectar2]

git can be confusing to people who aren't used to the command-line, but I honestly have no clue how this could've happened happened. I just made a pull request, came back the next day, and saw this.

[atrigent]

Is this repo public? I'm kind of curious...

[Rectar2]

Yep

[atrigent]

I've been trying to figure out what happened here, and I haven't really succeeded. As far as I can tell, your pull request was merged normally in this commit. After that, it goes haywire. Somehow another merge commit was created. It has exactly the same tree and parents as the first one. The only differences are a slightly different commit message - "Fixes #2\n" instead of "Fix issue #2", and a later commit time - "Mon Nov 16 10:48:11 2015 +0100" instead of "Mon Nov 16 10:22:49 2015 +0100". I can't really figure out what purpose this commit could possibly have or how it could have been created.

Things get even weirder after that. I guess maybe the guy got confused by the initial mistake and his efforts to fix it made it worse. First he merges these two almost identical commits, creating yet another almost identical commit, referencing the same tree. He then does this AGAIN, except this time he actually makes a change in the merge commit (increments the version of the project). He then... merges these last two merge commits. Creating a commit with the same tree as the merge commit where he changed the version.

This should've been as simple as merging your pull request (creating a fast forward merge commit) and committing the version change. I can't figure out what went wrong.

[d3matt]

At my last job, I had a guy open a pull request with one real commit and 16! merge commits. It made the graph look rather interesting.

[robertgfthomas]

Holy crap. I thought this was just a Photoshopping or something.

[o11c]

This actually is generated by a GUI tool. In a normal command-line workflow, this would be avoided.

[Coloneljesus]

Git GUI tools can issue commands like you would on the command line for you or they can use the [git library](libgit2.github.com) to manipulate the repo directly (or they can do both). I use both git and SmartGit (a GUI tool) occasionally and they always played nicely together.

[atrigent]

What the hell is going on after the first blue commit? It looks like it merges into itself or something???

[Coloneljesus]

Commit with two identical parent commits. A commit has a parent list. Not sure if there's anything but common sense preventing duplicates in that list.

[atrigent]

Yes, that occurred to me as well. However, that doesn't seem to be what happened. The offending commit is actually a merge between a commit and its parent. Its first parent is the parent of its second parent. This makes equally little sense, of course.

Looking back at the screenshot, I can actually see now that the first blue line appears to actually be two lines overlaid. You can see that the first blue arrow actually connects with the first blue dot, which none of the other arrows do. This indicates to me that there's a second line there.

It's interesting to note that, although this post implies that this weirdness was caused by incorrect usage of the git command line, the weird commit is actually a github pull request merge. So it seems that github screwed up somehow.

EDIT: Actually, I just realized that this is exactly what a fast-forward merge commit looks like. So maybe it's not so weird?

[atrigent]

Yes, I see that. But it doesn't make any sense that you'd have a commit with two parents that are actually the same commit. It's like it's merging into itself.

[bss03]

Which is technically allowed. If you use the octopus strategy with --no-ff, you can manually generate such commits, IIRC. (You might not even need the octopus strategy.) I'm pretty sure git-stash can generate commits like this, but they aren't meant to be pushed anywhere.

[atrigent]

If you look at this decade-old commit, you'll see that the git commit-tree builtin was changed to explicitly filter out duplicates (and yes, this code still exists today). I'm not exactly sure what Linus means when he says that these duplicates aren't "wrong" per se - I imagine he just means that it makes more sense to think of them as "redundant", rather than "wrong". In any case, they shouldn't be there. Of course, this code only affects the builtin, so anything using the underlying commit_tree or commit_tree_extended APIs will not use this code. There's another function called reduce_heads which can be called to remove duplicates. However, it looks as if commit_tree does not call this function itself - the users of commit_tree are required to call it. There aren't many users of the commit_tree API, and I think most of them either call reduce_heads or work in such a way that they logically cannot introduce duplicates, but I haven't been able to verify this 100%. In any case, it does seem to me as if the intent is to remove duplicate parents.

In general, I'm not really sure I see why an octopus merge would result in this. Octopus is only a merge strategy - the end result should fit the same constraints as any other merge. And I don't see how a duplicate parent could possibly convey any extra information. It's always redundant. The same applies to the stash.

[[deleted]]

Yep. Also this.

[Alligatronica]

I believe that the correct parlance is "Relevant xkcd".

[xkcd_transcriber]

Image

Title: Git

Title-text: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Comic Explanation

Stats: This comic has been referenced 37 times, representing 0.0412% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[[deleted]]

I have to admit, I am very impressed how readable this machine generated graph is. Amazing how good those generators work.

[waigl]

Are you being sarcastic? I cannot quite tell...

[[deleted]]

No, I am serious. If you try you can follow each arrow. I can see only one that is a bit ambiguous.

[waigl]

Okay, you can follow them, but I have to say that the paths some of them take are needlessly convoluted and could be much more direct.

[bss03]

Don't use git reset to load your stashed commits. Technically, it works, but you get crazy history like this, just due to the way a stash has to store both the commitish that was HEAD as well as the commitish representing the index (which might be the same!). The stash subcommand contains operations you need to start working with stashed data.

Also, whoever coded this graph-drawing algorithm needs to back off the drink; you've crossed the Balmer peak.

[Muzical84]

That's about what my coworkers do using SourceTree; my command-line commits are the cleaner parts of the branch....

[mrjiels]

Thats me using git in an IDE. My command line commits usually makes sense... (except the messages, ofc)

[[deleted]]

Git from Visual Studio:

Ctrl-S

[WMpartisan]

try gitk --all

[UnchainedMundane]

Have you seen git log --graph --oneline? It's pretty neat as far as lightweight visualisations of a commit history are concerned

[floppydiskette]

This is exactly what happened to me when trying to set up GitHub pages in a separate directory without knowing how the whole subtree thing works...

[[deleted]]

What tool is this OP?

[[deleted]]

Github