using git, create patch with new files
I'm trying, and failing, to create a patch that adds new files to a module. According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false. When I run `git status`, I see something like this: [dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc When I run `git diff`, I see changes to all the modified files, but I do not see the new files. What am I missing? Thanks, -Dave
I am new to git. I have not tried to mass add the files using git add ... For time being, until someone comes with better answer, you can probably use: git add fb.process.inc -a git add fb_tab.js -a Regards, Nitish On Mon, Apr 11, 2011 at 10:46 PM, Dave Cohen <drupal@dave-cohen.com> wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
Nitish, I just get "error: unknown switch `a'" when appending -a. On Monday 11 April 2011 10:28:32 Nitish Kumar wrote:
I am new to git. I have not tried to mass add the files using git add ...
For time being, until someone comes with better answer, you can probably use: git add fb.process.inc -a git add fb_tab.js -a
Regards, Nitish
Hmm... well those instructions are wrong I guess. "git diff" is the diff of changes since the last commit that have *not* been staged. So once you've added a file via "git add", it won't show up anymore when you run "git diff". If you want to see the diff between the last commit and staged files, run "git diff --cached" -- Kyle Mathews Blog: kyle.mathews2000.com/blog Twitter: http://twitter.com/kylemathews On Mon, Apr 11, 2011 at 10:16 AM, Dave Cohen <drupal@dave-cohen.com> wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
If you look at the "Git instructions" tab for the project you're working on I think you'll find more mature instructions for patch creation. When you find a git documentation problem like this, please file an issue at http://drupal.org/project/issues/git_dev My approaches to patch creation: http://randyfay.com/node/97 -Randy On Mon, Apr 11, 2011 at 11:28 AM, Kyle Mathews <mathews.kyle@gmail.com>wrote:
Hmm... well those instructions are wrong I guess.
"git diff" is the diff of changes since the last commit that have *not*been staged. So once you've added a file via "git add", it won't show up anymore when you run "git diff".
If you want to see the diff between the last commit and staged files, run "git diff --cached"
-- Kyle Mathews
Blog: kyle.mathews2000.com/blog Twitter: http://twitter.com/kylemathews
On Mon, Apr 11, 2011 at 10:16 AM, Dave Cohen <drupal@dave-cohen.com>wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
On Monday 11 April 2011 10:40:05 Randy Fay wrote:
If you look at the "Git instructions" tab for the project you're working on I think you'll find more mature instructions for patch creation.
When you find a git documentation problem like this, please file an issue at http://drupal.org/project/issues/git_dev
OK, filed this: http://drupal.org/node/1123948 I didn't report an issue at first cause I figured the problem was on my end. With git there's 3 ways to do anything right, and 8 ways to do anything wrong. I just figured I was doing one of the 8. Thanks for the help, -Dave
On 04/11/2011 12:16 PM, Dave Cohen wrote:
When I run `git diff`, I see changes to all the modified files, but I do not see the new files. Git allows (actually assumes) that a directory might have various degrees of "dirt" in it. Unapplied patches, your half composed manifesto about the importance of not hacking core, etc.
A git diff just compares the changes in the "tracked" files that git has been told to care about. Its a good neighbor basically. To do what you want above, just temporarily tell git to care about your new files with "git add ." or listing them by name and then run "git diff HEAD". These two steps tell git to care about the file then ask whats different. You can of course unstage your files if you dont want to actually commit them using git "git reset HEAD". None of these chanegs actually destroy any data except temporary data in the git index. Your files will all remain intact as you want. A more common use case is to use git commits to track your progress ona feature/bug branch as you go and git diff between two named commits instead. YMMV. -- Michael Favia michael@favish.com tel. 512.669.5650 http://www.favish.com
On Monday 11 April 2011 11:16:12 Michael Favia wrote:
On 04/11/2011 12:16 PM, Dave Cohen wrote:
When I run `git diff`, I see changes to all the modified files, but I do not see the new files. Git allows (actually assumes) that a directory might have various degrees of "dirt" in it. Unapplied patches, your half composed manifesto about the importance of not hacking core, etc.
A git diff just compares the changes in the "tracked" files that git has been told to care about. Its a good neighbor basically.
I suppose if you're a fan of git, you can argue that it is always right. If you're like me, on the other hand, you might expect something to show up in git diff, after you've run git add.
To do what you want above, just temporarily tell git to care about your new files with "git add ." or listing them by name and then run "git diff HEAD".
I find that "git diff HEAD" is wrong because I'm not working on HEAD. Similarly, "git diff origin" does not do the right thing. However "git diff origin/6.x-3.x" appears to get me both the modified files and also the add files! Why doesn't git remember that it's origin is the 6.x-3.x branch? So, to generate a patch, I'm using... git diff --no-prefix origin/6.x-3.x Thanks to all for the suggestions. -Dave
On 04/11/2011 02:53 PM, Dave Cohen wrote:
I suppose if you're a fan of git, you can argue that it is always right.
I'm no more a"fan" of git than i am of drupal. Its a tool that has good value if you know how to use it and can frustrate the hell out of you if you dont.
If you're like me, on the other hand, you might expect something to show up in git diff, after you've run git add. It just has one more layer of intelligence/workflow that allows it/you to ignore changes in your working copy that you don't want to pay attention right now. If you're like me and have a couple things going on at once and want to commit your work in atomic chunks you can find it useful. If not there are git shortcuts for commits to ignore the whole layer.
To do what you want above, just temporarily tell git to care about your new files with "git add ." or listing them by name and then run "git diff HEAD". I find that "git diff HEAD" is wrong because I'm not working on HEAD. Similarly, "git diff origin" does not do the right thing. You find that its wrong or it doesnt work? These are two different things.
HEAD is a special dynamic variable that refers to the most recent commit in the index. It is there so you don't have to type in the whole commits crazy ass SHA name. In that way it works EXACTLY like a named version tag. (fyi HEAD^ equals "next to last commit" so git "diff HEAD^ HEAD" shows you the diff between the last commit and the one before it). You can see what this is by interrogating the HEAD file in .git manually for fun. HEAD isnt a branch name like master or |6.x-3.x. Though i can see the point of confusion if im understanding you correctly. | -- Michael Favia michael@favish.com tel. 512.669.5650 http://www.favish.com
On Monday 11 April 2011 13:09:20 Michael Favia wrote:
I'm no more a"fan" of git than i am of drupal. Its a tool that has good value if you know how to use it and can frustrate the hell out of you if you dont.
Let's just say it frustrates the hell out of me. :)
It just has one more layer of intelligence/workflow that allows it/you to ignore changes in your working copy that you don't want to pay attention right now.
In my case there are modified files, and added files, and I want git to pay attention to both of those groups.
I find that "git diff HEAD" is wrong because I'm not working on HEAD. Similarly, "git diff origin" does not do the right thing. You find that its wrong or it doesnt work? These are two different things.
Wrong for my case, I meant. I thought I tried both "git diff HEAD" and "git diff origin" and both produced a diff with too many changes. But I tried again, and "git diff HEAD" did what I wanted. So I guess I was seeing things for a moment there. git diff origin <--- does the wrong thing, in my case git diff HEAD <--- appears to work git diff origin/6.x-3.x <-- appears to work, in my case (I also add --no-prefix when running git diff, at least when I remember)
HEAD is a special dynamic variable that refers to the most recent commit in the index. It is there so you don't have to type in the whole commits crazy ass SHA name. In that way it works EXACTLY like a named version tag. (fyi HEAD^ equals "next to last commit" so git "diff HEAD^ HEAD" shows you the diff between the last commit and the one before it).
Thanks for explaining that. -Dave
On 04/11/2011 03:32 PM, Dave Cohen wrote:
On Monday 11 April 2011 13:09:20 Michael Favia wrote:
I'm no more a"fan" of git than i am of drupal. Its a tool that has good value if you know how to use it and can frustrate the hell out of you if you dont. Let's just say it frustrates the hell out of me. :) So did drupal at first for me at least but we've grown accustomed to each other over the last 5 years. :)
git diff origin<--- does the wrong thing, in my case git diff HEAD<--- appears to work git diff origin/6.x-3.x<-- appears to work, in my case Your "origin" is a reference to a remote repository. That repository has a "default branch". It seems, at least in this case, that this default branch is NOT 6.x-3.x. This explains why the former failed and the latter worked for you. It probably looked like a ton of changes because it was set to the 7 branch or something :). The HEAD comparison is entirely local and what you really wanted to use anyway you cut it.
Thanks for explaining that. Anytime bud. You've saved me days with fb and associated work. Happy to help. if you ever run into specific issues hit me up in IRC.
-- Michael Favia michael@favish.com tel. 512.669.5650 http://www.favish.com
Hi Dave, I think that the main thing your missing is that you're still stuck in the old ways of CVS, when you weren't allowed to commit to the repo. Now you have your own copy of the entire repo, and you can do whatever you like with it. By far the easiest way to do some work and generate a patch is to start by branching: git checkout -b dev-new-work-123456 Then you do some work, maybe edit file a file here, and create a file there, then you add those to the 'index': git add edited.file.php git add created.file.php Then you can commit those changes: git commit Then you can repeat, do some more work, add and commit until you're done. At this point you'll have two branches of work, the clean copy of (say) 6.x-1.x and yours, which you can now diff easily: git diff 6.x-1.x This will give me a diff of my current branch (dev-new-work-123456) with 6.x-1.x, which will be the patch file you're after. Not being scared of branching and committing really is the key to effectively using git. Git really does change the way you work, and for the better, give it a year and you'll wonder how you managed before! Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk On 11 April 2011 21:32, Dave Cohen <drupal@dave-cohen.com> wrote:
On Monday 11 April 2011 13:09:20 Michael Favia wrote:
I'm no more a"fan" of git than i am of drupal. Its a tool that has good value if you know how to use it and can frustrate the hell out of you if you dont.
Let's just say it frustrates the hell out of me. :)
It just has one more layer of intelligence/workflow that allows it/you to ignore changes in your working copy that you don't want to pay attention right now.
In my case there are modified files, and added files, and I want git to pay attention to both of those groups.
I find that "git diff HEAD" is wrong because I'm not working on HEAD. Similarly, "git diff origin" does not do the right thing. You find that its wrong or it doesnt work? These are two different things.
Wrong for my case, I meant. I thought I tried both "git diff HEAD" and "git diff origin" and both produced a diff with too many changes. But I tried again, and "git diff HEAD" did what I wanted. So I guess I was seeing things for a moment there.
git diff origin <--- does the wrong thing, in my case git diff HEAD <--- appears to work git diff origin/6.x-3.x <-- appears to work, in my case
(I also add --no-prefix when running git diff, at least when I remember)
HEAD is a special dynamic variable that refers to the most recent commit in the index. It is there so you don't have to type in the whole commits crazy ass SHA name. In that way it works EXACTLY like a named version tag. (fyi HEAD^ equals "next to last commit" so git "diff HEAD^ HEAD" shows you the diff between the last commit and the one before it).
Thanks for explaining that.
-Dave
Targeted answer to this original question: `git diff` will show you unstaged changes. `git diff --cached` (or --staged, they are synonyms) will show you staged changes. `git diff HEAD` will show you all of these changes together. And, re: your point:
I find that "git diff HEAD" is wrong because I'm not working on HEAD. Similarly, "git diff origin" does not do the right thing.
HEAD from CVS days is gone. In Git, HEAD basically refers to whatever's currently checked out in your working copy - typically the branch you're currently working on. cheers s On 4/11/11 10:16 AM, Dave Cohen wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
On Monday 11 April 2011, Dave Cohen wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
Here is a simple way to pull together a patch on a drupal project. Create a new directory, let's call it 'git-sandbox' cd into it and run something like this: git clone --branch 6.x-3.x http://git.drupal.org/project/mymodule.git This will create a directory 'mymodule' (or whatever you fetched) copy your changed files into it and run git diff > mymodule.patch if you are adding new files copy them in and run 'add .' cd in and run git diff --staged > mymodule.patch To do both at the same time git diff HEAD > mymodule.patch As Sam Boyer explains earlier in this thread. open the patchfile in your editor and eyeball to see if it makes any sense If that's OK copy the patchfile away somewhere and delete the whole mymodule directory and run the git clone command again, copy the patchfile back in and run git apply mymodule.patch or patch -p1 < mymodule.patch if it applies cleanly you are ready to upload the patch to the issue queue or wherever. Of course a git clone run using http cannot be used for commits so it is 'safer' as it were. You can also do all this and a lot more using a tool like Smartgit though many would argue that learning it on the command line is better for understanding it, true enough. Another *big* help is to install the git docs (as well as php, mysql etc) on your devbox. Hope this helps.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included as well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
-- ----------------- Bob Hutchinson Midwales dot com -----------------
Dev list: Yeah I've definitely learned that you might be much better off using the 'create branches for features and delete them when done, or make them public to allow people to help' method rather than the old CVS 'make changes and then a patch' method of development. It's a transition, but I think it works really well once you get used to it. And I'm one of the biggest CVS curmudgeons in Drupal. Dave Reid dave@davereid.net On Mon, Apr 11, 2011 at 4:42 PM, Bob Hutchinson <hutchlists@midwales.com>wrote:
On Monday 11 April 2011, Dave Cohen wrote:
I'm trying, and failing, to create a patch that adds new files to a module.
Here is a simple way to pull together a patch on a drupal project.
Create a new directory, let's call it 'git-sandbox' cd into it and run something like this:
git clone --branch 6.x-3.x http://git.drupal.org/project/mymodule.git
This will create a directory 'mymodule' (or whatever you fetched)
copy your changed files into it and run
git diff > mymodule.patch
if you are adding new files copy them in and run 'add .'
cd in and run
git diff --staged > mymodule.patch
To do both at the same time
git diff HEAD > mymodule.patch
As Sam Boyer explains earlier in this thread.
open the patchfile in your editor and eyeball to see if it makes any sense
If that's OK copy the patchfile away somewhere and delete the whole mymodule directory and run the git clone command again, copy the patchfile back in and run
git apply mymodule.patch or patch -p1 < mymodule.patch
if it applies cleanly you are ready to upload the patch to the issue queue or wherever.
Of course a git clone run using http cannot be used for commits so it is 'safer' as it were.
You can also do all this and a lot more using a tool like Smartgit though many would argue that learning it on the command line is better for understanding it, true enough.
Another *big* help is to install the git docs (as well as php, mysql etc) on your devbox.
Hope this helps.
According to http://drupal.org/node/707484, I should simply run `git add ...` then "Next time you run git diff, these new files will be included
as
well." In my experience, this statement is false.
When I run `git status`, I see something like this:
[dave@starbuck fb-3]$ git status # On branch 6.x-3.x # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: fb.process.inc # new file: fb_tab.js # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.txt # modified: contrib/fb_example.module # modified: fb.module # modified: fb_canvas.admin.inc # modified: fb_canvas.module # modified: fb_devel.module # modified: fb_settings.inc # modified: fb_tab.admin.inc # modified: fb_tab.info # modified: fb_tab.module # modified: fb_url_rewrite.inc
When I run `git diff`, I see changes to all the modified files, but I do not see the new files.
What am I missing? Thanks,
-Dave
-- ----------------- Bob Hutchinson Midwales dot com -----------------
participants (10)
-
Bob Hutchinson -
Dave Cohen -
Dave Reid -
Kyle Mathews -
Michael Favia -
Michael Favia -
Nitish Kumar -
Randy Fay -
Sam Boyer -
Steven Jones