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

Learn the workings of Git, not just the commands (2015)

developer.ibm.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Learn the workings of Git, not just the commands (2015)

#41

Post by erwincoumans »

balefrost wrote: post #23
erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge).

One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)

Re: Learn the workings of Git, not just the commands (2015)

#42

Post by commandlinefan »

erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

I'm the same - although I've had many experiences in the past where I avoided the time-saving tools because they were too complex in the moment and then kicked myself later on when I realized just how much time I had been wasting by avoiding spending ten minutes learning the time saving tools, every time I try to do a git merge "the right way", I end up with conflicts that shouldn't be conflicts and changes that I didn't want to pull in that I have to manually undo until I just give up and "manually" merge.

Re: Learn the workings of Git, not just the commands (2015)

#43

Post by MarkSweep »

erwincoumans wrote: post #19
globular-toast wrote: post #17

Earlier quoted context omitted.

"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?

Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.

This sort of use case makes sense to make a copy of the .git folder. When you are trying to rewrite the history of a whole Git repo, throwing away the repo and starting for a backup is often easier than trying to unwind changes.

Though in this specific case of rewriting emails, there is a way in git to do it without rewriting history:

https://git-scm.com/docs/gitmailmap

Re: Learn the workings of Git, not just the commands (2015)

#44

Post by [deleted] »

erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

[deleted]

Re: Learn the workings of Git, not just the commands (2015)

#45

Post by zelphirkalt »

altonen wrote: post #25
balefrost wrote: post #23

Earlier quoted context omitted.

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.

Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.

Re: Learn the workings of Git, not just the commands (2015)

#46

Post by dec0dedab0de »

globular-toast wrote: post #17
erwincoumans wrote: post #15

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja…

"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?

Are you really shocked that someone would make a backup before doing something they are unsure of?

Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.

Re: Learn the workings of Git, not just the commands (2015)

#47

Post by pfarrell »

_dain_ wrote: post #13
pfarrell wrote: post #12

Earlier quoted context omitted.

Poe's Law is getting me on your comment. If it wasn't sarcasm, what's an example of a weakness? IMHO, there's a learning curve to using git and especially getting to the point where you can be your team's go-to person for git questions. However, I hold the opinion that of the many technologies out there, git is among those that is worth any investment you can make in learning it. Personally, long term use of git has…

quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.

git reset: unstage a change

git revert: create a commit that reverses a previous commit

git restore: you got me. I can't remember

Re: Learn the workings of Git, not just the commands (2015)

#48

Post by Accacin »

_dain_ wrote: post #13
pfarrell wrote: post #12

Earlier quoted context omitted.

Poe's Law is getting me on your comment. If it wasn't sarcasm, what's an example of a weakness? IMHO, there's a learning curve to using git and especially getting to the point where you can be your team's go-to person for git questions. However, I hold the opinion that of the many technologies out there, git is among those that is worth any investment you can make in learning it. Personally, long term use of git has…

quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.

I'm pretty basic with my Git knowledge. I can merge, rebase, reflog, and the other basic things. However, even I know the difference between reset, revert, restore, and generally use them daily.

Now, I generally do not remember many of the extra arguments that can be passed apart from 'reset --hard/--soft', 'git log --stat/--oneline --decorate', etc.

Personally I've found git complicated when I've worked at a place with bad 'git' discipline. When I've worked at companies with sane branching agreements, etc. I rarely face problems.

Re: Learn the workings of Git, not just the commands (2015)

#49

Post by DarylZero »

icedchai wrote: post #38
balefrost wrote: post #23

Earlier quoted context omitted.

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!

You don't need to create backup branches ahead of time with git, because the reflog saves every branch before every operation. You can create your backup branch from the reflog _after_ you discover you need it!

Re: Learn the workings of Git, not just the commands (2015)

#50

Post by rileymat2 »

pfarrell wrote: post #47
_dain_ wrote: post #13

Earlier quoted context omitted.

quick: explain to me the difference between "git reset", "git revert" and "git restore", without looking up the docs.

git reset: unstage a change git revert: create a commit that reverses a previous commit git restore: you got me. I can't remember

Reset is more overloaded once you add parameters.
Post reply on HN