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…
Better Git configuration
31–40 of 66 posts
Re: Better Git configuration
#32Earlier 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…
Re: Better Git configuration
#33Earlier 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…
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
#34I'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
git push backup my-new-branchRe: Better Git configuration
#35I'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…
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
#36Earlier 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…
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
#37I'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)'…
[alias]
dirdiff = difftool --dir-diffRe: Better Git configuration
#38I 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…
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
#39So 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.
Re: Better Git configuration
#40I 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.
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...)