Live data from Hacker News

Better Git configuration

blog.scottnonnenberg.com

31–40 of 66 posts

Re: Better Git configuration

#31
post #26

I'm a git noob. I realy mis an option to simply backup my current work situation to Git and work further on it on another machine, or simply later with the knowledge that everything is safe on the server. Currently I have a big list of commits called "Backup" which I always push immediately. It's ugly. Is there a way to save to the git server your current situation with bothering others working on the project with yo…

You could push to a private git repo or server, that way you don't bother anyone, and then when you're in a clean state push to the origin

Re: Better Git configuration

#32
post #30
post #28

Earlier quoted context omitted.

Sounds like you want to work on a separate branch. Also sounds like you'd want to rebase onto the correct branch when done, so that you can reorganize commits

I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message. Git sync would be the equivalent of hitting ctrl-S working on a doc in a Dropbox folder. You hit…

The workflow is entirely up to you and your collaborators. "commit" does not have be literally a commitment. Try branching on your branches so that you have the freedom to experiment.

Re: Better Git configuration

#33
post #30
post #28

Earlier quoted context omitted.

Sounds like you want to work on a separate branch. Also sounds like you'd want to rebase onto the correct branch when done, so that you can reorganize commits

I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message. Git sync would be the equivalent of hitting ctrl-S working on a doc in a Dropbox folder. You hit…

I do basically what the parent suggested for all my git work, i.e. it's my workflow. Call your branches wip-* to signal that you'll be using it haphazardly, don't bother doing "clean" commits while working (just commit stuff whenever you feel like it or when you might want to backtrack an experimental change, use the message "wip" or whatever). Push to branch whenever you want a "backup", e.g. when moving to a different machine.

When done, clean up the history[1], push to a different "real" branch for review. Delete wip-* branch.

Unless people have actively checked out your branch locally they shouldn't have any "mess" on their end. (They'll have a remote branch listed by "git branch -r", but all of those can be cleaned up periodically with a "git prune ...".)

I haven't heard any complaints so far. (I've been doing it this way for 4+ years, I think.)

[1] I usually find that it's easier to split/clean up after the feature is almost completely done and ready for review. When I'm "in the zone" I don't want to have to suddenly switch to the "cleaning up history" mode.

Re: Better Git configuration

#34
post #31
post #26

I'm a git noob. I realy mis an option to simply backup my current work situation to Git and work further on it on another machine, or simply later with the knowledge that everything is safe on the server. Currently I have a big list of commits called "Backup" which I always push immediately. It's ugly. Is there a way to save to the git server your current situation with bothering others working on the project with yo…

You could push to a private git repo or server, that way you don't bother anyone, and then when you're in a clean state push to the origin

This is the best method in my opinion. Back up simply by

    git push backup my-new-branch

Re: Better Git configuration

#35
post #26

I'm a git noob. I realy mis an option to simply backup my current work situation to Git and work further on it on another machine, or simply later with the knowledge that everything is safe on the server. Currently I have a big list of commits called "Backup" which I always push immediately. It's ugly. Is there a way to save to the git server your current situation with bothering others working on the project with yo…

What you could do is commit half-finished work with the name “Backup”, and then commit --amend over the top of it once that piece of work has completed. This ensures your for-sync-only commits won’t get in the way of the other commits.

However, I recommend you use a separate tool for backups and syncing than the tool you use for version control. For example, you could use Rsync to push the files -- both the .git folder and your source code files -- to a remote server, and then pull them down on another computer. Not only will you only be committing for actual commits, but you can also save the state of your repository and continue working on it later; you could stage certain files and not commit them, sync your .git folder to another machine, then have those same files staged but not committed.

Re: Better Git configuration

#36
post #30
post #28

Earlier quoted context omitted.

Sounds like you want to work on a separate branch. Also sounds like you'd want to rebase onto the correct branch when done, so that you can reorganize commits

I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message. Git sync would be the equivalent of hitting ctrl-S working on a doc in a Dropbox folder. You hit…

> I do work on my own branches indeed. But something like "git sync" would be nice, no commits, no mess for your collaborators or in your Git history, just my current work, safe on the server, to be synced elsewhere without formally committing anything so that commits can be real improvements that require a commit message.

You seem to be hung-up on commits or have an inexplicable aversion (IMO) to committing to a private, expendable branch. Git made branching cheap and easy by design - you can go crazy on your private 'backup' branches without having to add detailed commit messages. When you are happy, you can rebase or squash merge into the 'real' branch with proper commit messages and delete the backup branch. This will not create a mess for collaborators or your Git history (after you've deleted the ephemeral branches).

As a matter of fact, you could create an alias for 'git sync' that does the above in the background, if you find the individual steps too tedious to manually type in.

Re: Better Git configuration

#37

I'm a long time vim user and my brain is wired to reach for the keyboard shortcuts in vimdiff to jump from diff to diff. Also, I really love diffing entire trees in one vim session using the DirDiff plugin ( https://github.com/will133/vim-dirdiff ). Here's how I wire it into my .gitconfig, which gets me the alias "git dirdiff": [difftool "default-difftool"] cmd = gvim -f '+next' '+execute \"DirDiff\" argv(0) argv(1)'…

The last section should be:

  [alias]
    dirdiff = difftool --dir-diff

Re: Better Git configuration

#38

I want to also recommend the following: git config --global stash.showPatch true: A recent addition to git which defaults the -p flag to `git stash show`; meaning `git stash show` shows the diff from that stash (should really be default...) git config --global rebase.autostash true: will automatically stash and unstash the working directory before and after rebases. This makes it possible to rebase with changes in th…

Other settings I appreciate:

    rebase.autoSquash true
When committing you can specify --squash= or --fixup=, `git rebase -i --autosquash` will then automatically move and mark the relevant commits in your rebase queue. Setting autosquash into your config enables it by default for all interactive rebases.

    user.useConfigOnly true
that's really convenient when you routinely use multiple identities on the same machine (e.g. personal and work): by default if you haven't configured an identity locally git will fallback to global, and then to guessing based on your current user and machine.

useConfigOnly mandates an explicit configuration, then you can just remove any global user or email, and git will require the correct configuration of any local repository before allowing commits.

    alias.original "!git show $(cat .git/rebase-apply/original-commit)"
when performing a rebase (interactive or not) it can be difficult to remember what the original intent of a specific commit is when it's mixed with conflict markers. This shows the original commit being rebased.

    alias.git "!git"
I regularly type "git", go do something else, remember what I wanted to do and type "git ". This makes "git git git git show" work instead of barfing.

Finally

    merge.tool 
Will automatically use the specified tool when invoking "git mergetool", if you like external utilities to perform merges or conflict resolution (e.g. emerge, kdiff3, araxis, vimdiff3, meld, etc… the list of builtin tool support is accessible via "git mergetool --tool-help")

Re: Better Git configuration

#40

I have a ridiculous "vim style" alias setup: https://github.com/myfreeweb/dotfiles/blob/4eb052cc54f9edcc8... So I can just e.g. type "g ws" to tell [g]it to give me the [w]orking tree [s]tatus. Seeing people actually type "git status" is just painful.

Me too, though I have them setup on shell rather than .gitconfig. Saves that one space after 'g' :)

The ones I find myself using most are 'gru' for git remote update, and 'gka' for "gitk --all -500 &". (The -500 is there to prevent my laptop dying when I run gitk with --all on the Linux kernel repo without second thought...)

Post reply on HN