Git help thread

Archive of the old editing forum
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
User avatar
Rachael
Admin
Posts: 13084
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Git help thread

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48325
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Git help thread

Post by 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.
User avatar
Nash
 
 
Posts: 17319
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Git help thread

Post by 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.
User avatar
Nash
 
 
Posts: 17319
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Git help thread

Post by 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_
 
 
Posts: 3784
Joined: Sun Aug 07, 2011 4:32 am

Re: Git help thread

Post by _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.
User avatar
Rachael
Admin
Posts: 13084
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Git help thread

Post by 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_
 
 
Posts: 3784
Joined: Sun Aug 07, 2011 4:32 am

Re: Git help thread

Post by _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.
User avatar
Rachael
Admin
Posts: 13084
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Git help thread

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48325
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Git help thread

Post by 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.
User avatar
Nash
 
 
Posts: 17319
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Git help thread

Post by 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.
User avatar
Rachael
Admin
Posts: 13084
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Git help thread

Post by 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. :P "grep -v" will print everything that does not match the search query.

Code: Select all

type githistory.txt|grep "nashmuhandes"|grep -v "Merge"
Last edited by Rachael on Thu Sep 07, 2017 10:26 am, edited 1 time in total.
Reason: minor correction
User avatar
Nash
 
 
Posts: 17319
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Git help thread

Post by Nash »

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

Return to “Editing (Archive)”