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

Things I wish everyone knew about Git (Part II)

blog.plover.com

Post reply on HN
Print view View original

31–40 of 148 posts

Re: Things I wish everyone knew about Git (Part II)

#31

Post by lelandfe »

codingdave wrote: post #30

> It is really hard to lose stuff If that stuff is committed. Maybe I'm stating the obvious but conversations seem to revolve so much around finding stuff and merging stuff that my favorite use of git isn't talked about as much -- throwing stuff away. A commit is your save point - once made, you can basically code risk-free, knowing you can always go back to that save point. Try new things, thrash your code, don't st…

As a corollary: cheap branches are wonderful.

The workflow I teach the newbies at my job is to just do a quick `git checkout -b tempbranch` when trying out: complicated rebasing, cherry-picking commits, whatever.

Do your thing on that temporary branch. Did the thing work? Hell yeah. `git checkout - && git reset --hard tempbranch`. Presto magic, your old branch is now a perfect replica of tempbranch. It's as if you did the whole thing on your original branch to start.

Did it fail miserably? Oh well. `git checkout - && git branch --delete tempbranch`. It vanishes and no one has to know that the rebase fell apart. Your working branch is in pristine condition still.

Re: Things I wish everyone knew about Git (Part II)

#34

Post by [deleted] »

shikoba wrote: post #28
formerly_proven wrote: post #23

Earlier quoted context omitted.

Maybe it would have been good if the git defaults were changed from the defaults used for the kernel development workflow to the git workflow ~everyone else is using, even though git was created for the kernel people by the kernel people - most users are not kernel people. "git pull" in the kernel workflow is for integrating downstream changes into your own upstream repository. Meanwhile, "git pull" in the everyman w…

The idea of "merging into" has no meaning with git. You're merging two things into one. But saying that there are a master thing and a slave thing has no meanings.

[deleted]

Re: Things I wish everyone knew about Git (Part II)

#35

Post by emacs28 »

I made a simple script below I find useful that commits current changes then automatically rebases and squashes it with the previous commit, preserving the previous commit message. I find it useful for a way to quickly save current changes before switching branches, or for easily backing up work before its worth making a new separate commit:

  git add --all
  git commit --fixup=HEAD~1
  GIT_SEQUENCE_EDITOR="sed -i -re 's/^pick (.*)fixup! (.*)/fixup \1\2/'" git rebase -i --autosquash --autostash --keep-empty HEAD~2

Re: Things I wish everyone knew about Git (Part II)

#36

Post by lelandfe »

emacs28 wrote: post #35

I made a simple script below I find useful that commits current changes then automatically rebases and squashes it with the previous commit, preserving the previous commit message. I find it useful for a way to quickly save current changes before switching branches, or for easily backing up work before its worth making a new separate commit: git add --all git commit --fixup=HEAD~1 GIT_SEQUENCE_EDITOR="sed -i -re 's/^…

HN italics markup is mangling your code – indent the code block to fix :)

    like so!
> save current changes before switching branches

Also: why this over a stash? Stashing fundamentally just creates a hidden little commit with all your unstaged work on it. It does have one advantage over your approach, which is easily applying the work to another branch.

Re: Things I wish everyone knew about Git (Part II)

#37

Post by emacs28 »

lelandfe wrote: post #36
emacs28 wrote: post #35

I made a simple script below I find useful that commits current changes then automatically rebases and squashes it with the previous commit, preserving the previous commit message. I find it useful for a way to quickly save current changes before switching branches, or for easily backing up work before its worth making a new separate commit: git add --all git commit --fixup=HEAD~1 GIT_SEQUENCE_EDITOR="sed -i -re 's/^…

HN italics markup is mangling your code – indent the code block to fix :) like so! > save current changes before switching branches Also: why this over a stash? Stashing fundamentally just creates a hidden little commit with all your unstaged work on it. It does have one advantage over your approach, which is easily applying the work to another branch.

> indent the code block to fix :)

Thanks!

> Also: why this over a stash?

I just like this better because with stash you have to do one more command (stash pop) to get the changes back after switching back to the first branch, but this way the changes are already there when you switch back.

Re: Things I wish everyone knew about Git (Part II)

#39

Post by [deleted] »

eulenteufel wrote: post #25
praptak wrote: post #16

I love this quote from Part I: "Git has an elegant and powerful underlying model based on a few simple concepts: 1. Commits are immutable snapshots of the repository 2. Branches are named sequences of commits 3. Every object has a unique ID, derived from its content Built atop this elegant system is a flaming trash pile. "

The quote is kinda wrong in that point 1 and 2 are mixed up. Branches are just pointers to commits. Commits contain a reference to their history. It's only kind of incorrect because in praxis branches are used to refer to a history (a sequence of commits). But it's also misleading once you have to do anything more complicated than just commiting/merging. When I started out using git I was working with the same assump…

[deleted]

Re: Things I wish everyone knew about Git (Part II)

#40

Post by onpensionsterm »

>Some people automate this: they have a process that runs every few minutes and commits the current working tree to a special branch that they look at only in case of disaster.

This sounds nice. Does anyone have a concrete example?

I'd like to try with a cronjob but it would be useful to avoid having to create the job manually for each repo & I don't want a job repeatedly scanning all my disks. Is there anything like a global post-clone hook? Additionally, I'd be worried about race-conditions from saving work during the job.

Post reply on HN