| |||||||||||||
|
| |||||||||||||
Simplified porcelains?Simplified porcelains?Posted Aug 5, 2008 15:05 UTC (Tue) by alex (subscriber, #1355)In reply to: Simplified porcelains? by epa Parent article: Git Magic
In reality the day to day usage of git comes down to the same 5-6 commands. The rest is just plumbing which is useful in a very small set of circumstances. However the reason Cogitco fell by the wayside is you could do all the porcelain type actions with the core git commands. I believe there was talk about removing a bunch of the git-* commands from the search path (they are just symlinks anyway). I'm not sure where that has gotten too.
(Log in to post comments)
Simplified porcelains? Posted Aug 5, 2008 15:10 UTC (Tue) by epa (subscriber, #39769) [Link] The thing that worries me from the article is that 'git checkout HEAD' (and perhaps other commands) lose any uncommitted changes. With svn, I know that it is always safe to update to the latest version or to any version, since it will merge the changes with what's in my working copy. It's clear that git never permanently loses a commit, unless you run the prune command, but I would want the revision control system to take just as much care with the contents of my working directory, even if not committed yet. What about Easy Git, is that still going?
Simplified porcelains? Posted Aug 5, 2008 15:38 UTC (Tue) by nix (subscriber, #2304) [Link]
'git checkout HEAD' fails unless your tree is clean. 'git reset --hard HEAD' will throw your
changes away, but that's fairly difficult to type unless you know what you're doing. ('git
stash' is worth looking at if you're often trying to move around with uncommitted changes in
your tree.)
Simplified porcelains? Posted Aug 5, 2008 17:19 UTC (Tue) by iabervon (subscriber, #722) [Link] "git checkout HEAD" doesn't do anything (expect possibly display a bit of useful information). It's "git checkout HEAD ." (note the filename "." at the end) that will discard uncommitted changes, because (like in CVS), it's a request to cause the working directory to match "HEAD" with respect to the path ".". But I think that section shouldn't really be in that document; it's talking about a non-recommended method for keeping two computers in sync by confusing one of them and then intentionally losing the false changes that the computer thinks it has. Git is actually extremely careful about uncommitted changes. The only ways to lose uncommitted changes with git are to either ask to discard them (with "checkout <filename>" or "reset") or ask to have working-directory files modified or removed (e.g., "apply" or "rm"). By default, git won't even overwrite modified working directory files with merge results like other version control systems will.
Simplified porcelains? Posted Aug 5, 2008 17:40 UTC (Tue) by newren (subscriber, #5160) [Link] Yes, EasyGit (eg) is still going. I've used it on a daily basis for nearly the last 6 months, and many others have told me it's helped them in getting started with git. Just download eg and fire off eg help to get started, or look at the detailed comparison to subversion. EasyGit basically provides beginner-oriented built-in documentation, checks for and warns about common gotchas with git, and layers things in an orderly fashion. You can switch back and forth between eg and normal git commands too; in fact, there are --translate and --debug options designed to show you what git commands eg is running behind the scenes (in addition to clearly documented differences between eg and git commands, where such differences exist). I've been a little slow at responding at times, and haven't published some updates and commentary I've been meaning too, but eg is perfectly usable for daily work. I have too many users to abandon it...
Simplified porcelains? Posted Aug 6, 2008 3:47 UTC (Wed) by benlynn (guest, #53270) [Link] My bad: in the old days, git was less forgiving. As others have noted, nowadays a checkout fails on unclean trees. That is, unless you specify particular paths in which case only those particular paths are overwritten. I've updated the guide to reflect this.
Simplified porcelains? Posted Aug 5, 2008 15:14 UTC (Tue) by Sutoka (guest, #43890) [Link] > "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.
/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
|
|
||||||||||||