{"thread":{"id":"1173","subject":"git and commiting","startedAt":"2005-07-08T14:07:34Z","lastAt":"2005-07-08T20:10:25Z","messageCount":2,"participants":["Mateusz Berezecki","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5823","messageId":"42CE88A6.5080502@gmail.com","threadId":"1173","inReplyTo":null,"subject":"git and commiting","fromName":"Mateusz Berezecki","fromEmail":"mateuszb@gmail.com","sentAt":"2005-07-08T14:07:34Z","receivedAt":"2005-07-08T14:07:34Z","isPatch":false,"sender":{"key":"mateuszb@gmail.com","avatar":null},"body":"Hi list readers,\n\nHow to commit and check-in changes done to the checked-out source code?\nThe \"git commit\" command seems to only commit the changes locally\nwithout pushing them via rsync.\nIs there any way I can push commits via rsync? Am I missing the point\nand git commit is not enough?\n\nplease CC me with the answer as I am not subscribed to the list.\n\n\nregards\n/mb\n"},{"id":"5833","messageId":"Pine.LNX.4.58.0507081254190.17536@g5.osdl.org","threadId":"1173","inReplyTo":"42CE88A6.5080502@gmail.com","subject":"Re: git and commiting","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T20:10:25Z","receivedAt":"2005-07-08T20:10:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 8 Jul 2005, Mateusz Berezecki wrote:\n> \n> How to commit and check-in changes done to the checked-out source code?\n> The \"git commit\" command seems to only commit the changes locally\n> without pushing them via rsync.\n> Is there any way I can push commits via rsync? Am I missing the point\n> and git commit is not enough?\n\n\"git commit\" is \"enough\" in the sense that it does indeed commit \neverything to the local tree, and often that is enough.\n\nBut what you're asking for is to _export_ the changes to others. And \nthat's a different issue.\n\nThere's actually two different parts to exporting your changes:\n\n - making your existing tree (or branch) available as-is on some public \n   place.\n\n   This is done with\n\n\tgit-send-pack <destination> [branches]\n\n   where the destination can either be a locally writable tree, or it's a \n   ssh-format remote tree (ie you need to have some place where you can \n   log into with ssh).\n\n   For example, when I export my kernel changes, I do so with\n\n\tgit-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6\n\n   which I have in a \"push-all\" script in my kernel directory (so that \n   regardless of what project I'm working on, I can just do \"./push-all\" \n   to push it to the repositories I have as the public destinations).\n\n - other people will _pull_ the changes (ie you don't push them to others: \n   you publicize, and then it's up to others to decide whether they want \n   to pull your tree).\n\nNow, there's one special case, namely when you use a shared \"CVS-line\" \nrepository that multiple people push to. If you do that, then you are both \npusher and puller, and exactly like with CVS, you'll have to be up-to-date \nin order to push. So before you do the git-send-pack, you should first see \nif you need to update with work that other people have done in the shared \nrepository, ie it might look something like this:\n\n\tgit pull repo.work.com:/project/work.git branch\n\tgit-send-pack repo.work.com:/project/work.git branch\n\nwhere the first command makes sure that you're up-to-date (and as with \n\"cvs update\", you may need to fix up any merge issues), and the second \ncommand then pushes back the merge results.\n\nNOTE NOTE NOTE! As it stands, git-send-pack is really geared towards _my_\nkind of usage, ie it is geared towards sending to a public repository that\ndoesn't have other people pushing to it (ie it's \"public for reading\", but\nit's \"private for writing\"). That's the way _I_ work, but it's not the \nway you'd work in a more CVS-like environment with multiple people that \npush to a common repository.\n\nWhat this means is that \"git-send-pack\" is a bit too eager to try to make\nthe other end look exactly like _your_ end. It's a bit too easy to re-set\na branch that somebody else may have changed to what _you_ happen to have\nin your tree, so be careful. The data doesn't go away, of course, but if\nyou reset a branch the old contents aren't reachable any more, so it might\nas well be considered gone (you can use \"git-fsck-cache\" to find the\nnon-reachable commits and re-name them to some new branch, but the point\nis that it's real work).\n\nI'll try to make git-send-pack much more careful about setting branches to \nnew values.\n\n\t\tLinus\n"}]}