Git help thread

[Rachael]

If you made a commit, then it's not gone for good but recovering it is very hard. If you didn't commit your changes, then they are wiped completely.

If you remember your most recent commit number you can do "git checkout -B newbranch <commit hash>" to automatically checkout that commit hash at that point in history and give it a new branch.

Additionally, you can look at your reflog in TortoiseGit (it's under Browse Repository and Browse References) and you can see a log of your actual actions (it's like the Activity Log in Facebook). Using this, you can recover deleted branches and the like.

[Graf Zahl]

They are not immediately wiped. If you are lucky you can restore them from the cache until the next garbage collection.
The wise approach is to set a tag on the orphaned branch to prevent this.

[Nash]

I specifically want the wipe (I basically wanted to undo a huge round of commits and start over) so this is good to know, thanks.

[Nash]

When maintaining forked projects - say my project is forked from GZDoom - is there no way to avoid littering my commit history with those "Merge branch 'master' of https://github.com/coelckers/gzdoom" entries? I have been pulling updates from GZDoom frequently over the past few years so you can imagine there's a huge pile of them by now...

[_mental_]

You can do rebase instead of merge during pull. The first command line do pull with merge, the second one with rebase:

Code: Select all

git pull coelckers master
git pull --rebase coelckers master

The first parameter after pull is remote name, the second is branch bane.

For Git UI clients actual procedures may vary. For example, SourceTree has an option for this in Pull dialog.

[Rachael]

Keep in mind that doing rebase will break push/pull compatibility with other users. There's a reason why a rebase is blocked (by default) when you attempt to push it to Github (or other online repository) if your remote branch/master contains a HEAD that your local branch/master does not have - you can, of course, force the push anyway but that's not a good idea if anyone uses your repo for downstream.

Doing multiple rebases this way is catastrophic to any users who regularly use "git pull" on your repository - and even worse, any conflicts will make things 10 times worse because you will have to resolve them in every rebase - and even worse than that, if you have any collaborators they will push the dirty history right back, de-effectivizing any previous rebase you did.

It's better to live with the "merge" commits - they are valid commits in their own right and are good for tracking.

[_mental_]

If the idea is to keep previous history intact (it wasn't quite clear from the request) then there are possibilities to do this: cherry-picking commit range and more precise rebase control.
For example, discussions on this topic are here and here.

[Rachael]

Another thing you can do is if you pull from a remote that is not your own, you can after the pull (provided there are no conflicts) but before you do a push - do a "git rebase origin/master" - this will remove the merge commit and convert all of the other's commits into cherry-picks automatically. This can be done with conflicts, too, however they will have to be resolved individually for every commit that has one and this can be time-consuming.

Rebasing on your own master is something that will actually not have the catastrophic effects I described earlier when doing a push - however, keep in mind that your cherry-picks are no longer a part of the other person's repository's history - and therefore you will have to start cherry-picking commit ranges as _mental_ said, and that can be a little bit more time-consuming.

[Graf Zahl]

My clear advice is: Don't. Even. Think. About. It.
As long as you deopend on the other repo you have to keep its commit history intact in yours and cannot intermingle your own commits with it. The long term hassle will far outweigh any perceived benefit.
For pull requests you can safely do a rebase, because a PR is normally a branch that won't see any future development.

[Nash]

Alright, noted. My main concern was because sometimes I want to filter my own commits by typing "nashmuhandes" into the log viewer... but there are so many results due to all the "merge master" commits.

Anyway, I'll live with it.

[Rachael]

Have you tried adding "-merge" to the search? Not all searches support the exclude function but some do - this is of course having no idea what Git client you are using (assuming it's a graphical one, at any rate). Some git clients might support exclusions with a keyword (i.e. "NOT" or "not:") - you'd have to consult your client's documentation to see what's available.

Failing that, if you're using the command line, there's always grep pipes. "grep -v" will print everything that does not match the search query.

Code: Select all

type githistory.txt|grep "nashmuhandes"|grep -v "Merge"

[Nash]

Using TortoiseGit. Yeah, making it exclude "merge" was probably the best idea and something that completely flew over my head in hindsight. :P