| |||||||||||||
|
| |||||||||||||
Simplified porcelains?Simplified porcelains?Posted Aug 5, 2008 15:14 UTC (Tue) by Sutoka (guest, #43890)In reply to: Simplified porcelains? by alex Parent article: Git Magic
> "In reality the day to day usage of git comes down to the same 5-6 commands." This is definitely true for me. The day-to-day git commands I use are: git diff (incredibly useful, use it constantly) git commit -a (automatically commit only the changed files that are already in the repo) git push (push my commits to the remote server) This are really all the commands I use frequently. Occasionally I'll use 'git add <filename' if I add a new file I wanted monitored, 'git init' is useful when you want to create a new repo in a folder (not something you'll need very often probably), and off the top of my head I don't remember the command to switch branches (I haven't gotten to the point where I use them at all regularly). Git really is quite simple if you have simple needs like me, and it's also quite nice because theres several hosts that'll provide free hosting for repos without having to do lots of effort to setup an account then get the project approved.
(Log in to post comments)
/etc is a good candidate Posted Aug 5, 2008 15:23 UTC (Tue) by alex (subscriber, #1355) [Link] Every time I go into a sub directory in /etc to edit a file for config for the first time the first thing I do is: git-init-db; git-add .; git-commit -m "Initial Version" I'd tried various approaches with CVS before but it quickly turned ugly. Now I can easily roll back changes, start again or fork of in a new direction without loosing track of what I did and why.
Good idea Posted Aug 5, 2008 15:30 UTC (Tue) by dmarti (subscriber, #11625) [Link] Good idea, but have a look at etckeeper. It will also automatically track any changes that the package manager makes in /etc.
for now I'll hand roll Posted Aug 5, 2008 16:48 UTC (Tue) by alex (subscriber, #1355) [Link] For now I'll hand roll. I started with my whole /etc in git, no I tend to have mini-repos for each bit of /etc so it's not tied to the rest of the system. Hence I can pull my apache or exim config without the mess of the rest of /etc involved :-)
/etc is a good candidate Posted Aug 5, 2008 17:19 UTC (Tue) by mikachu (guest, #5333) [Link] You should be using "git init; git add .; git commit -m 'Initial Version'", since init-db has been deprecated since before i can remember. git-* have been since 1.5, and will not be available by default in 1.6.0.
/etc is a good candidate Posted Aug 6, 2008 6:32 UTC (Wed) by alex (subscriber, #1355) [Link] Well all the servers which I muck around with the config on run Debian which is a little behind the bleeding git edge ;-)
/etc is a good candidate Posted Aug 6, 2008 7:51 UTC (Wed) by nix (subscriber, #2304) [Link] Storing /etc in git seems like a bad idea to me, as git doesn't preserve permissions (other than the executable bit), ownership information, hard links, or any type of file other than regular files and directories.
/etc is a good candidate Posted Aug 6, 2008 8:44 UTC (Wed) by alex (subscriber, #1355) [Link] I don't store the whole of etc, usually only the bits I need to tweak/configure, e.g. /etc/apache2 or /etc/exim4
/etc is a good candidate Posted Aug 6, 2008 11:07 UTC (Wed) by rleigh (subscriber, #14622) [Link] There are, however, people who want git to be able to do this: [git storage backend for chroots] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477942 This is essentially using git directly as a snapshottable filesystem; cloning the chroot would be effectively a git clone (and/or branch). In this case, file ownership, permissions, special files and empty directories are all features we would like git to store. I have heard there are patches in the works to implement (some of) the above, though I haven't seen them myself. This would also allow /etc to be stored directly in git. Regards, Roger
/etc is a good candidate Posted Aug 6, 2008 16:42 UTC (Wed) by iabervon (subscriber, #722) [Link] Ideally, it should be possible to have a more flexible mapping between the index and the working directory, such that the repository's contents are of the same type as any other repository (and it could be checked out as a description), but, when it's used as an actual chroot, it works directly. For example, it should be possible to work on a chroot image for some other machine without being root on the machine you're working on; this is easy if the image is stored with the "special stuff" as plain files that only translate into device nodes and permissions when in the chroot checkout. (Actually, I suspect that the ideal thing is a fakeroot/git team effort, where git stores what fakeroot stores, not what the actual filesystem stores, and you can check this out as a real chroot image if you're root, or fake it in fakeroot, or as a set of control files and data if you want that.)
/etc is a good candidate Posted Aug 6, 2008 21:33 UTC (Wed) by rickmoen (subscriber, #6943) [Link] nix wrote:Storing /etc in git seems like a bad idea to me, as git doesn't preserve permissions (other than the executable bit), ownership information, hard links, or any type of file other than regular files and directories. etckeeper's author (Joey Hess) was well aware of this; that's why it uses metastore to encode that information transparently, so that git can track it. (etckeeper's integration into Debian/*buntu package management is also a killer advantage, over just checking /etc into an RCS: Changes to /etc resulting from a package operation get checked in automatically.) Rick Moen
/etc is a good candidate Posted Aug 7, 2008 0:25 UTC (Thu) by bronson (subscriber, #4806) [Link] It doesn't use metastore anymore. A certain lwn reader didn't like having a big binary-only file in /etc and sent Joey some patches to replace it with a text file and simple find commands. ~March 17-20, 2008 I like etckeeper. When the bad stuff starts flying, it sure is nice to be able to roll back to a known good config. And the cryptographic integrity makes a nice sanity check.
Simplified porcelains? Posted Aug 5, 2008 17:24 UTC (Tue) by jwb (guest, #15467) [Link] git push only works if your "origin" is somehow magically configured in a dotfile which is very poorly explained deep in the 50th page of the manual. Unless that's been fixed in the last year or so.
Simplified porcelains? Posted Aug 5, 2008 19:10 UTC (Tue) by bronson (subscriber, #4806) [Link] Still not fixed. :/ On the other hand, if you clone a repo, it automatically sets it up so that push with no arguments pushes back to that repo. That way, at least, most people will never need to worry about it.
Simplified porcelains? Posted Aug 5, 2008 20:30 UTC (Tue) by bfields (subscriber, #19510) [Link] git push only works if your "origin" is somehow magically configured in a dotfile Yes, that's true of a plain "git push" with no arguments, though of course you can always just give a url (or the name of a remote). which is very poorly explained deep in the 50th page of the manual. You're talking about this? Actually I'm not sure if it ever explicitly says that "origin" is the default, though it does show how to add a new remote. Any concrete suggestions would be appreciated. I do agree that remotes could be better explained.
Simplified porcelains? Posted Aug 5, 2008 20:36 UTC (Tue) by Sutoka (guest, #43890) [Link] The tutorial I used to learn git was: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.htmlFor a while it vanished from google so I had lost it until just now when I searched for it. To get git push working all I did was just followed the instructions on my Gitorious project page: You can run "git push git@gitorious.org:[project]/mainline.git", or you can setup a remote by doing the following: git remote add origin git@gitorious.org:[project]/mainline.git # to push the master branch to the origin remote we added above: git push origin master # after that you can just do: git push Basically, it was extremely for me easy to setup, it might be harder if you're trying to setup the remote server yourself, but I tried that several times with SVN and CVS and never once got it to work (plus the tutorials I kept finding were having me install apache and a crap load of other services). My only 'problem' with Git is that I didn't really know how to use Vim so I kinda had to learn that on the fly. IMO, Git is extremely easy to learn and takes very little effort to use (definitely more intuitive than Vim :P).
Simplified porcelains? Posted Aug 5, 2008 21:30 UTC (Tue) by bronson (subscriber, #4806) [Link] Git just uses EDITOR. So, for instance, if you wanted to edit your commit message using nano, run "EDITOR=/usr/bin/nano git commit" Or put "setenv EDITOR=/usr/bin/nano" in your .bashrc to make the change permanent.
Editor Posted Aug 6, 2008 6:40 UTC (Wed) by alex (subscriber, #1355) [Link] I find bringing up emacs each commit can be a pain so I tend to just use the -m switch: git-commit -m "My commit message, maybe over serveral lines" filaA fileB
Editor Posted Aug 6, 2008 7:52 UTC (Wed) by nix (subscriber, #2304) [Link] Set your EDITOR to emacsclient and leave an emacs running.
Editor Posted Aug 6, 2008 8:48 UTC (Wed) by alex (subscriber, #1355) [Link] Sadly I have yet to come up with a solution that works well with all my needs. I tend to run at least one emacs per "project" which is long running as well as temporary ones for commits or editing pages. I suspect I just need to think about rules for starting an emacs server in my .emacs. The other problem is running text mode emacs on remote screen sessions. I don't want to switch to another (v)tty when EDITOR gets invoked. I've heard there is a thing called multi-tty but I have yet to investigate it and it's implications. Pointers to pimped up emacsserver examples are welcomed :-)
Editor Posted Aug 6, 2008 9:04 UTC (Wed) by nix (subscriber, #2304) [Link] What I'd suggest is an interactive function bound to some key which does a gnudoit (? is this the Emacs name?) to stop whatever server exists via (server-start t), then does a (server-start) in the current instance. So then you can switch which emacs your emacsclient invocation talks to with a single keystroke. Alternatively you could set `server-name' on the servers and use the --socket-name argument to emacsclient. There are more elaborate methods but these two should work. I'm afraid as an XEmacs user the multi-tty stuff just works for me ;)
Editor Posted Aug 6, 2008 14:54 UTC (Wed) by newren (subscriber, #5160) [Link] You could just put the commit message in a file and use the -F flag. e.g. git commit -F file-with-commit-message
|
|
||||||||||||