Re: [PATCH 2/2] transport-helper: update remote helper namespace
Hi, Why wasn't this patch merged to 'pu'? To my knowledge nobody raised any real concerns. Should I explain in every commit that touches transport-helper how remote-helpers without marks are impossible? I know I said I was going to update the commit message, but I don't think that reason to not put it in 'pu'. Also, the only reason I said so was to make Jeff happy, but now that I think again, it doesn't really belong there; remote helpers cannot be using these refs, they just can't. They cannot work without marks, it's not possible. To think otherwise is simply a mistake. On Thu, Apr 11, 2013 at 12:18 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Apr 11, 2013 at 12:05 AM, Jeff King p...@peff.net wrote: On Wed, Apr 10, 2013 at 11:53:38PM -0500, Felipe Contreras wrote: But if we push some commits to the helper, moving Y up to Z, then it would build the new commit (which contains the foreign-vcs's equivalent of Y..Z) on top of Z, not Y. Why would it do that? If X points to say revision 100, presumably it was stored somewhere while doing a fetch. Similarly, if foreign version of Z is 150, it can update that number while doing a push. The next fetch it would start from 151. I think the only reason not to bump the marker forward during the push would be if the helper wants for some reason to re-import from the foreign source rather than accepting the git versions of the commits. Something like git-svn's markup of the commit messages with revision ids comes to mind. Yeah, but that's already a second level hypothesis. First, remote-helpers would need to be able to work without marks, and they can't. But if it matters, then by definition that would mean that the import/export is not bidirectionally clean. I don't see how would that matter. So I can buy the argument that bumping it forward ourselves will not matter for any well-implemented helper. Or any helper. That is the sort of thing that might be helpful to include in the commit message; if somebody does run across such a helper and bisects to your commit, then they can understand the rationale for the decision. If it did matter, it would be mentioned. I will updated it later if there's no further comments. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] transport-helper: report errors properly
On Sat, Apr 13, 2013 at 12:42:29AM -0500, Felipe Contreras wrote: To me, the reality is obvious: my patch didn't require such a big commit message, the short version was fine, the only reason Jeff King insisted on a longer version is because the patch came from me. Get over yourself. The reason I suggested a longer commit message for your commit is because after spending several hours figuring out what the current code did, and what it should be doing instead, I wanted to document that effort so that I and other readers did not have to do it again later. I didn't even review the other patch you mention, so I could not possibly have come to the same point with it. But hey, if you want to have paranoid fantasies that I'm persecuting you (by writing the longer commit messages for you!), go ahead. If you don't want me to review your patches, that's fine by me, too; our discussions often end up frustrating, and it's clear we do not agree on very much with respect to process or design. But if you don't want that, please stop cc'ing me when you send out the patches. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] shallow clones over http
On Wed, Apr 10, 2013 at 12:48:51PM +, Tom wrote: The problem occurs to me also when I want to deepen a shallow clone of MediaWiki via https:// git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git pull --depth=9 fatal: git fetch-pack: expected shallow list. Perhaps it helps someone to find the reason. UPDATE: This however works git clone --depth=2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git fetch --depth=5 Yes, I experienced the same thing. I don't think the problem is related to the depth per se, but rather the particular pattern of ACKs that upload-pack sends based on which commits are being selected. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] transport-helper: report errors properly
On Sat, Apr 13, 2013 at 1:00 AM, Jeff King p...@peff.net wrote: On Sat, Apr 13, 2013 at 12:42:29AM -0500, Felipe Contreras wrote: To me, the reality is obvious: my patch didn't require such a big commit message, the short version was fine, the only reason Jeff King insisted on a longer version is because the patch came from me. Get over yourself. The reason I suggested a longer commit message for your commit is because after spending several hours figuring out what the current code did, and what it should be doing instead, I wanted to document that effort so that I and other readers did not have to do it again later. I didn't even review the other patch you mention, so I could not possibly have come to the same point with it. The double standard might not come from you, perhaps you subject all the patches you review to the same standard, it comes from the fact that the patches you review have an unfair disadvantage. But hey, if you want to have paranoid fantasies that I'm persecuting you (by writing the longer commit messages for you!), go ahead. You don't persecute me, you persecute my patches. I could almost picture the moment you see a patch is coming from me, you have already decided to rewrite the commit message, even before reading it. Antoine is not me, so you simply didn't review that patch. If you don't want me to review your patches, that's fine by me, too; our discussions often end up frustrating, and it's clear we do not agree on very much with respect to process or design. But if you don't want that, please stop cc'ing me when you send out the patches. This comment was directed towards Junio, I do hope he is able to see the double standard. As for you, I think your reviews have value, but I also think you dwelling in irrelevant details do slow things down, which is not too bad, what is bad is that you assume that your opinions are facts (e.g. the commit message need to be bigger), and get angry when somebody disagrees with them. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/2] doc/http-backend: match query-string in apache half-auth example
W dniu 13.04.2013 05:33, Jeff King pisze: When setting up a half-auth repository in which reads can be done anonymously but writes require authentication, it is best if the server can require authentication for both the ref advertisement and the actual receive-pack POSTs. [...] Thanks for writing(and testing) this patch. -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ARA 2013 ----- ECS 2013 (part of ARA 2013) ----- New Deadline for ECS 2013. Indexing in ISI, EI Compendex, SCOPUS, INSPEC (IET) etc... Publication of accepted papers in Journals or Chapters i
*ECS 2013* The 2013 International Conference on Electronics and Communication Systems July 16-19, 2013, Rhodes (Rodos) Island, Greece http://www.europment.org/conf2013/ecs.htm PUBLICATIONS: Extended Versions of Selected papers (about 40%) will be published in Journals of NOVA Publishers or as Chapters in Books of Springer Verlag, World Scientific, Imperial College Press, IOS Press, IGI Global and others. These Books (hard copies) of Springer Verlag, World Scientific, Imperial College Press, IOS Press, IGI Global, etc will be sent to all authors after the conference. These publishers will take care of Indexing of these Books in all major indexes (including ISI). Samples from our previous work with SPRINGER: http://www.springer.com/?SGWID=0-102-24-0-0searchType=EASY_CDAqueryText=Mastorakis Samples from our previous work with WORLDSCIENTIFIC http://www.worldscientific.com/action/doSearch?searchType=normalsearchText=MastorakispublicationFilterSearch=all Samples from our previous work with NOVA Publishers https://www.novapublishers.com/catalog/advanced_search_result.php?keywords=MastorakisosCsid=85c084d2f14555a3366fac07495f9b98x=0y=0 The Proceedings of the Conferences (all the accepted and registered papers; not only the selected ones to be sent to the previous publishers) with all the accepted and registered papers of the conferences will be sent for indexing to: ISI (Thomson Reuters), ELSEVIER, SCOPUS, ACM - Association for Computing Machinery, Zentralblatt MATH, British Library, EBSCO, SWETS, EMBASE, CAS - American Chemical Society, EI Compendex, Engineering Village, DoPP, GEOBASE, Biobase, TIB|UB - German National Library of Science and Technology, American Mathematical Society (AMS), Inspec - The IET, Ulrich's International Periodicals Directory. The conferences will feature tutorials, technical paper presentations, workshops and distinguished keynote speeches Organizing Committee General Chairs - Professor Charles A. Long Professor Emeritus University of Wisconsin Stevens Point, Wisconsin, USA Professor Nikos E. Mastorakis Military Institutes of University Education (ASEI) Hellenic Naval Academy Sector of Electrical Engineering and Computer Science Piraeus, Greece -also with- Technical University of Sofia 1000 Sofia, Bulgaria Professor Valeri Mladenov Technical University of Sofia 1000 Sofia, Bulgaria Senior Program Chair Professor Philippe Dondon ENSEIRB Rue A Schweitzer 33400 Talence France Program Chairs - Professor Filippo Neri Dipartimento di Informatica e Sistemistica University of Naples Federico II Naples, Italy Professor Hamid Reza Karimi Department of Engineering Faculty of Engineering and Science University of Agder, N-4898 Grimstad Norway Professor Sandra Sendra Instituto de Inv. para la Gestion Integrada de Zonas Costeras (IGIC) Universidad Politecnica de Valencia, Spain Tutorials Chair -- Professor Pradip Majumdar Department of Mechanical Engineering Northern Illinois University Dekalb, Illinois, USA Special Session Chair Professor Pavel Varacha Tomas Bata University in Zlin Faculty of Applied Informatics Department of Informatics and Artificial Intelligence Zlin, Czech Republic Workshops Chair -- Professor Ryszard S. Choras Institute of Telecommunications University of Technology Life Sciences Bydgoszcz, Poland Local Organizing Chair - Assistant Professor Klimis Ntalianis, Technological Educat. Inst. of Athens (TEI), Athens, Greece Publication Chair Professor Gen Qi Xu Department of Mathematics Tianjin University Tianjin, China Publicity Committee -- Professor Reinhard Neck Department of Economics Klagenfurt University Klagenfurt, Austria Professor Myriam Lazard Institut Superieur d' Ingenierie de la Conception Saint Die, France International Liaisons, France Professor Ka-Lok Ng Department of Bioinformatics Asia University Taichung, Taiwan Professor Olga Martin Applied Sciences Faculty Politehnica University of Bucharest Romania Professor Vincenzo Niola Departement of Mechanical Engineering for Energetics University of Naples Federico II Naples, Italy Professor Eduardo Mario Dias Electrical Energy and Automation Engineering Department Escola Politecnica da Universidade de Sao Paulo Brazil Steering Committee --- Professor Aida Bulucea, University of Craiova, Romania Professor Dana Simian, Univ. of Sibiu, Sibiu, Romania Professor Zoran Bojkovic, Univ. of Belgrade, Serbia Professor Metin Demiralp, Istanbul Technical University, Turkey Professor F. V. Topalis, Nat. Tech. Univ. of Athens, Greece Professor Imre Rudas, Obuda University, Budapest, Hungary Program Committee Prof. Lotfi Zadeh (IEEE Fellow,University of Berkeley, USA) Prof. Leon Chua (IEEE Fellow,University of Berkeley, USA) Prof. Michio Sugeno (RIKEN Brain Science Institute (RIKEN BSI), Japan)
Fwd: Re: git send-pack: protocol error: bad band #50
Hello,
I have tried to remove and recreate my git folder and remove some files
to get more logs. Here they are:
packet: push
capabilities^{}\0 report-status delete-refs side-band-64k quiet ofs-delta
packet: push
packet: push
17c420b8bd99856aee6da9c1743f6df0ec18a9ca refs/heads/master\0
report-status side-band-64k
packet: push
packet: push
20b8bd99856aee6da9c1743f6df0ec18a9cac28267338c198573ad59e89d0acc445a62b3d127
acf853d0a30287d9455dbe1707edeb16cc3e9b22
conf.php845ecef1e4aaece71ef357285c2df71056ae0314
db98699a6c68b653be1fa8dceb64204397d9814cd1
db/db.sqlfed89aa6a337c6ab5a89dba13702a65ab70372bd
httpff2a325bfd33f1fb7098b5688ffe99fe67bf5874
http/apifbf53a7bcd223485e56d30715a794a7e067df8d2
http/api/.htaccess84d1f0580e88c6351df884200ebcd526d8b145ea
http/api/index.php9b8a7a21fa6e4c3a9672469b9b4a7e51a336d015
http/www9a464b3db152808bc74512304054ac25a63cb9b7
http/www/files8cab2dab60f85385de1ef984a976a038176c2015
http/www/files/foundationa5cb50f4203d7176a505857ac80ffbbcf562c91f
http/www/files/foundation/cssc2a844c8a00ef41d912f53c40026580f2b10fd00
http/www/files/foundation/css/accessibility_foundicons.css699d805b9f5858111d4bc95705df22f6137ec14a
http/www/files/foundation/css/accessibility_foundicons_ie7.css8e0ddf1ac316d9231277a77bcd550895f291b5c7
http/www/files/foundation/css/foundation.css1d592b3fc77c4b44af67b82edbee4cc51b8a97d9
http/www/files/foundation/css/foundation.min.css3c308c85cf36052810d35c08d4f5bbc233cf61ea
http/www/files/foundation/css/general_foundicons.cssd5b3776730a16e4ec61bad31526cc0a5a24096bc
http/www/files/foundation/css/general_foundicons_ie7.cssa9c6f52f05e50c6fd8dab6c30e22c8d4ea2f15ea
http/www/files/foundation/css/normalize.css914f6472ffce7135f191048a923e07e7886f192b
http/www/files/foundation/css/social_foundicons.css6a3c9c07729fc466c38e6a40d36b298de881706b
http/www/files/foundation/css/social_foundicons_ie7.cssd44839248d958fdc96fa044dae0ea71dffd35bde
http/www/files/foundation/fonts5008ddfcf53c02e82d7eee2e57c38e5672ef89f6
http/www/files/foundation/fonts/.DS_Store237a0ca97e568531dc58bf7c81202028af1e881c
http/www/files/foundation/fonts/accessibility_foundicons.eot49c0d07bea6f18cdbc35ee938b1b3f48cacce64c
http/www/files/foundation/fonts/accessibility_foundicons.svg46a67f8d0223b881ca74ccafb44b64664552b937
http/www/files/foundation/fonts/accessibility_foundicons.ttf4eae85189fee6930191b69e31a09b34e6a9a9c19
http/www/files/foundation/fonts/accessibility_foundicons.woff20733a0388ef77572cbc55cbf76cc46babf0a15d
http/www/files/foundation/fonts/general_foundicons.eota9347515264ac712b5d083eaa231929243ea7142
http/www/files/foundation/fonts/general_foundicons.svg90a5ccead2d84d036bd8ed66926af93b21621df5
http/www/files/foundation/fonts/general_foundicons.ttfdaab63141b07e0a1fa8efd931a98945b837bd4aa
http/www/files/foundation/fonts/general_foundicons.woffa9341f49f12c10aaa5db2bc74ed3889245ce9a3a
http/www/files/foundation/fonts/social_foundicons.eoteb4189cd70c623deaa25e5bb55ab210d27fe2d14
http/www/files/foundation/fonts/social_foundicons.svg01158c66b13b6f90e7b7d1cdb5c4e7369c6434ae
http/www/files/foundation/fonts/social_foundicons.ttfbd1f1e58a692b73205fce579faee81801d3157aa
http/www/files/foundation/fonts/social_foundicons.woffcd2531e2044a9c1875159ff1278aafac1aaa8944
http/www/files/foundation/img8b137891791fe96927ad78e64b0aad7bded08bdc
http/www/files/foundation/img/.gitkeep36b90e58095363e46845d98d979700d16019830e
http/www/files/foundation/js596287860dbdcd04dd8a78d2ee1999862286515a
http/www/files/foundation/js/foundation.min.jsec14148b2d83476fffebf3cba39d6516844b7200
http/www/files/foundation/js/foundationb78a35a14d000346914644cc0e9783a40f64760d
http/www/files/foundation/js/foundation/foundation.alerts.jsc8ff324991762b763dd936da49415fff1ec2de93
http/www/files/foundation/js/foundation/foundation.clearing.js862027c8631db60070e8c3ebd7b8953c0283c561
http/www/files/foundation/js/foundation/foundation.cookie.js24b35e12e7860a80edb9f16a0209715f249f96b0
http/www/files/foundation/js/foundation/foundation.dropdown.js6a27af4ad0e0865235cd3a84cd251b8f928510ba
http/www/files/foundation/js/foundation/foundation.forms.js323e6e1e633ace0dcc873553b8df03a28bcd78bc
http/www/files/foundation/js/foundation/foundation.joyride.js87c3b65bd9231264c110749b7ad75214cee50c93
http/www/files/foundation/js/foundation/foundation.js3cdef5b617b054a355f80a5bce164cc1ed8a419e
http/www/files/foundation/js/foundation/foundation.magellan.js54c467efd46e3c199ae4dd0860ee5196403b1027
http/www/files/foundation/js/foundation/foundation.orbit.js65c18fc2b4383b5111953114c13ebdb2ba3c5cda
http/www/files/foundation/js/foundation/foundation.placeholder.js31a450ad44b7ec6593bdefc4a88c781a45c418e1
http/www/files/foundation/js/foundation/foundation.reveal.js1069794478f6c4032e1caf4ecc24bce961482835
[PATCH v2 3/3] convert.c: Remove duplicate code
has_cr_in_index() is an almost 1:1 copy of
read_blob_data_from_index_path() with some additions. Invoke
read_blob_data_from_index_path() instead of using copy-pasted code.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
convert.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/convert.c b/convert.c
index 3520252..a12bc78 100644
--- a/convert.c
+++ b/convert.c
@@ -153,36 +153,13 @@ static void check_safe_crlf(const char *path, enum
crlf_action crlf_action,
static int has_cr_in_index(const char *path)
{
- int pos, len;
unsigned long sz;
- enum object_type type;
void *data;
int has_cr;
- struct index_state *istate = the_index;
- len = strlen(path);
- pos = index_name_pos(istate, path, len);
- if (pos 0) {
- /*
-* We might be in the middle of a merge, in which
-* case we would read stage #2 (ours).
-*/
- int i;
- for (i = -pos - 1;
-(pos 0 i istate-cache_nr
- !strcmp(istate-cache[i]-name, path));
-i++)
- if (ce_stage(istate-cache[i]) == 2)
- pos = i;
- }
- if (pos 0)
+ data = read_blob_data_from_index_path(path, NULL, sz);
+ if (!data)
return 0;
- data = read_sha1_file(istate-cache[pos]-sha1, type, sz);
- if (!data || type != OBJ_BLOB) {
- free(data);
- return 0;
- }
-
has_cr = memchr(data, '\r', sz) != NULL;
free(data);
return has_cr;
--
1.8.2.675.gda3bb24.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] Add public function read_blob_data_from_index_path()
* Make the read_index_data() function public, rename it to
read_blob_data_from_index_path() and move it from attr.c to
read-cache.c.
* Add a use_index parameter to specify a custom index_state since we are
no longer enable to access the static use_index variable from attr.c.
This allows for reusing the function in convert.c later.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
attr.c | 35 +--
cache.h | 1 +
read-cache.c | 34 ++
3 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/attr.c b/attr.c
index 689bc2a..08347b6 100644
--- a/attr.c
+++ b/attr.c
@@ -381,46 +381,13 @@ static struct attr_stack *read_attr_from_file(const char
*path, int macro_ok)
return res;
}
-static void *read_index_data(const char *path)
-{
- int pos, len;
- unsigned long sz;
- enum object_type type;
- void *data;
- struct index_state *istate = use_index ? use_index : the_index;
-
- len = strlen(path);
- pos = index_name_pos(istate, path, len);
- if (pos 0) {
- /*
-* We might be in the middle of a merge, in which
-* case we would read stage #2 (ours).
-*/
- int i;
- for (i = -pos - 1;
-(pos 0 i istate-cache_nr
- !strcmp(istate-cache[i]-name, path));
-i++)
- if (ce_stage(istate-cache[i]) == 2)
- pos = i;
- }
- if (pos 0)
- return NULL;
- data = read_sha1_file(istate-cache[pos]-sha1, type, sz);
- if (!data || type != OBJ_BLOB) {
- free(data);
- return NULL;
- }
- return data;
-}
-
static struct attr_stack *read_attr_from_index(const char *path, int macro_ok)
{
struct attr_stack *res;
char *buf, *sp;
int lineno = 0;
- buf = read_index_data(path);
+ buf = read_blob_data_from_index_path(path, use_index);
if (!buf)
return NULL;
diff --git a/cache.h b/cache.h
index ba5a47c..2a206aa 100644
--- a/cache.h
+++ b/cache.h
@@ -471,6 +471,7 @@ extern int add_file_to_index(struct index_state *, const
char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned
char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int index_name_is_other(const struct index_state *, const char *, int);
+extern void *read_blob_data_from_index_path(const char *path, struct
index_state *use_index);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index 5a9704f..964ae26 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1899,3 +1899,37 @@ int index_name_is_other(const struct index_state
*istate, const char *name,
}
return 1;
}
+
+void *read_blob_data_from_index_path(const char *path,
+struct index_state *use_index)
+{
+ int pos, len;
+ unsigned long sz;
+ enum object_type type;
+ void *data;
+ struct index_state *istate = use_index ? use_index : the_index;
+
+ len = strlen(path);
+ pos = index_name_pos(istate, path, len);
+ if (pos 0) {
+ /*
+* We might be in the middle of a merge, in which
+* case we would read stage #2 (ours).
+*/
+ int i;
+ for (i = -pos - 1;
+(pos 0 i istate-cache_nr
+ !strcmp(istate-cache[i]-name, path));
+i++)
+ if (ce_stage(istate-cache[i]) == 2)
+ pos = i;
+ }
+ if (pos 0)
+ return NULL;
+ data = read_sha1_file(istate-cache[pos]-sha1, type, sz);
+ if (!data || type != OBJ_BLOB) {
+ free(data);
+ return NULL;
+ }
+ return data;
+}
--
1.8.2.675.gda3bb24.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] Add size parameter to read_blob_data_from_index_path()
This allows for optionally getting the size of the returned data and
will be used in a follow-up patch.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
attr.c | 2 +-
cache.h | 2 +-
read-cache.c | 5 -
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/attr.c b/attr.c
index 08347b6..17338c8 100644
--- a/attr.c
+++ b/attr.c
@@ -387,7 +387,7 @@ static struct attr_stack *read_attr_from_index(const char
*path, int macro_ok)
char *buf, *sp;
int lineno = 0;
- buf = read_blob_data_from_index_path(path, use_index);
+ buf = read_blob_data_from_index_path(path, use_index, NULL);
if (!buf)
return NULL;
diff --git a/cache.h b/cache.h
index 2a206aa..a5272f2 100644
--- a/cache.h
+++ b/cache.h
@@ -471,7 +471,7 @@ extern int add_file_to_index(struct index_state *, const
char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned
char *sha1, const char *path, int stage, int refresh);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int index_name_is_other(const struct index_state *, const char *, int);
-extern void *read_blob_data_from_index_path(const char *path, struct
index_state *use_index);
+extern void *read_blob_data_from_index_path(const char *path, struct
index_state *use_index, unsigned long *size);
/* do stat comparison even if CE_VALID is true */
#define CE_MATCH_IGNORE_VALID 01
diff --git a/read-cache.c b/read-cache.c
index 964ae26..547e98a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1901,7 +1901,8 @@ int index_name_is_other(const struct index_state *istate,
const char *name,
}
void *read_blob_data_from_index_path(const char *path,
-struct index_state *use_index)
+struct index_state *use_index,
+unsigned long *size)
{
int pos, len;
unsigned long sz;
@@ -1931,5 +1932,7 @@ void *read_blob_data_from_index_path(const char *path,
free(data);
return NULL;
}
+ if (size)
+ *size = sz;
return data;
}
--
1.8.2.675.gda3bb24.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] i18n: branch: mark strings for translation
Signed-off-by: Jiang Xin worldhello@gmail.com
Reviewed-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Not mark BUG: impossible combination of %d and %p, which would
never happen.
branch.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/branch.c b/branch.c
index 6ae6a..4ddd69 100644
--- a/branch.c
+++ b/branch.c
@@ -57,7 +57,7 @@ void install_branch_config(int flag, const char *local, const
char *origin, cons
if (remote_is_branch
!strcmp(local, shortname)
!origin) {
- warning(Not setting branch %s as its own upstream.,
+ warning(_(Not setting branch %s as its own upstream.),
local);
return;
}
@@ -79,23 +79,23 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
if (flag BRANCH_CONFIG_VERBOSE) {
if (remote_is_branch origin)
printf(rebasing ?
- Branch %s set up to track remote branch %s from
%s by rebasing.\n :
- Branch %s set up to track remote branch %s from
%s.\n,
+ _(Branch %s set up to track remote branch %s
from %s by rebasing.\n) :
+ _(Branch %s set up to track remote branch %s
from %s.\n),
local, shortname, origin);
else if (remote_is_branch !origin)
printf(rebasing ?
- Branch %s set up to track local branch %s by
rebasing.\n :
- Branch %s set up to track local branch %s.\n,
+ _(Branch %s set up to track local branch %s by
rebasing.\n) :
+ _(Branch %s set up to track local branch
%s.\n),
local, shortname);
else if (!remote_is_branch origin)
printf(rebasing ?
- Branch %s set up to track remote ref %s by
rebasing.\n :
- Branch %s set up to track remote ref %s.\n,
+ _(Branch %s set up to track remote ref %s by
rebasing.\n) :
+ _(Branch %s set up to track remote ref %s.\n),
local, remote);
else if (!remote_is_branch !origin)
printf(rebasing ?
- Branch %s set up to track local ref %s by
rebasing.\n :
- Branch %s set up to track local ref %s.\n,
+ _(Branch %s set up to track local ref %s by
rebasing.\n) :
+ _(Branch %s set up to track local ref %s.\n),
local, remote);
else
die(BUG: impossible combination of %d and %p,
@@ -115,7 +115,7 @@ static int setup_tracking(const char *new_ref, const char
*orig_ref,
int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE;
if (strlen(new_ref) 1024 - 7 - 7 - 1)
- return error(Tracking not set up: name too long: %s,
+ return error(_(Tracking not set up: name too long: %s),
new_ref);
memset(tracking, 0, sizeof(tracking));
@@ -134,7 +134,7 @@ static int setup_tracking(const char *new_ref, const char
*orig_ref,
}
if (tracking.matches 1)
- return error(Not tracking: ambiguous information for ref %s,
+ return error(_(Not tracking: ambiguous information for ref
%s),
orig_ref);
install_branch_config(config_flags, new_ref, tracking.remote,
@@ -179,12 +179,12 @@ int validate_new_branchname(const char *name, struct
strbuf *ref,
int force, int attr_only)
{
if (strbuf_check_branch_ref(ref, name))
- die('%s' is not a valid branch name., name);
+ die(_('%s' is not a valid branch name.), name);
if (!ref_exists(ref-buf))
return 0;
else if (!force !attr_only)
- die(A branch named '%s' already exists., ref-buf +
strlen(refs/heads/));
+ die(_(A branch named '%s' already exists.), ref-buf +
strlen(refs/heads/));
if (!attr_only) {
const char *head;
@@ -192,7 +192,7 @@ int validate_new_branchname(const char *name, struct strbuf
*ref,
head = resolve_ref_unsafe(HEAD, sha1, 0, NULL);
if (!is_bare_repository() head !strcmp(head, ref-buf))
- die(Cannot force update the current branch.);
+ die(_(Cannot force update the current branch.));
}
return 1;
}
@@ -247,7 +247,7 @@ void create_branch(const char *head,
}
Re: git instaweb - share all project files
Please do not top-post.
On 11.04.2013, Trenton D. Adams wrote:
#1 would actually work. Though long term it would be cool to view it
with all the most recent commit information, kind of like github does.
You know, showing updated 4 days ago.
On Wed, Apr 10, 2013 at 11:03 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 07.04.2013 05:02, Trenton D. Adams pisze:
On that first page that shows up, it shows the .git folder. It would
be kind of nice if it shared out both the git repo and the actual
current project files. I frequently have stuff I'd like to see in a
web browser, and even requires one (i.e. Navigating to
file:///home/blah/blah doesn't work; ajax requests for example)
There are a few possible solutions, from simplest to most complicated:
1. Configure gitweb ran by git-instaweb to have 'worktree' link in
the action bar pointing to 'file:///path/to/repo' (or rather
'file:///path/to/workdir') via 'actions' feature, adding e.g.
$feature{'actions'}{'default'} =
[('worktree', 'file:///path/to/repo', 'summary')];
to gitweb_config.perl / gitweb.conf used by git-instaweb's gitweb.
This of course works only for local use, so either git-instaweb
or gitweb (in config) should check that we use it locally
(e.g. if hostname is 'localhost' or equivalent).
[...]
Unfortunately it turns out such simple solution doesn't really work.
First, for some reason Firefox 20.0 refuses to follow file:/// link,
even though it shows correctly worktree if copy'n'pasted as URL in new
window / new tab.
Second, it would work only for the top git repository. There can be
repositories being submodules, or in untracked subdirectories (like
e.g. 't/trash directory.t*/.git' in git/.git), and said 'worktree'
link would always lead to top git repository workdir.
But anyway, here you have it:
-- 8 --
Subject: [PATCH] git-instaweb: Show project files... kind of (WIP)
On first page that git-instaweb shows, it shows the .git folder. It
would be kind of nice if it shared out both the git repo and the
actual current project files (i.e. current worktree). [...]
[...]
This commit implements solution 1.), with git-instaweb enabling it
only for local use, which means when it is run with `--local` option.
Signed-off-by: Jakub Narebski jna...@gmail.com
---
git-instaweb.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 01a1b05..43ae255 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -22,6 +22,13 @@ restartrestart the web server
. git-sh-setup
fqgitdir=$GIT_DIR
+if test x$(git rev-parse --is-bare-repository) = xfalse
+then
+ fqworktree=$(git rev-parse --show-toplevel)
+else
+ fqworktree=
+fi
+
local=$(git config --bool --get instaweb.local)
httpd=$(git config --get instaweb.httpd)
root=$(git config --get instaweb.gitwebdir)
@@ -588,6 +595,13 @@ our \$projects_list = \$projectroot;
\$feature{'remote_heads'}{'default'} = [1];
EOF
+ test x$fqworktree != x
+ test x$local = xtrue
+ cat $fqgitdir/gitweb/gitweb_config.perl EOF
+\$feature{'actions'}{'default'} = [
+ ('worktree', 'file://$fqworktree', 'summary')
+];
+EOF
}
configure_httpd() {
--
1.8.2.1.367.geafc030.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bisect: Store first bad commit as comment in log file
When bisect successfully finds a single revision, the first bad commit
should be shown to human readers of 'git bisect log'.
This resolves the apparent disconnect between the bisection result and
the log when a bug reporter says I know that the first bad commit is
$rev, as you can see from $(git bisect log).
Signed-off-by: Torstein Hegge he...@resisty.net
---
I don't know how useful the added test is, I didn't find any existing
tests that looks at the comment parts of bisect log.
git-bisect.sh |8 +++-
t/t6030-bisect-porcelain.sh | 18 ++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 99efbe8..c58eea7 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,7 +311,13 @@ bisect_next() {
res=$?
# Check if we should exit because bisection is finished
- test $res -eq 10 exit 0
+ if test $res -eq 10
+ then
+ bad_rev=$(git show-ref --hash --verify refs/bisect/bad)
+ bad_commit=$(git show-branch $bad_rev)
+ echo # first bad commit: $bad_commit $GIT_DIR/BISECT_LOG
+ exit 0
+ fi
# Check for an error in the bisection process
test $res -ne 0 exit $res
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 2fce99a..6e65cdf 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -741,4 +741,22 @@ test_expect_success 'bisect: demonstrate identification of
damage boundary'
git bisect reset
+cat expected.bisect-log EOF
+# bad: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add 4: Ciao for now into
hello.
+# good: [7b7f204a749c3125d5224ed61ea2ae1187ad046f] Add 2: A new day for git
into hello.
+git bisect start '32a594a3fdac2d57cf6d02987e30eec68511498c'
'7b7f204a749c3125d5224ed61ea2ae1187ad046f'
+# good: [3de952f2416b6084f557ec417709eac740c6818c] Add 3: Another new day for
git into hello.
+git bisect good 3de952f2416b6084f557ec417709eac740c6818c
+# first bad commit: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add 4: Ciao
for now into hello.
+EOF
+
+test_expect_success 'bisect log: successfull result' '
+ git bisect reset
+ git bisect start $HASH4 $HASH2
+ git bisect good
+ git bisect log bisect-log.txt
+ test_cmp expected.bisect-log bisect-log.txt
+ git bisect reset
+'
+
test_done
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
This configuration variable comes into effect when 'git clone' is
invoked inside an existing git repository's worktree. When set,
instead of cloning the given repository as-is, it relocates the gitdir
of the repository to the path specified by this variable. This
setting is especially useful when working with submodules.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Okay, so this is part of my evil plan to make 'git add' DTRT wrt
submodules, and deprecate 'git submodule add' (I have some code
written down, but this is a prerequisite: I don't like the
.git/modules nonsense).
Unfortunately, this patch is in pathetic shape and is an RFC for
three reasons:
1. I've used setup_git_directory_gently() at the start of
builtin/clone.c to check if I'm inside a git directory. This
breaks a lot of existing tests (I'm yet to understand these
failures fully).
2. setup_git_directory_gently() has the side-effect of changing the
current directory and calling set_git_work_tree(), both of which
must be done away with if we want the rest of clone.c to work.
I've hacked around the issue in a very dirty manner. What is the
solution to this?
3. I don't know how to test the case clone.submoduleGitDir has no
effect outside a git repository, because our entire test
environment is a git repository. Even if I remove the .git
directory, we're still inside the soure tree's git repository.
What do I do about this? Even if we decide that this patch is
fundamentally unworkable, we should try to fix this issue so that
we can verify that a plain 'git clone' works outside a git
repository.
Thanks for reading. And I'm truly sorry for making you read through
such ugly code.
Documentation/config.txt | 11 +++
builtin/clone.c | 33 -
environment.c| 11 ---
t/t5702-clone-options.sh | 41 +
4 files changed, 84 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3d750e0..aac26c3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -798,6 +798,17 @@ clean.requireForce::
A boolean to make git-clean do nothing unless given -f
or -n. Defaults to true.
+clone.submoduleGitDir::
+ An absolute path on the filesystem where gitdirs of submodules
+ should be stored away safely. When not set, a 'git clone'
+ executed inside a git repository will do exactly what it does
+ outside a git repository. When set, a 'git clone' executed
+ inside a git repository will create the worktree in place of
+ the full repository, and put the object store in a
+ subdirectory of clone.submoduleGitDir, choosing the name to be
+ the humanish part of the source repository (`repo.git` for
+ `/path/to/repo.git` and `foo.git` for `host.xz:foo/.git`).
+
color.branch::
A boolean to enable/disable color in the output of
linkgit:git-branch[1]. May be set to `always`,
diff --git a/builtin/clone.c b/builtin/clone.c
index f9c380e..4a845a4 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -44,6 +44,7 @@ static char *option_template, *option_depth;
static char *option_origin = NULL;
static char *option_branch = NULL;
static const char *real_git_dir;
+static const char *submodule_gitdir;
static char *option_upload_pack = git-upload-pack;
static int option_verbosity;
static int option_progress = -1;
@@ -707,12 +708,22 @@ static void write_refspec_config(const char*
src_ref_prefix,
strbuf_release(value);
}
+static int git_clone_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, clone.submodulegitdir)) {
+ git_config_string(submodule_gitdir, var, value);
+ return 0;
+ }
+ return git_default_config(var, value, cb);
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
struct stat buf;
const char *repo_name, *repo, *work_tree, *git_dir;
- char *path, *dir;
+ char *path, *dir, *dest_git_dir;
+ char cwd[PATH_MAX];
int dest_exists;
const struct ref *refs, *remote_head;
const struct ref *remote_head_points_at;
@@ -725,6 +736,7 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
const char *src_ref_prefix = refs/heads/;
struct remote *remote;
int err = 0, complete_refs_before_fetch = 1;
+ int nongit = 1;
struct refspec *refspec;
const char *fetch_pattern;
@@ -732,6 +744,14 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
junk_pid = getpid();
packet_trace_identity(clone);
+
+ /* setup_git_directory_gently without changing directories */
+ getcwd(cwd, sizeof(cwd) - 1);
+ setup_git_directory_gently(nongit);
+
Re: git instaweb - share all project files
Jakub Narębski jna...@gmail.com wrote: Unfortunately it turns out such simple solution doesn't really work. First, for some reason Firefox 20.0 refuses to follow file:/// link, even though it shows correctly worktree if copy'n'pasted as URL in new window / new tab. I can confirm this behavior with chromium on Debian testing (25.0.1364.160 (Developer Build 186726) Debian 7.0) I can guess this is likely for security reasons. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Introduce pull.autostash
I've been using this patch for some time now, and have to say that 'git pull' is much more useable now. The feature is turned off by default so that it doesn't break any existing tests. [1/3] and [2/3] are simple while we're there patches, that are unchanged from the last round. [3/3] is actually fine in this round. I'm embarassed that I sent out the previous round in such a hurry: there were a lot of things wrong with it, as Junio's review pointed out. Ramkumar Ramachandra (3): pull: prefer invoking git command over git-command t5521 (pull-options): use test_commit() where appropriate pull: introduce --[no-]autostash and pull.autostash Documentation/config.txt | 5 Documentation/git-pull.txt | 7 + git-pull.sh| 37 ++--- t/t5521-pull-options.sh| 67 -- 4 files changed, 110 insertions(+), 6 deletions(-) -- 1.8.2.1.392.g6943ea6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pull: prefer invoking git command over git-command
14e5d40c (pull: Fix parsing of -Xoption, 2010-01-17) added the lines
containing git-push and git-merge, even though the prevelant style
at the time was to use the unhyphenated git command form. Fix
this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..5fe69fa 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -285,11 +285,11 @@ fi
merge_name=$(git fmt-merge-msg $log_arg $GIT_DIR/FETCH_HEAD) || exit
case $rebase in
true)
- eval=git-rebase $diffstat $strategy_args $merge_args $verbosity
+ eval=git rebase $diffstat $strategy_args $merge_args $verbosity
eval=$eval --onto $merge_head ${oldremoteref:-$merge_head}
;;
*)
- eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
+ eval=git merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
eval=$eval \\$merge_name\ HEAD $merge_head
;;
--
1.8.2.1.392.g6943ea6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] t5521 (pull-options): use test_commit() where appropriate
test_commit() is a well-defined function in test-lib-functions.sh that allows you to create commits with a terse syntax. Prefer using it over creating commits by hand. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5521-pull-options.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh index aa31abe..3bdfe82 100755 --- a/t/t5521-pull-options.sh +++ b/t/t5521-pull-options.sh @@ -7,8 +7,8 @@ test_description='pull options' test_expect_success 'setup' ' mkdir parent (cd parent git init -echo one file git add file -git commit -m one) +test_commit one file one + ) ' test_expect_success 'git pull -q' ' -- 1.8.2.1.392.g6943ea6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
Currently, executing a 'git pull' on a dirty worktree gives the
following annoying message:
# User doesn't notice dirty worktree
$ git pull
... # fetch operation
error: Your local changes to the following files would be overwritten by
merge:
quux
Please, commit your changes or stash them before you can merge.
Aborting
At which point the user will stash her changes, re-execute git pull,
and pop the stash. This process can easily be automated out for a
smooth:
$ git pull
... # fetch operation
Saved working directory and index state WIP on master: 8ea73ed baz
HEAD is now at 8ea73ed baz
... # The merge/rebase process
Dropped refs/stash@{0} (83f47fbfb07a741817633f9191dc4a1530f79249)
If there is a conflict during the merge/rebase process, the user has
to pop the stash by hand after committing the conflict resolution:
$ git pull
... # fetch operation
Saved working directory and index state WIP on master: 8ea73ed baz
HEAD is now at 8ea73ed baz
... # The merge/rebase process
Automatic merge failed; fix conflicts and then commit the result.
Please run 'git stash pop' after commiting the conflict resolution.
Introduce a new configuration variable pull.autostash that does
exactly this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/config.txt | 5
Documentation/git-pull.txt | 7 ++
git-pull.sh| 33 ++--
t/t5521-pull-options.sh| 63 ++
4 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3d750e0..6c5cd8e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1804,6 +1804,11 @@ pull.rebase::
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
+pull.autostash::
+ When true, automatically stash all changes before attempting
+ to merge/rebase, and pop the stash after a successful
+ merge/rebase.
+
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 24ab07a..1c5384b 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -94,6 +94,13 @@ must be given before the options meant for 'git fetch'.
has to be called afterwards to bring the work tree up to date with the
merge result.
+--[no-]autostash::
+ When turned on, automatically stash all changes before
+ attempting to merge/rebase, and pop the stash after a
+ successful merge/rebase. Useful for people who want to pull
+ with a dirty worktree. This option can also be set via the
+ `pull.autostash` configuration variable.
+
Options related to merging
~~
diff --git a/git-pull.sh b/git-pull.sh
index 5fe69fa..4edc06a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -48,6 +48,7 @@ if test -z $rebase
then
rebase=$(git config --bool pull.rebase)
fi
+autostash=$(git config --bool pull.autostash || echo false)
dry_run=
while :
do
@@ -116,6 +117,12 @@ do
--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
rebase=false
;;
+ --autostash)
+ autostash=true
+ ;;
+ --no-autostash)
+ autostash=false
+ ;;
--recurse-submodules)
recurse_submodules=--recurse-submodules
;;
@@ -202,7 +209,8 @@ test true = $rebase {
then
die $(gettext updating an unborn branch with changes
added to the index)
fi
- else
+ elif test $autostash = false
+ then
require_clean_work_tree pull with rebase Please commit or
stash them.
fi
oldremoteref=
@@ -219,6 +227,12 @@ test true = $rebase {
fi
done
}
+
+stash_required () {
+ ! (git diff-files --quiet --ignore-submodules
+ git diff-index --quiet --cached HEAD --ignore-submodules)
+}
+
orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
$@ || exit 1
test -z $dry_run || exit 0
@@ -294,4 +308,19 @@ true)
eval=$eval \\$merge_name\ HEAD $merge_head
;;
esac
-eval exec $eval
+
+if test $autostash = true stash_required
+then
+ git stash || die $(gettext Cannot autostash)
+ require_clean_work_tree pull Please commit or stash them.
+ if eval $eval
+ then
+ git stash pop || die $(gettext Cannot pop stash)
+ else
+ exit_code=$?
+ echo Please run 'git stash pop' after commiting the conflict
resolution.
+ exit $exit_code
+ fi
+else
+ eval exec $eval
+fi
diff --git a/t/t5521-pull-options.sh
Re: git p4 submit failing
l...@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100: Just a thought, but check the files that are failing to see if they've got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all sorts of nasty problems. That's assuming it's definitely not a CRLF line ending problem on Windows. I had recently debugged a similar-looking problem where core.autocrlf was set to input. Christopher, if you have this set and/or the .xml files have ^M (CRLF) line endings, please let us know. -- Pete On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: I tried running git p4 submit on a repo that I've been running as an interim bridge between git and perforce. Multiple people are using the repo as a remote and its being periodically submitted back to perforce. It's been working mostly fine. Then one day out of the blue I get this error. I can no longer push any git commits to perforce. (This is from the remote repo which I am pushing back to perforce) user@hostname:~/Source/code$ git p4 submit -M --export-labels Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying ffa390f comments in config xml files //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit error: patch failed: sub/folder/structure/first.xml:1 error: sub/folder/structure/first.xml: patch does not apply error: patch failed: sub/folder/structure/second.xml:1 error: sub/folder/structure/second.xml: patch does not apply error: patch failed: sub/folder/structure/third.xml:1 error: sub/folder/structure/third.xml: patch does not apply error: patch failed: sub/folder/structure/forth.xml:1 error: sub/folder/structure/forth.xml: patch does not apply error: patch failed: sub/folder/structure/fifth.xml:1 error: sub/folder/structure/fifth.xml: patch does not apply Unfortunately applying the change failed! //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted No commits applied. I thought it could be the .gitattributes setting that I had which was this at the time was this: * text eol=lf My global core.autocrlf setting was also false. So I remade a new remote repo, and changed core.autocrlf to input and changed .gitattributes to this * text=auto *.php text eol=lf *.pl text eol=lf *.pm text eol=lf *.sh text eol=lf *.vbs text eol=crlf *.bat text eol=crlf *.ps1 text eol=crlf *.bdb binary *.mtr binary Then I started to realize that it could just be the files in the initial commit that are suspect, because when i made edits to other files in the repo then tried to push them back with git p4 submit, those files submitted successfully But the files in the commit where I initially got the failure still give me this problem. Here's what it looks like when I retested with a fresh git repo cloned from perforce with git p4 clone and tried to do the git p4 submit with verbose turned on on only one of the suspecting files user@hostname:/code$ git p4 submit -M --export-labels --verbose Reading pipe: git name-rev HEAD Reading pipe: ['git', 'config', 'git-p4.allowSubmit'] Reading pipe: git rev-parse --symbolic --remotes Reading pipe: git rev-parse p4/master Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf Reading pipe: git cat-file commit HEAD~0 Reading pipe: git cat-file commit HEAD~1 Reading pipe: ['git', 'config', 'git-p4.conflict'] Origin branch is remotes/p4/master Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec'] Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...'] Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Opening pipe: p4 -G opened ... Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master'] Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck'] Reading pipe: ['git', 'config', 'git-p4.detectCopies'] Reading pipe: ['git', 'config', '--bool',
Re: [ITCH] pull.default
Junio C Hamano wrote: I think you can shrink and enhance the above repertoire at the same time by separating do I want to have stash and stash pop around bit into an orthogonal axis. The other orthogonal axes are Under what condition do I integrate the work from the upstream? (e.g. only when I do not have anything, aka, ff-only) and How would I integrate the work from the upstream? (e.g. rebase my work and discard anything I did aka reset --hard). Okay, so this is what I currently have: - pull.condition = clean-worktree | ff-update | no-local-changes | always | never - pull.action = merge | rebase* | reset - pull.resetType = soft | hard | merge | keep - pull.autostash = true | false (ff-update is satisfied when FETCH_HEAD is directly ahead of refs/remotes/branch, while no-local-changes is satisfied when FETCH_HEAD is directly ahead of refs/heads/branch) Personally, I would love the defaults pull.condition = ff-update, pull.action = rebase, pull.autostash = true. However, there are branches that I have where this isn't applicable. Any clues on how to design branch-specific options for all these (there's branch.name.pullAction is a bit yuck)? Did I manage to cover everything? Now that pull.autostash is done, I will start writing pull.condition after feedback. * pull.rebase is pending deprecation -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] branch: colour upstream branches
It's hard to see them among so much output otherwise.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/branch.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 00d17d2..a1cdc29 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -417,32 +417,45 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
int ours, theirs;
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
+ char fancy[80];
if (!stat_tracking_info(branch, ours, theirs)) {
if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref)
- strbuf_addf(stat, [%s] ,
- shorten_unambiguous_ref(branch-merge[0]-dst, 0));
+ show_upstream_ref) {
+ ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ strbuf_addf(stat, [%s%s%s] ,
+ GIT_COLOR_BLUE, ref,
GIT_COLOR_RESET);
+ else
+ strbuf_addf(stat, [%s] , ref);
+ }
return;
}
- if (show_upstream_ref)
+ if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
+ if (want_color(branch_use_color))
+ snprintf(fancy, sizeof(fancy), %s%s%s,
+ GIT_COLOR_BLUE, ref, GIT_COLOR_RESET);
+ else
+ strncpy(fancy, ref, sizeof(fancy));
+ }
+
if (!ours) {
if (ref)
- strbuf_addf(stat, _([%s: behind %d]), ref, theirs);
+ strbuf_addf(stat, _([%s: behind %d]), fancy, theirs);
else
strbuf_addf(stat, _([behind %d]), theirs);
} else if (!theirs) {
if (ref)
- strbuf_addf(stat, _([%s: ahead %d]), ref, ours);
+ strbuf_addf(stat, _([%s: ahead %d]), fancy, ours);
else
strbuf_addf(stat, _([ahead %d]), ours);
} else {
if (ref)
strbuf_addf(stat, _([%s: ahead %d, behind %d]),
- ref, ours, theirs);
+ fancy, ours, theirs);
else
strbuf_addf(stat, _([ahead %d, behind %d]),
ours, theirs);
--
1.8.2.1.641.gd16d37a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
