GIT_WORK_TREE=. fails to apply patch in install profile when using --working-copy [#1276872]

This is a related issue to what a02 describes in http://drupal.org/node/745224 comments 110, 115 are the pertinent details.

Basically when an install profile is tracked in a git repository patching fails on a sub-directory if the '--working-copy' flag is used.

I was able to reproduce this issue manually with just git. From reading the git documentation the GIT_WORK_TREE as defined should resolve the issue however this is not the case for me. I attempted passing the --work-tree=. command as well. On both versions of this command git returns success but fails to apply the patch even though PATCHES.txt is cleanly generated referencing that the patch is applied. The interesting thing for me is that using the '--bare' flag worked perfectly for me.

Below is my shell output from the above discovery. Note that '/srv/www/html/profiles/PROFILE' is a git checkout of an install profile with the name PROFILE used to protect sensitive informaiton.

jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ diff -u scribdfield.module.org scribdfield.module
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ cp /home/jeff/scribdfield-undefined-index-warning-1274418-1.patch  .
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ GIT_WORK_TREE=. && git apply -p1 ./scribdfield-undefined-index-warning-1274418-1.patch --verbose
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ diff -u scribdfield.module.org scribdfield.module
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ GIT_WORK_TREE=. && git apply -p1 ./scribdfield-undefined-index-warning-1274418-1.patch --verbose
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ echo $?
0
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ diff -u scribdfield.module.org scribdfield.module
jeff@ubuntu:/srv/www/jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ git --work-tree=. apply -p1 ./scribdfield-undefined-index-warning-1274418-1.patch --verbose
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ echo $?
0
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ diff -u scribdfield.module.org scribdfield.module
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ git --bare apply -p1 ~/scribdfield-undefined-index-warning-1274418-1.patch --verbose
Checking patch scribdfield.module...
Applied patch scribdfield.module cleanly.
jeff@ubuntu:/srv/www/html/profiles/PROFILE/modules/scribdfield$ diff -u scribdfield.module.org scribdfield.module
--- scribdfield.module.org	2011-09-12 12:39:24.302284074 -0700
+++ scribdfield.module	2011-09-12 12:41:37.642430471 -0700
@@ -173,7 +173,7 @@
 function _scribdfield_node_presave(&$node, $field) {
   // Upload each file to Scribd.
   foreach ($node->{$field['field_name']} as $field_delta => $field_value) {
-    if (($field_value['filepath'])
+    if (!empty($field_value['filepath'])
       && ($field_delta == 'field_scribd')
       && !($field_value['data']['scribd_doc_id']
       && file_exists($node->{$field['field_name']}[$field_delta]['filepath'])) ){

From testing this scenario locally I am using the following;
http://ftp.drupal.org/files/projects/scribdfield-6.x-1.1-beta1.tar.gz
with the following patch;
http://drupal.org/files/issues/scribdfield-undefined-index-warning-12744...

git version: 1.7.0.4
drush: 4.5
drush make: 2.3

Also related as I think changing the order could resolve this issue as applying the patches prior to moving to the __build__ dir would prevent any potential nested git directories.
http://drupal.org/node/1212834

Comment	File	Size	Author
#27	drush-1276872-git-fail-apply-patches-GIT_DIR.patch	1.03 KB	patcon
#19	drush-1276872-git-fail-apply-patches.patch	1.41 KB	steven jones
#10	drush_make-git_work_tree_fails_to_patch-1276872-10.patch	1.02 KB	mrfelton
#2	drush_make-git_work_tree_fails_to_patch-1276872-2.patch	1015 bytes	jgraham

Comments

Comment #1

jgraham commented 12 September 2011 at 19:52

To clarify using '--bare' rather than 'GIT_WORK_TREE=.' resolves the issue for me.

Comment #2

jgraham commented 12 September 2011 at 21:22

Status:

Active

» Needs review

Status	File	Size
new	drush_make-git_work_tree_fails_to_patch-1276872-2.patch	1015 bytes

Attached patch resolves the described issue for me.

Comment #3

adamdicarlo commented 16 September 2011 at 20:47

Subscribing.

Comment #4

steven jones commented 22 September 2011 at 11:43

Do you have any documentation about what the --bare option does for git apply?

Comment #5

jgraham commented 30 September 2011 at 17:35

Since kernel.org is still down http://schacon.github.com/git/git.html

--bare

Treat the repository as a bare repository. If GIT_DIR environment is not set, it is set to the current working directory.

There is obviously a difference between setting GIT_DIR to '.' versus using '--bare'. From reading the git documentation I initially thought the behaviour would be the same but in practice it was definitely not.

So '--bare' sets GIT_DIR to '.' and then treats the repository as a "bare repository". In this scenario I think the important detail is that it doesn't traverse up the directory structure looking for a .git dir.

An alternate solution, which I think would be better, is just changing the order when patches are applied covered in #1212834

Comment #6

ao2 commented 7 October 2011 at 10:38

Subscribing, to see where this end up :)

Comment #7

steven jones commented 10 December 2011 at 17:18

Status:

Needs review

» Needs work

I have now seen this with one of my repos, but not sure that --bare is the answer here.

Comment #8

steven jones commented 10 December 2011 at 17:37

I'm seeing this issue with git 1.7.0.4, but not with git 1.7.5.4, odd.

Comment #9

helmo commented 16 December 2011 at 22:00

Project:	Drush Make	» Drush
Version:	6.x-2.3	»
Component:	Code	» Make

[ Powered by #1115636: Issue Macros and Templates - Drush Make]

Drush make is being merged into drush core (discussed in issue:#1310130: Put drush make in drush core)
This means that the issue queue is also moving. The drush queue has a component 'Make' especially for drush_make.

More information will be posted on the drush_make and drush project pages.

Comment #10

mrfelton commented 5 April 2012 at 13:05

Status	File	Size
new	drush_make-git_work_tree_fails_to_patch-1276872-10.patch	1.02 KB

Similar problem for us. Patches do not actually apply, although there are no reported build errors, and PATCHES.txt is still generated. Very very problematic, as the only way to tell if your build is actually complete is to manually check if every single patch has been applied. It also means that unless you are aware of this issue, you can very easily end up with a platform build with missing patches. So, I'm upping this to Major priority.

Here is a revised patch against latest code, based on #2

Comment #11

mrfelton commented 5 April 2012 at 13:06

Priority:

Normal

» Major

Comment #12

milesw commented 5 April 2012 at 13:15

I ran into the same thing described in #10. Patches were reported to apply successfully but code actually went untouched. Updated to Git 1.7.9.4 and the problem is resolved. Not sure now which version I was running before.

Comment #13

mrfelton commented 5 April 2012 at 14:36

milesw - We were having this issue with very latest code in git, from a clone of the drush repo made just a couple of hours ago. We are using git 1.7.0.4 for the record - latest version available through apt on Ubuntu LTS.

Comment #14

steven jones commented 5 April 2012 at 15:02

@mrfelton Indeed, that version of git exhibits this bug, sadly.

Comment #15

mrfelton commented 5 April 2012 at 15:04

ok, we'll I suspect this is the version that the majority of people will have, since it's what you get with LTS Ubuntu.

Comment #16

steven jones commented 5 April 2012 at 15:08

Agreed, the use of --bare is a bit lame IMHO, but I guess that it will solve the issue. We should document why we are using it though, because it's weird.

Comment #17

thedavidmeister commented 16 April 2012 at 07:36

fyi, I am seeing this bug with git version 1.7.2.5

Comment #18

sylus commented 3 July 2012 at 14:50

Yeah experienced this bug too. Actually wasted a few days because as mentioned the patches.txt state the patches applied cleanly. This is definitely a major bug.

What is a long term solution for this? Looks like a few options:

1) Add the patch
2) Upgrade to latest git (though still seems not 100% fix)

Ideally if the patch works can we not get this in?

Comment #19

steven jones commented 3 July 2012 at 14:52

Status:

Needs work

» Needs review

Status	File	Size
new	drush-1276872-git-fail-apply-patches.patch	1.41 KB

Here's the comment I wanted in #16, if someone could test this, that would be great.

Comment #20

jhedstrom

English

Portland, OR

commented 3 July 2012 at 20:09

Tests are all passing with #19. Is there any way to write a test for this specific failure though? If not I'm inclined to commit after others have had a chance to test the fix.

Comment #21

sylus commented 5 July 2012 at 21:54

Works for me! Thanks for the great work! :)

Comment #22

dominikb1888 commented 20 July 2012 at 10:07

I've manually applied the patch against 6.x-2.3, it works for an issue I had with these patches, when running the makefile through Aegir:
- http://drupal.org/files/issues/noderelationships.delete-842456-23.patch
- http://drupal.org/files/features-revert-660958-97.patch

Comment #23

patcon commented 1 November 2012 at 07:59

Patch works for me.

Errr... Would I be out of line to bump this to critical? No patches apply when --working-copy flag is used for install profiles? Seems pretty critical?

Comment #24

thedavidmeister commented 1 November 2012 at 09:55

it is pretty heinous, I've had to drop --working-copy from my workflow completely, but as I understand it only affects a limited number of people who have a version of git with the bug in it, and that bug has been fixed in later versions of git... IMO if you want to get it committed and you've tested the patch, you'd be better of changing the status to RTBC than the priority to critical.

Comment #25

patcon commented 2 November 2012 at 01:53

Good point. Thanks @thedavidmeister :)

I think I've found the root of the issue, and it's not really a mystery (although the change in behavior is odd. From man git:

--work-tree=
Set the path to the working tree. The value will not be used in combination with repositories found automatically in a .git directory (i.e. $GIT_DIR is not set).
This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable. It can be an absolute path or relative
path to the directory specified by --git-dir or GIT_DIR. Note: If --git-dir or GIT_DIR are specified but none of --work-tree, GIT_WORK_TREE and core.worktree is
specified, the current working directory is regarded as the top directory of your working tree.

--bare
Treat the repository as a bare repository. If GIT_DIR environment is not set, it is set to the current working directory.

So this bug only comes into play in profiles that are presumably already version-controlled. It affects trying to apply an email patch via git apply-patch to a non-version-controlled project when using --working-copy(Views module tarball in my case). GIT_WORK_TREE is not used when the .git dir is found automatically (ie. when $GIT_DIR is not set). --bare solves things because it sets GIT_DIR to the working directory.

So in theory, GIT_DIR=. git apply patch etc should work just as well as the --bare flag. Haven't tested that yet.

Comment #26

patcon commented 2 November 2012 at 02:02

I am a terrible Sherlock. Apologies to @jgraham in #5 :/

Comment #27

patcon commented 2 November 2012 at 02:17

Status	File	Size
new	drush-1276872-git-fail-apply-patches-GIT_DIR.patch	1.03 KB

Actually, I'm on git 1.7.0.4 and drush 5.7, and it seems that setting GIT_DIR=. (rather than GIT_WORK_TREE=. or --bare), solves the problem as well.

Can you confirm your previous findings @jgraham et al in regards to GIT_DIR not working for some reason?

Comment #28

patcon commented 2 November 2012 at 02:22

Ugh. OK, so it was THIS patch: http://drupal.org/files/views-1055616-71.patch
which isn't a git email patch, so perhaps no surprise that it applied. Sorry too many cooks in the kitchen on the project I'm working on -- patch got switched

Comment #29

alarcombe commented 29 November 2012 at 09:42

Hi,

I can confirm that this patch worked for me. Git 1.7.1, Drush 5.8

FWIW Attempting to apply the patch manually on the command line using git apply resulted in no output. Doing any of the following manually all worked too.

git config core.bare true && git apply patchfile
git init && git apply patchfile
GIT_DIR=. git apply patchfile