Re: [git-users] Git rebase for cleanup, after pushing
Then if I merge my branch into the master branch, all that becomes part of the mainline of the code. Do you *need* to merge into the master branch to build your code? If possible, a much better way to do this would be to push the work-in-progress branch to the remote, build and test it on the server, perform any code review, then clean up the work-in-progress branch with an interactive rebase, merge it into master, and push it to the central repository. If you're using a central workflow and your entire team is pulling from the same master branch on a central repository, I would steer clear of rebasing it. Even if you need to build remotely, you should still be able to follow the standard Git workflow: develop in a dedicated feature branch, then merge into the master branch when the changes are ready to be published. Let me know if you have any questions. Ryan http://rypress.com/tutorials/git/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reset branch to master after merge
Paul, It sounds like you have one of two options: 1) Use the topic branch as a short-lived branch that just serves as an isolated environment for you to do some work on a particular feature. This means you would delete it as soon as you merge it into master, because that feature is done, at least for the time being. When you want to start work on it again, create a new topic branch for it, and repeat. 2) Use the topic branch as a long-running feature branch. If you were to do this, you should *not* merge it into master until it's completely done. This means the topic branch would co-exist with the master branch as long as you're still working on it. If you need to pull in updates from master, then you would either a) rebase the topic branch onto master or b) merge master into the topic branch (but *not* the other way around). Either way, you should pick one or the other. You typically shouldn't have a long-running feature branch that you continuously merge into master. As you've discovered, this makes for a lot of superfluous merge commits. We have a number of developers making lots of changes and our git repo is REALLY complicated That sounds...not good. You should generally be able to make sense of your git repository. If you have so many branches and cross-merges laying around that you can't understand your history, you probably need to enforce some integration rules about which branches can get merged into which other branches and when they're allowed to do this. Have you read through http://nvie.com/posts/a-successful-git-branching-model/? It might help you keep things organized. This is another option if you need something a little more flexible: http://scottchacon.com/2011/08/31/github-flow.html. Hope that helps. Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reset branch to master after merge
Yea, that last bit is a bit outside the norm, and yes, I'm saying that you should just delete it and recreate it later on. It basically has the same effect as resetting it to master, but it's less hassle and you don't have an extra topic branch laying around. What I was getting at was that this is really a mentality issue. You shouldn't think of what you're doing as continuing the feature. Once you merge it into master, that feature should be considered done, and any subsequent work should be considered a new feature--hence the new topic branch. This mental model should help keep things a little more organized. Ryan On Mar 11, 2013 12:23 PM, Paul Smith p...@mad-scientist.net wrote: On Mon, 2013-03-11 at 10:54 -0500, Ryan Hodson wrote: 1) Use the topic branch as a short-lived branch that just serves as an isolated environment for you to do some work on a particular feature. This means you would delete it as soon as you merge it into master, because that feature is done, at least for the time being. When you want to start work on it again, create a new topic branch for it, and repeat. 2) Use the topic branch as a long-running feature branch. If you were to do this, you should *not* merge it into master until it's completely done. This means the topic branch would co-exist with the master branch as long as you're still working on it. If you need to pull in updates from master, then you would either a) rebase the topic branch onto master or b) merge master into the topic branch (but *not* the other way around). I do #2... I work and merge from master periodically, then when I'm ready to deliver I merge my topic branch back to master and I'm off doing other things. But then after a while I often pick back up the branch to implement further features etc. It's this last bit that seems outside the norm... but I do it fairly often. So your opinion is that it's better to delete the branch after I merge, then recreate it later, rather than trying to force it to point to the master post-merge commit so I can ff-merge it later? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: git: Command not found.
PID TT STAT TIME COMMAND 28206 s000 S 0:00.02 -tcsh I confess I don't know what this means. That means you're using tcsh as your shell, which doesn't use the `export` command. Try the following: set PATH = ($PATH /usr/local/git/bin) That should (hopefully) solve your problem. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: git: Command not found.
I'm assuming the problem is the space/colon? Agh. Yea, my bad. Use a colon, not a space. *That* should solve your problem. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git: Command not found.
I have a clone of a local repository on my computer, and when I try to issue any git command from Terminal I get this git: Command not found.. That seems to indicate that git is not in the directory containing the clone, but it is. Actually, this is indicating that the git program can't be found on your computer. It sounds like you have in fact installed Git, so this probably means you haven't added it to your PATH environment variable. Try running the following in your Terminal: export PATH=/usr/local/git/bin:$PATH Then try running your git command again. You'll probably want to add this like to your ~/.bash_profile so you don't have to worry about doing it every time you need the Git command line. Hope that helps, Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: git subtree workflow
Hi Ben, To expand on Gergely's reply a bit, it sounds like what you're looking for is `git submodule`, not `git subtree`. Submodules were designed to solve exactly the problem you're facing. Each submodule is essentially its own independent Git repository. If you have RepoA that relies on RepoB, you would add RepoB as a submodule to RepoA. Then you can pull in upstream commits from RepoB as you would with a normal Git workflow and access them from RepoA. There are a few extra `git submodule` commands you would need to learn to keep things in sync. If I have GitHub host both monolithic and splitted out repos, it seems unclear as to how I keep those repos in sync and make sure all the developers in our company push their changes to both repos. This sounds like a dangerous idea. I would use submodules instead. Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: git subtree workflow
Ben, That second article is a bit preachy. The `git submodule` command exists for a reason, and I would trust it over any of the 3rd-party alternatives. That said, it can be a bit finicky to work with at times. The key to remember is that the parent project always points to a *snapshot* (i.e., a commit) of the submodule repository, not a branch. This has a couple of potentially annoying side effects: 1. Upstream commits from the submodule will not automatically be reflected in the parent repository. You have to manually go in and update the commit reference in the parent project. However, the advantage of this behavior is that you can check out or revert to a previous commit in the parent project and get its *exact* state, which is not possible if each commit references a *branch* in the submodule. 2. As noted in that second article, the submodule will typically be in a detached head state, which means you need to be careful about committing changes directly in a submodule (this is not a problem if you are only working on the submodule repos in isolation and using `git submodule` to pull upstream changes into the parent project). The official docs cover all of this in much more detail. Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git wont pull
Have you checked your internet connection? On Feb 25, 2013 2:47 PM, Matt Snow ctsgm...@gmail.com wrote: For some unknown reason whenever I do a git pull, it just hangs. Nothing happens. I have tried to remove all the files, do a git init, then try to git pull again but no luck. I am at a loss for what happened or any ideas how to fix it. Anyone care to help a frustrated gitter? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Free Git Book
Hi Daniel, Thanks! I'm glad you found it helpful. I'm planning on doing an organized translation effort down the road. Can I contact you about an official translation in the future? In the meantime, I would like to keep all of my content on RyPress.com, so I have to respectfully decline your request. Thanks for understanding! Ryan On Feb 24, 2013 9:39 AM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Hello, Ryan. This is great :) The explanation is quite easy to follow and it explains the concept of git correctly. Can I translate this into Korean language and open that to public? If you are ok, I want to translate this into Korean and share it on Internet. Thanks in advance. Daniel Juyung Seo (SeoZ) On Tuesday, February 19, 2013 1:33:41 AM UTC+9, Ryan Hodson wrote: Thanks Alex, I really appreciate that :) Let me know if you have any suggestions. Ryan On Feb 18, 2013 5:06 AM, Alex Lewis alex.l...@gmail.com wrote: Hi Ryan, Your Git Tutorial has been well and truly cemented into my bookmarks. I'm often recommending it to others as it has proven to be an excellent resource. Thank you!! Cheers, Alex On Thursday, 10 January 2013 00:03:40 UTC, Ryan Hodson wrote: Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/**g**it/index.htmlhttp://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Free Git Book
Thanks Alex, I really appreciate that :) Let me know if you have any suggestions. Ryan On Feb 18, 2013 5:06 AM, Alex Lewis alex.lewis...@gmail.com wrote: Hi Ryan, Your Git Tutorial has been well and truly cemented into my bookmarks. I'm often recommending it to others as it has proven to be an excellent resource. Thank you!! Cheers, Alex On Thursday, 10 January 2013 00:03:40 UTC, Ryan Hodson wrote: Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/**git/index.htmlhttp://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Free Git Book
Thanks! I'm glad it was helpful :) On Feb 17, 2013 7:56 AM, Small Fitz smallf...@gmail.com wrote: It's an excellent book ! Thank you very much ! Le jeudi 10 janvier 2013 01:03:40 UTC+1, Ryan Hodson a écrit : Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/**git/index.htmlhttp://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Free Git Book
Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan --
Re: [git-users] Free Git Book
There is a mention of a ebook now being free of charge. Admitting total laziness, it would be great to have a link to the amazon store now free ebook... unless I misunderstood. Sorry, I'm no longer maintaining the Kindle version, but the entire book is available via the link in the original email. Thanks Ryan. The book is worth reading. :) Thanks Iñigo, I appreciate that :) Ryan --
Re: [git-users] Re: Free Git Book
Thanks Thomas. I actually already did that :). I'll see what I can do about an ebook version. On Jan 10, 2013 1:43 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: I've also suggested they add the book to the external resources list on git-scm.com http://git-scm.com/documentation/external-links: https://github.com/github/gitscm-next/pull/235 -- --
Re: [git-users] Re: Free Git Book
Lol. Thanks for the thought though. On Jan 10, 2013 1:45 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: Uh, never mind, I saw you beat me to it :) On Thursday, January 10, 2013 8:43:57 AM UTC+1, Thomas Ferris Nicolaisen wrote: I've also suggested they add the book to the external resources list on git-scm.com http://git-scm.com/documentation/external-links: https://github.**com/github/gitscm-next/pull/**235https://github.com/github/gitscm-next/pull/235 -- --
Re: [git-users] Re: securing data in a non-local repository
You may also want to look at atlassian.com if you're doing enterprise work. They specialize in behind-the-firewall solutions. On Dec 12, 2012 7:47 AM, Serge Matveenko se...@matveenko.ru wrote: On Wed, Dec 12, 2012 at 5:27 PM, John McKown john.archie.mck...@gmail.com wrote: Thanks. I had forgotten that encrypting data tends to randomize it and so it wouldn't compress very well. What I was thinking was of was GitHub's private repositories perhaps containing company proprietary software. It might be attractive to a startup which recruits non-local talent and does its work via the Internet rather than in an office building. In that case, my paranoia would kick in about the possibility of GitHub being hacked and my source stolen or compromised. I guess in this case, it would be wise for the startup to run a GitHub Enterprise virtual server on its own equipment. Or, like I do, have a git subdirectory on a machine which contains the various repositories and is accessible only via SSH. I.e. keep it in house with external developers having an SSH connection to the git server. You may be interested in using gitolite https://github.com/sitaramc/gitolite to host your repositories in house. The setup is easy and you will get many features that github has. -- Serge Matveenko mailto: se...@matveenko.ru github: http://lnkfy.com/1 linkedin: http://lnkfy.com/S -- --
Re: [git-users] How to list a directory content with Git or GitHub
git status would also do the trick. On Dec 8, 2012 10:55 AM, Philip Oakley philipoak...@iee.org wrote: ** git-ls-files - Show information about files in the index and the working tree (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* - Original Message - *From:* Fanta f.g.fa...@gmail.com *To:* git-users@googlegroups.com *Sent:* Saturday, December 08, 2012 4:03 PM *Subject:* [git-users] How to list a directory content with Git or GitHub Hello. How can I list the content of a directory in a local repository, telling apart files and directories that are under GIT configuration from those that are not? I am using Git and GitHub under MS Windows.Thanks! -- Philip -- --
Re: [git-users] How to list a directory content with Git or GitHub
Try git ls-files (no hyphen after the git command). On Dec 8, 2012 3:00 PM, Fanta f.g.fa...@gmail.com wrote: Thank you Ryan. git status only lists files the are untracked (and not listed in .gitignore) or to be committed. -- --
Re: [git-users] curiosity: why are files in .git/objects marked writable?
Kudos for the complete answer. Very insightful. On Dec 7, 2012 11:20 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 7 Dec 2012 08:48:41 -0800 (PST) John McKown john.archie.mck...@gmail.com wrote: That's the question. Or I really am not understanding what all is in there. But what I understand (if correct) is that the files in .git/objects are such that the subdirectory name is the first two hex characters of the SHA1SUM value of the contents, the file name within that subdirectory are the last 38 characters. And the contents of the file are a compressed version of the data. That's just an implementation detail which does not really affect the way Git works from the standpoint of its user. Also note that when the number of objects and commits grow, Git starts to organise them into the so-called pack files, so the number of those loose objects is not usually high. The same applies to references (branches and tags) which might get archived as well, when Git thinks they should be. As with packed object, this is transparent to the users and higher-level Git tools. In any case, once the file is created, the contents are never updated. In fact, if they were updated, git would likely be royally messed up. If the original file is modified, a new SHA1SUM file is generated. So, why doesn't git just mark the files as read only? First, there's the question of filesystem semantics. That read only attribute found on FATs (or maybe earlier filesystems) actually compensated for complete lack of any access controls (and user identities in the OS, for that matter) which are typically used novadays to restrict access to files. These attributes were carried to NTFS to provide backward compatibility. Outside of FAT and NTFS, I know that extN filesystems implemented by the Linux kernel support a set of attributes as well, but this set is different from Microsoft filesystems. extN supports the so-called immutable attribute which is sort-of equivalent to read only. Note that the standard C library which defines those lowest-level file-manipulation functions like open(2), do not mention file attributes. What I try to convey, is that there's no such thing as a universally available and agreed-upon convention about supporting read only attributes on files; hence to implement it, Git would have to maintain a list of known filesystems and be able to use filesystem-specific methods to manipulate attributes on those files. But now consider that if Git (running under the same credentials as you, the logged in user) is able to set that read only attribute on a file, you still have full privileges to unset it, hence this kind of protecting would be just a single level of fool-proofing and nothing more. Say, imagine a standard Windows Explorer dialog for deleting files -- if it would encounter a file marked as read only, it would ask you if you really sure to delete that file, and I don't think I have to assure you that most users just click through all those nagging dialogs which get in thir way. So really, implementing this sort of protection is too much trouble for too little reason. The primary way to protect your Git repository is to have backups. Naturally, with Git (as with any DVCS), this could just amount to periodically mirroring your changes to some offsite repository. Naturally, if several developers are working on a project, each having their own private clone on their own hardware, the project becomes really hard to kill completely as if someone thrashes their repository, they could just re-clone it from someone else's copy. If you're worried about what happens if someone/something deletes/modifies a Git object and this goes unnoticed, then it's not that bad either: 1) When doing certain operations, Git does re-check hashes of objects it manipulates. 2) Git has the `git fsck` program, which is able to perform thorough analysis of a Git repository, so if you have any doubts, you could just run it on a suspicious repository. -- --
Re: [git-users] Re: abuse of git / commit ?
I'm glad the squash merge is what you were looking for. It's true that you should avoid rebasing public history, but if you're not working on a team, you can rebase to your heart's content without worrying about messing anybody up. With your workflow, it sounds like interactive rebasing might be very helpful. It lets you condense all those small commits into a meaningful history. Cheers, Ryan On Dec 4, 2012 8:29 AM, John McKown john.archie.mck...@gmail.com wrote: Thanks for the thoughts. I am not part of a team in this particular instance. And I am basically just learning git and perhaps how I, personally, want to use it for some of my own purposes. I tend to do a commit after each successful edit/compile/test cycle. Mainly so that I can change my mind easily. A sign of ad hoc design on my part, which I agree is not optimal or even very good/wise. The rebase seems like an interesting idea as well. The two books discourage it. But they are talking about rebasing a published repository which some one else may have cloned. I tested the git merge --squash and it is just what I was looking for in my original scenario. On Monday, December 3, 2012 6:54:15 PM UTC-6, John McKown wrote: I've been reading Version Control using git (already finish Pro Git). One thing the author said was that git really encourages developers to commit frequently. Mainly because they have an entire (at the time) copy of the repository. So there's not a lot of overhead of sending files across the Internet (or Intranet). This sounds good to me. Basically, what I like to do is: until satisified do; edit; compile; test; commit; done I do this for every program. Once a change is complete, i.e. all programs and files modified, and tested, I then do a git push to the repository. But it occurs to me that this is a lot of commits for what is logically a single change. Would it be better to implement a single change as a single, well documented, commit? If so, then how to eliminate all those commits? What I've read says to do something like create a new branch; do all your development and commits in that branch; then do a git checkout back to master and do a single git merge of the new branch. The way that I read the doc, what happens is that your branch remains and the master branch commit has two parents. One from master the other from the change branch. What I was thinking would be better would be to completely remove all vestiges of the change branch. I think this can be done by abusing git as follows: git tag starting git branch changes until satisfied; do edit; compile; test; commit; done #use the changes branch for all development git merge --no-commit changes git branch -d changes git reset --soft starting git tag -d starting git commit #put in a single commit with very detailed documentation git push #push the change up to the origin Does this seem reasonable? Or am I entirely out of the ball park? -- --
Re: [git-users] Pushing files into a subtree
Dale, If you're not looking for a submodule, you can just move the tracked files into a subdirectory with 'mv' or through your file browser. Then run 'git add .' in the project root and Git will figure out the file renames on its own. The 'git mv' command can be used to the same effect. Hope that helps. Ryan On Nov 28, 2012 1:13 PM, Dale R. Worley wor...@alum.mit.edu wrote: I am just beginning to use git. I've read the O'Reilly book (by Loeliger and McCullough), and (unexpectedly) it didn't give me a clear view of some of the messier aspects of git. So as a first question, I'd like to know if anyone knows of an exposition that gives a clear and accurate description of the logical structure of git repositories and git operations. As a second question, consider a situation I am now in. I've been using git to maintain a repository of a directory. I now want to start tracking all the files in the *parent* of that directory, continuing the history of all the files that are now in the repository. I know how to use Subversion to do this, with one or two commands I can move the repository files into a subordinate directory in the repository. But what is the correct way to do this in git? Thanks, Dale -- --
Re: [git-users] about git commit -m add the more than two lines log
I'm thinking maybe OP wants to run `git commit -m` from a script or automate the messages in some fashion. There might be a better way, but the following will work: echo -e Line One\nLine Two | git commit -a -F - The `-e` option tells `echo` to treat `\n` as an escape sequence. The echoed output is piped to `git commit`, and the `-F -` option tells Git to read the message from stdin. Hope that's what you're looking for. - Ryan On Fri, Oct 12, 2012 at 12:16 AM, Gadget/Steve gadgetst...@hotmail.com wrote: On 12/10/2012 3:58 AM, lei yang wrote: I know git commit -m somethingsomething will give the git info in the git log but I don't know how to write some thing with more than two line some thing like something something something something something something in the git log One solution is not to specify the -m something.. on the command line - the commit process will then start vi, or whatever you have set as your editor, for you to type in as long a commit comment as you like. Gadget/Steve -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] push error
I believe the 403 error is a GitHub permissions issue. I don't think you can push over https without some special setup. The easy solution is to use SSH instead. Try changing your remote to: ssh:// github.com/ashutoshverma/drunken-ironman.git On Aug 29, 2012 4:11 AM, Michael Wang ylzc...@gmail.com wrote: No, this time is another error fatal: remote origin already exists. you have already add that remote. No need and you cannot add it again. just run *sudo git push -u origin master * 2012/8/29 ashutosh verma ashutove...@gmail.com It is still giving the same error: ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ touch README ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ echo 'Hello world' README ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git add README [sudo] password for ashu: ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git commit -m first commit [master (root-commit) 1edf97b] first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 README ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git remote add origin https://github.com/ashutoshverma/drunken-ironman.git fatal: remote origin already exists. ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git push -u origin master error: The requested URL returned error: 403 while accessing https://github.com/ashutoshverma/drunken-ironman.git/info/refs fatal: HTTP request failed On Wed, Aug 29, 2012 at 2:22 PM, Michael Wang ylzc...@gmail.com wrote: the git commit has warned you nothing to commit (create/copy files and use git add to track) and if you try git log, you will get someting like： fatal: bad default revision 'HEAD' git cannot commit an empty tree, so you should add at least one file for git to track, try the following commands: touch README echo 'Hello world' README git add README git commit -m first commit then try to push again. 2012/8/29 ashu ashutove...@gmail.com What can be the reason of this error ? ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git init [sudo] password for ashu: Initialized empty Git repository in /home/ashu/Documents/git-dir/git1/.git/ ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ git commit -m first commit fatal: Unable to create '/home/ashu/Documents/git-dir/git1/.git/index.lock': Permission denied ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git commit -m first commit # On branch master # # Initial commit # nothing to commit (create/copy files and use git add to track) ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git remote add origin https://github.com/ashutoshverma/drunken-ironman.git *ashu@ashu-G41MT-S2P:~/Documents/git-dir/git1$ sudo git push -u origin master error: The requested URL returned error: 403 while accessing https://github.com/ashutoshverma/drunken-ironman.git/info/refs fatal: HTTP request failed * -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/rE74k7ry258J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Michael Wang Unix/Linux Admin | Software Configuration Management MSN: ylzc...@gmail.com Blog: http://loveky2012.blogspot.com 命由己作，福由心生；积善之家，必有余庆； -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Michael Wang Unix/Linux Admin | Software Configuration Management MSN: ylzc...@gmail.com Blog: http://loveky2012.blogspot.com 命由己作，福由心生；积善之家，必有余庆； -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this
Re: [git-users] how to push changes to .git/info/exclude
The .git folder is not under revision control, so you won't be able to add the exclude file to your project, let alone push it to the remote. If you need an ignore file for the entire project, you should put a. gitignore file in the working directory and commit it like any other file. On Aug 29, 2012 2:12 PM, git newbie technewbi...@gmail.com wrote: Hi, We have a remote repository that we clone from. I updated my local repository's .git/info/exclude file, but I can't seem to be able to get this pushed up to the remote repository. How do I do this? Thank you very much -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/FLuyaKV_35YJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] git branching
Hi there. The parent branch will always be the *current* branch, so all you need to do is: git checkout develop git branch some-feature git checkout some-feature Or, you can use the -b shortcut to save a step: git checkout develop git checkout -b some-feature In either case, some-feature will have develop as its parent. Hope that's what you were looking for. -- Ryan On Aug 28, 2012 2:44 PM, git newbie technewbi...@gmail.com wrote: For a more complicated development environment where there is a master branch, a devel branch off of master, and feature branches off of devel, how do you create a feature branch so that it's parent is the devel branch and not the master branch? Thanks! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/Yc8IQGZbgZ8J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] git branching
Lol. Yea, that's a good point. On Aug 28, 2012 3:11 PM, Adam Prescott a...@aprescott.com wrote: On Aug 28, 2012 8:51 PM, Ryan Hodson hodson.r...@gmail.com wrote: Or, you can use the -b shortcut to save a step: git checkout develop git checkout -b some-feature If you're going to use a shortcut, use a shortcut! git checkout -b some-feature develop -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: getting changes since a specified commit
Kevin, Try running the following in the first site's repository: git format-patch since where since is the ID of the commit common to both sites. This should generate a patch file in the first site's working directory that contain any new commits. Copy this file (or files, for multiple commits) into the second site's working directory and run the following: git am some-file.patch but make sure to change the filename to your actual patch file. This will recreate the commit in the new repository. Hope that helps, -- Ryan On Jan 27, 1:08 pm, Chris Stone nightshade1...@gmail.com wrote: Sounds like you want to create a patch file. Command would be git diff. I have not worked with patch files much beyond applying them. Can any one else fill in the details? On Jan 27, 2012 11:53 AM, Kevin Wilson wkev...@gmail.com wrote: Hi, I have a git tree on one site, and a copy of it (from two weeks ago) on a second site. I cannot access the first site from the second one. The git tree on one site had some commits since I made a backup of it for the second site. I can of course backup the first tree and override the second one. I of course know which is the commit which is the latest when I made the backup (by git log). Is there a way that I can reproduce only the commits since that last commit in the first site and copy only them, and apply them, for the second site? rgs, Kevin -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
