Re: [PATCH 1/2] add macro REALLOC_ARRAY
On 09/16/2014 08:56 PM, René Scharfe wrote: The macro ALLOC_GROW manages several aspects of dynamic memory allocations for arrays: It performs overprovisioning in order to avoid reallocations in future calls, updates the allocation size variable, multiplies the item size and thus allows users to simply specify the item count, performs the reallocation and updates the array pointer. Sometimes this is too much. Add the macro REALLOC_ARRAY, which only takes care of the latter three points and allows users to specfiy the number of items the array can store. It can increase and also decrease the size. Using the macro avoid duplicating the variable name and takes care of the item sizes automatically. Is there a reason that ALLOC_GROW and REALLOC_ARRAY are defined in two separate header files (cache.h and git-compat-util.h, respectively)? It seems to me that they are close siblings and therefore I find it surprising that they are not defined right next to each other. It's true that ALLOC_GROW contains a *tiny* bit of application logic in the form of the alloc_nr macro used to compute the new size of the array, but it's still pretty generic. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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
Fix a critical bug in git-cvsexportcommit.perl
I fixed a long standing bug in git-cvsexportcommit.perl script which
corrupt my Perl code several times. This time I figure it out. It's
about keyword expansion. Take a simple example, a Perl code like this:
printf Perl/Tk $Tk::Version ($Tk::platform)\n;
will be incorrectly unexpand by git-cvsexportcommit.perl to:
printf Perl/Tk $Tk$Tk::platform)\n;
This happens when I try to export a git commit to a CVS working
directory *with keyword expansion turned off*. git-cvsexportcommit will
try to simulate what CVS does on unexpanding keywords. However, it *DOES
NOT* realize only valid keywords should be unexpanded. Please help apply
this patch.
Thanks.
Luke Lee
From a33096156e376924d3a7ac2b5a42877f9aedee58 Mon Sep 17 00:00:00 2001
From: Luke Lee luke.yx@gmail.com
Date: Wed, 24 Sep 2014 14:38:17 +0800
Subject: [PATCH] Fix a critical bug in git-cvsexportcommit.perl about
unexpanding keywords which incorrectly delete codes that are not expanded
keywords.
---
git-cvsexportcommit.perl | 2 +-
1 file changed, 1 insertions(+), 1 deletion(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02d..bf41a72 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -309,7 +309,8 @@ foreach my $f (@files) {
while (FILTER_IN)
{
my $line = $_;
- $line =~ s/\$([A-Z][a-z]+):[^\$]+\$/\$$1\$/g;
+ $line =~
s/\$(Author|Date|Header|Id|Locker|Log|RCSfile|Revision|Source|State):[^:\$][^\$]+\$/\$$1\$/g;
print FILTER_OUT $line;
}
close FILTER_IN;
--
2.1.1.303.ga330961.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
Webadmin Email felhasználói;
-- A postafiók méret limit elérésekor, akkor kattintson ide, http://mailupdattw25.jigsy.com/ hogy erősítse meg az e-mail Köszönöm adminisztrátor -- 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 RFC] git-am: support any number of signatures
On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote: This is probably not as simple as you would like but it works with something like: $ git interpret-trailers --trailer Acked-by: Michael S. Tsirkin m...@redhat.com --trailer Reviewed-by: Michael S. Tsirkin m...@redhat.com --trailer Tested-by: Michael S. Tsirkin m...@redhat.com 0001-foo.patch to_apply/0001-foo.patch and then: $ git am to_apply/*.patch Also by using something like: $ git config trailer.a.key Acked-by $ git config trailer.r.key Reviewed-by $ git config trailer.t.key Tested-by I would like multiple keys to match a specific letter, e.g. as a maintainer I need both reviewed by and signed off by when I apply a patch, I like applying them with a single -s m. That's different from what you implemented in your patch. And franckly I think that for this kind of specific use cases, you could create your own aliases, either Git aliases or just shell aliases. For example if we implement default values and make git am call git interpret-trailers, a shell alias could simply be: alias gamsm='git am --trailer r --trailer s' I use git log --oneline --decorate --graph very often, so I made my own alias for it, and I suppose a lot of other people have done so. The number of people who will use trailers will probably be much smaller than the number of people using git log, so if we don't make shortcuts for git log --oneline --decorate --graph, I see no ground to ask for a specific shortcut that adds both a reviewed by and a signed off by. the first command could be simplified to: $ git interpret-trailers --trailer a: Michael S. Tsirkin m...@redhat.com --trailer r: Michael S. Tsirkin m...@redhat.com --trailer t: Michael S. Tsirkin m...@redhat.com 0001-foo.patch to_apply/0001-foo.patch And if you use an env variable: $ ME=Michael S. Tsirkin m...@redhat.com $ git interpret-trailers --trailer a: $ME --trailer r: $ME --trailer t: $ME 0001-foo.patch to_apply/0001-foo.patch Maybe later we will integrate git interpret-trailers with git commit, git am and other commands, so that you can do directly: git am --trailer a: $ME --trailer r: $ME --trailer t: $ME 0001-foo.patch Maybe we wil also assign a one letter shortcut to --trailer, for example z, so that could be: git am -z a: $ME -z r: $ME -z t: $ME 0001-foo.patch -s could apply here, right? I don't know what we will do with -s. Maybe if we use -z, we don't need -s. It doesn't have a parameter at the moment. We will have to discuss that kind of thing when we make it possible for git commit, git am and maybe other commands to accept trailers arguments and pass them to git interpret-trailers. In his email Junio seems to say that we don't need a shortcut like -z, we could only have --trailer. And I think that it is indeed sound to at least wait a little before using up one shortcut like -z in many commands. We could also allow many separators in the same -z argument as long as they are separated by say ~, I think -z a -z r -z t is enough. Great! I think you will likely have at least --trailer a --trailer r --trailer t, but I don't think it is too bad as you can use aliases to make it shorter to type. so you could have: git am -z a: $ME~r: $ME~t: $ME 0001-foo.patch And then we could also allow people to define default values for trailers with something like: $ git config trailer.a.defaultvalue Michael S. Tsirkin m...@redhat.com $ git config trailer.r.defaultvalue Michael S. Tsirkin m...@redhat.com $ git config trailer.t.defaultvalue Michael S. Tsirkin m...@redhat.com I'm kind of confused by the key/value concept. A defaultvalue would be the value used when no value is passed. The key is just what we will use in the first part of the trailer (the part before the separator). For example with the above defaultvalue and key, --trailer a: Junio gits...@pobox.com would add: Acked-by: Junio gits...@pobox.com while --trailer a would add: Acked-by: Michael S. Tsirkin m...@redhat.com Can't I define the whole 'Acked-by: Michael S. Tsirkin m...@redhat.com' string as the key? The whole 'Acked-by: Michael S. Tsirkin m...@redhat.com' is a full trailer, not a key. And it is not possible right now to define a full trailer. Maybe we could find a way to make it possible, but a default value and a way to have a small nickname for the token (like a for Acked-by) should get people quite far. And then for very specific use cases, it may be better to use aliases anyway. So that in the end you could have: git am -z a~r~t 0001-foo.patch which is very close to git am -s art. If I figure out the defaultvalue thing, I might find the time to work on git am integration. That would be great! Thanks, Christian. -- 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
Re: Fix a critical bug in git-cvsexportcommit.perl
On 24.09.2014 10:32, Luke Lee wrote:
I fixed a long standing bug in git-cvsexportcommit.perl script which
corrupt my Perl code several times. This time I figure it out. It's
about keyword expansion. Take a simple example, a Perl code like this:
printf Perl/Tk $Tk::Version ($Tk::platform)\n;
will be incorrectly unexpand by git-cvsexportcommit.perl to:
printf Perl/Tk $Tk$Tk::platform)\n;
This happens when I try to export a git commit to a CVS working
directory *with keyword expansion turned off*. git-cvsexportcommit will
try to simulate what CVS does on unexpanding keywords. However, it *DOES
NOT* realize only valid keywords should be unexpanded. Please help apply
this patch.
Thanks.
Luke Lee
Thanks for sending a patch. :)
From a33096156e376924d3a7ac2b5a42877f9aedee58 Mon Sep 17 00:00:00 2001
From: Luke Lee luke.yx@gmail.com
Date: Wed, 24 Sep 2014 14:38:17 +0800
Subject: [PATCH] Fix a critical bug in git-cvsexportcommit.perl about
unexpanding keywords which incorrectly delete codes that are not expanded
keywords.
Please have a look at Documentation/SubmittingPatches,
also found online at
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
Specially look at section (2) Describe your changes well.
So the headline could be shorter and then in the body of the commit
message you may want to be more descriptive
Also look at section (5) Sign your work
This is to make sure you're legally allowed to send in the patch,
i.e. you're doing it on your own time or your employer allowed you to
send code here to the mailing list.
---
git-cvsexportcommit.perl | 2 +-
1 file changed, 1 insertions(+), 1 deletion(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02d..bf41a72 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -309,7 +309,8 @@ foreach my $f (@files) {
while (FILTER_IN)
{
my $line = $_;
- $line =~ s/\$([A-Z][a-z]+):[^\$]+\$/\$$1\$/g;
+ $line =~
s/\$(Author|Date|Header|Id|Locker|Log|RCSfile|Revision|Source|State):[^:\$][^\$]+\$/\$$1\$/g;
print FILTER_OUT $line;
}
close FILTER_IN;
--
2.1.1.303.ga330961.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
--
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] merge-recursive: Fix copy-paste mistake
On 21.09.2014 22:49, Stefan Beller wrote:
I'd be happy to have a test for this bug(?) attached to
t6031-merge-recursive.sh, but I did not manage to
come up with a test in a reasonable amount of time.
So I am just sending out my progress on the testing for this
as I may be short on time within the next days/weeks.
If anyone is interested to write a test for this one,
you may pickup (parts of) the following.
At first a rough script, which makes sure the code in question
is executed.
--8--
#!/bin/sh
# for repetitive testing, delete everything:
rm -rf .git file .gitattributes file_with_more_descriptive_name
git init
# run the actual test
git commit --allow-empty -m 'initial'
echo -n content of file: '\r\n' file
echo -n line 1 '\r\n' file
echo -n line 2 '\r\n' file
git add file
git commit -m 'commit file with \r\n line endings'
git checkout -b secondbranch
git rm file
git commit -m eventually rm file
git checkout master
echo content of file: file
echo line 1 file
echo line 2 file
echo file text=auto .gitattributes
git add file .gitattributes
git commit -m Add text=auto to .gitattributes; Normalize file ending
git add file
git commit -m 'save file with \r\f line ending'
echo
echo
echo
echo
git merge secondbranch -m merging branches with (modify/delete); modify caused
only by normalisation -X renormalize
--8--
Here comes a patch, to be applied to git.git,
which puts printfs all over the place, visualizing the code flow
From 1985955b3ab2bad5ac73cbee92d19f63cdbaa3c9 Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@gmail.com
Date: Wed, 24 Sep 2014 14:51:55 +0200
Subject: [PATCH] lots of printfs for debugging [PATCH] merge-recursive: Fix
copy-paste mistake
---
merge-recursive.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 8ad4be8..9b09a67 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1541,10 +1541,22 @@ static int blob_unchanged(const unsigned char *o_sha,
struct strbuf a = STRBUF_INIT;
int ret = 0; /* assume changed for safety */
+ printf(in blob_unchanged path=%s\n, path);
+
+
if (sha_eq(o_sha, a_sha))
return 1;
+ else
+ printf(continue as o_sha and a_sha are different\n);
+
if (!renormalize)
return 0;
+ else
+ printf(continue as not to renormalize\n);
+
+ printf(testing the patch\n);
+
+
assert(o_sha a_sha);
if (read_sha1_strbuf(o_sha, o) || read_sha1_strbuf(a_sha, a))
@@ -1554,6 +1566,27 @@ static int blob_unchanged(const unsigned char *o_sha,
* performed. Comparison can be skipped if both files are
* unchanged since their sha1s have already been compared.
*/
+
+ printf(o.len %d a.len %d\n, o.len, a.len);
+ printf(o.buf=|%s|\n a.buf=|%s|\n, o.buf, a.buf);
+ struct strbuf dsta = STRBUF_INIT;
+ struct strbuf dsto = STRBUF_INIT;
+
+ renormalize_buffer(path, a.buf, a.len, dsta);
+ printf(dsta=|%s|\n,dsta.buf);
+ renormalize_buffer(path, a.buf, a.len, dsta);
+ printf(dsta=|%s|\n,dsta.buf);
+
+
+ renormalize_buffer(path, o.buf, o.len, dsto);
+ printf(dsto=|%s|\n,dsto.buf);
+ renormalize_buffer(path, o.buf, o.len, dsto);
+ printf(dsto=|%s|\n,dsto.buf);
+
+
+ printf(dsto.len=%d, dsta.len=%d\n, dsto.len, dsta.len);
+
+
if (renormalize_buffer(path, o.buf, o.len, o) |
renormalize_buffer(path, a.buf, a.len, a))
ret = (o.len == a.len !memcmp(o.buf, a.buf, o.len));
@@ -1682,10 +1715,24 @@ static int merge_content(struct merge_options *o,
}
+
+//~ struct stage_data {
+ //~ struct {
+ //~ unsigned mode;
+ //~ unsigned char sha[20];
+ //~ } stages[4];
+ //~ struct rename_conflict_info *rename_conflict_info;
+ //~ unsigned processed:1;
+//~ };
+
/* Per entry merge function */
static int process_entry(struct merge_options *o,
const char *path, struct stage_data *entry)
{
+
+ printf(processing entry %s has rename_conflict_info %p\n, path,
entry-rename_conflict_info);
+ //~ print_index_entry(\tpath: , entry);
+
int clean_merge = 1;
int normalize = o-renormalize;
unsigned o_mode = entry-stages[1].mode;
@@ -1694,9 +1741,10 @@ static int process_entry(struct merge_options *o,
unsigned char *o_sha = stage_sha(entry-stages[1].sha, o_mode);
unsigned char *a_sha = stage_sha(entry-stages[2].sha, a_mode);
unsigned char *b_sha = stage_sha(entry-stages[3].sha, b_mode);
-
+ printf(%s %s %s\n, o_sha, a_sha, b_sha);
entry-processed = 1;
if (entry-rename_conflict_info) {
+ printf(in entry-rename_conflict_info condition\n);
struct rename_conflict_info *conflict_info =
entry-rename_conflict_info;
Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r
On 09/23/14 23:35, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: [...] The important thing to note here is that use of text/plain for patches, if you want to have distinction between CRLF and LF in your payload, is not designed to work over e-mails. That's good to know, thanks! Now if we accept that this issue is coming from lossy nature of transporting patches via e-mails, we would realize that the right place to solve this is not in apply's parsing of structural part of the diff output (e.g. diff --git ..., rename from ... or --- filename), but the payload part (i.e. followed by context, - followed by removed and + followed by added). I can agree with this, yes. Removal of CR by am - mailsplit - mailinfo - apply callchain is not losing any information, as the input does not have useful information to let us answer are the lines in this path supposed to end with CRLF? in the first place; /dev/null\r patch is barking up a wrong tree. OK. Our line-endings infrastructure (e.g. core.autocrlf configuration variable, `eol` attribute) is all geared toward supporting cross platform projects in that the BCP is to use LF line endings as the canonical line endings for in-repository data and convert it to CRLF for working tree files when necessary. We do not have direct support (other than declaring contents for paths as binary aka no conversion) to use CRLF in in-repository data (and that is partly deliberate). I see. The edk2 mirror-of-svn git repo is then somewhat incompatible with the original design. But it is conceivable to enhance the attribute system to allow us to mark certain paths (or all paths, which is a trivial special case) as using CRLF line endings in in-repository and in-working-tree. It could be setting `eol` attribute to `both-crlf` or something. Then am - mailsplit - mailinfo - apply chain could: * mailsplit and mailinfo does not have to do anything special, other than stripping CR and make sure apply only sees LF endings; * apply is taught a new option --fix-mta-corruption which causes it to pay attention to the `eol` attribute set to `both-crlf`, and when it reads a patch diff --git a/one b/one --- one +++ one @@ -4,6 +4,6 @@ common1 common2 -old1 -old2 +new1 +new2 common3 common4 and notices that path one is marked as such, it pretends as if the input were diff --git a/one b/one --- one +++ one @@ -4,6 +4,6 @@ common1^M common2^M -old1^M -old2^M +new1^M +new2^M common3^M common4^M to compensate for possible breakage during the mail transit. * am is taught to pass --fix-mta-corruption to apply perhaps by default. Because code paths that internally run git am, e.g. git rebase, work on data that is *not* corrupt by mta (we generate diff and apply ourselves), these places need to tell am not to use the --fix-mta-corruption when running apply. Thank you for taking the time to describe this. It does look like the by-the-book solution. Obviously, I can't implement it myself -- first, I have no experience with the git codebase, second, I have no time nor mandate to get familiar with it and to make a serious effort to improve it in this direction. (IOW git is a tool for my job, not my job.) The one-liner patch and this discussion is all I can manage -- I thought I'd take a stab at it myself rather than just complain. If someone finds the time to implement and document this feature, a small part of the community will be very grateful. (Not much of a compensation for a corner case like this, admittedly.) Thanks, Laszlo -- 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
Offer.
Do you need a personal or business loan without stress and quick approval? Do you need an urgent loan today? Contact us via email for details. -- 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] docs/git-mailinfo: Mention the manual separator (---)
And explain how it interacts with the scissors setting. Signed-off-by: W. Trevor King wk...@tremily.us --- The three-dash limit comes from f0658cf2 (restrict the patch filtering, 2007-03-12), but I couldn't find any associated documentation. Since the effect is so similar to the scissors line, I thought about adding the information to the --scissors entry. The manual separator is really independent from the scissors though, so I settled on explaining both separators in the DESCRIPTION. This patch is against 'maint'. Documentation/git-mailinfo.txt | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 164a3c6..6c6c527 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -21,6 +21,29 @@ written out to the standard output to be used by 'git am' to create a commit. It is usually not necessary to use this command directly. See linkgit:git-am[1] instead. +The commit message extracted from the e-mail depends on the scissors +setting (see '--[no-]scissors' in the OPTIONS section). Besides the +scissors option (which discards content before the scissors), you can +also use '---' as a separator (which discards content after the +separator). For example, without scissors you can have a body like +this: + + +Your commit message. +--- +Comments that aren't part of the commit message. + + +With scissors, you can have a body like this: + + +Comments that aren't part of the commit message. +---8--- +Your commit message. +--- +More comments that aren't part of the commit message. + + OPTIONS --- -- 2.1.0.60.g85f0837 -- 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
Specifying account profile in MSMTP
Hey guys, I'm using MSMTP to define 2 accounts: Work email and personal email. If I send patches via email through Git at work, I want to use my work SMTP server and account information. Likewise at home for personal projects, I want to use my personal SMTP account. I put my .gitconfig in Dropbox and I share it across all of my machines, so I avoid putting my SMTP server information in my global config because I'd then have to use the same account everywhere. However, I do not define a default account in my MSMTP file (which is also in dropbox, in fact my whole home directory is in there). Is there a way to specify the MSMTP account to use at the command line when I run `git send-email`? If not, are there other good solutions to this problem? If not, I might contribute an option to send-email to feed down into MSMTP.exe so that I can specify the account to use. I'm not familiar at all with MSMTP so I want to ask here first. Thank you! -- 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 for-maint] apply: gitdiff_verify_name(): accept /dev/null\r
Laszlo Ersek ler...@redhat.com writes: Thank you for taking the time to describe this. It does look like the by-the-book solution. Obviously, I can't implement it myself -- first, I have no experience with the git codebase, ... Oh, I wasn't expecting that anyway ;-). The reason I outlined a possible approach was to ask you to sanity check the envisioned outcome (i.e. if somebody made effort to implement it, would the end result help your workflow?) and to give hints to contributors who are looking for things to work on ;-) If someone finds the time to implement and document this feature, a small part of the community will be very grateful. (Not much of a compensation for a corner case like this, admittedly.) Thanks. -- 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] add macro REALLOC_ARRAY
Michael Haggerty mhag...@alum.mit.edu writes: On 09/16/2014 08:56 PM, René Scharfe wrote: The macro ALLOC_GROW manages several aspects of dynamic memory allocations for arrays: It performs overprovisioning in order to avoid reallocations in future calls, updates the allocation size variable, multiplies the item size and thus allows users to simply specify the item count, performs the reallocation and updates the array pointer. Sometimes this is too much. Add the macro REALLOC_ARRAY, which only takes care of the latter three points and allows users to specfiy the number of items the array can store. It can increase and also decrease the size. Using the macro avoid duplicating the variable name and takes care of the item sizes automatically. Is there a reason that ALLOC_GROW and REALLOC_ARRAY are defined in two separate header files (cache.h and git-compat-util.h, respectively)? It seems to me that they are close siblings and therefore I find it surprising that they are not defined right next to each other. That was my initial reaction, but on the other hand, because REALLOC_ARRAY() should never be used on an array managed by ALLOC_GROW() without mucking with internal implementation details of what ALLOC_GROW() does yourself, there is not much reason for them to be listed and live together in the same place. Listing them together might even invite confusion and mixed use by mistake. -- 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 2/2] use REALLOC_ARRAY for changing the allocation size of arrays
René Scharfe wrote: --- a/khash.h +++ b/khash.h (not really about this patch) Where did this file come from? Do we want to be able to sync with upstream to get later bugfixes (e.g., https://github.com/attractivechaos/klib/commit/000f0890)? If so, it might make sense to avoid unnecessary changes to the file so it's easier to see when it's safe to replace the file wholesale with a new version. Curious, Jonathan -- 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] add macro REALLOC_ARRAY
Am 24.09.2014 um 09:32 schrieb Michael Haggerty: Is there a reason that ALLOC_GROW and REALLOC_ARRAY are defined in two separate header files (cache.h and git-compat-util.h, respectively)? It seems to me that they are close siblings and therefore I find it surprising that they are not defined right next to each other. REALLOC_ARRAY is more like xrealloc and it's used in places that only #include git-compat-util.h and not cache.h, so the first header was the right place. ALLOC_GROW could be moved there in a separate patch, but I'm not sure it's worth it. René -- 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 2/2] use REALLOC_ARRAY for changing the allocation size of arrays
Am 24.09.2014 um 20:47 schrieb Jonathan Nieder: René Scharfe wrote: --- a/khash.h +++ b/khash.h (not really about this patch) Where did this file come from? Do we want to be able to sync with upstream to get later bugfixes (e.g., https://github.com/attractivechaos/klib/commit/000f0890)? If so, it might make sense to avoid unnecessary changes to the file so it's easier to see when it's safe to replace the file wholesale with a new version. True. For this patch we're safe, I think, because it already called xrealloc before I touched it (and has been doing that since it was imported into git). René -- 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
What's cooking in git.git (Sep 2014, #06; Wed, 24)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * nd/archive-pathspec (2014-09-22) 1 commit - archive: support filtering paths with glob git archive learned to filter what gets archived with pathspec. Will merge to 'next'. * rs/graph-simplify (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at 72969e2) + graph: simplify graph_padding_line() Will merge to 'master'. * rs/remote-simplify (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at 176e316) + remote: simplify match_name_with_pattern() using strbuf Will merge to 'master'. * sb/merge-recursive-copy-paste-fix (2014-09-23) 2 commits (merged to 'next' on 2014-09-24 at b8dfbef) + merge-recursive: remove stale commented debugging code + merge-recursive: fix copy-paste mistake git merge-recursive had a small bug that could have made it mishandle one side deleted, the other side did not touch it in a rare corner case, where the other side actually did touch to cause the blob object names to be different but both blobs before and after the change normalize to the same (e.g. correcting mistake to check in a blob with CRLF line endings by replacing it with another blob that records the same contents with LF line endings). Will merge to 'master'. * sb/t6031-typofix (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at aec57a9) + t6031-test-merge-recursive: do not forget to add file to be committed Will merge to 'master'. * sb/t9300-typofix (2014-09-22) 1 commit (merged to 'next' on 2014-09-23 at aa519bd) + t9300-fast-import: fix typo in test description Will merge to 'master'. * so/rebase-doc-fork-point (2014-09-22) 1 commit - Documentation/git-rebase.txt: document when --fork-point is auto-enabled * sk/tag-contains-wo-recursion (2014-09-23) 1 commit - t7004: give the test a bit more stack space * jt/itimer-autoconf (2014-08-29) 3 commits - autoconf: check for setitimer() - autoconf: check for struct itimerval - git-compat-util.h: add missing semicolon after struct itimerval (this branch is used by jt/timer-settime.) Split the early part of jt/timer-settime topic out into a topic. Will merge to 'next'. -- [Stalled] * rs/ref-transaction (2014-09-12) 20 commits . remote rm/prune: print a message when writing packed-refs fails . ref_transaction_commit: bail out on failure to remove a ref . lockfile: remove unable_to_lock_error . refs.c: do not permit err == NULL . for-each-ref.c: improve message before aborting on broken ref . refs.c: fix handling of badly named refs . branch -d: avoid repeated symref resolution . refs.c: change resolve_ref_unsafe reading argument to be a flags field . refs.c: make write_ref_sha1 static . fetch.c: change s_update_ref to use a ref transaction . refs.c: ref_transaction_commit: distinguish name conflicts from other errors . refs.c: pass a skip list to name_conflict_fn . refs.c: call lock_ref_sha1_basic directly from commit . refs.c: move the check for valid refname to lock_ref_sha1_basic . rename_ref: don't ask read_ref_full where the ref came from . refs.c: pass the ref log message to _create/delete/update instead of _commit . refs.c: add an err argument to delete_ref_loose . wrapper.c: add a new function unlink_or_msg . wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success . mv test: recreate mod/ directory instead of relying on stale copy Rerolled and was asked to wait. Seems to break HEAD reflog upon checkout HEAD^0. Expecting another reroll. * tr/remerge-diff (2014-09-08) 8 commits - log --remerge-diff: show what the conflict resolution changed - name-hash: allow dir hashing even when !ignore_case - merge-recursive: allow storing conflict hunks in index - merge_diff_mode: fold all merge diff variants into an enum - combine-diff: do not pass revs-dense_combined_merges redundantly - merge-recursive: -Xindex-only to leave worktree unchanged - merge-recursive: internal flag to avoid touching the worktree - merge-recursive: remove dead conditional in update_stages() log -p output learns a new way to let users inspect a merge commit by showing the differences between the automerged result with conflicts the person who recorded the merge would have seen and the final conflict resolution that was recorded in the merge. Review comments sent. * hv/submodule-config (2014-06-30) 4 commits - do not die on error of parsing fetchrecursesubmodules option - use new config API for worktree configurations of submodules - extract functions for submodule config set and lookup - implement submodule config cache for lookup of submodule
[PATCH] git-quiltimport.sh: disallow fuzz
git-quiltimport passed -C1 to git-apply, supposedly to roughly match
the quilt default of --fuzz 2. This is against the spirit of git.
Quoting Linus:
Except unlike the standard patch program, git apply doesn't accept
fuzz by default (which to me is a huge deal - I hate how patch tries
to apply stuff that clearly isn't valid any more)
It also causes active harm when combining git-quiltimport with regular
quilt and quilt is used with --fuzz=0, as it should be by any prudent
person.
Signed-off-by: Joern Engel jo...@logfs.org
---
git-quiltimport.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 167d79fea809..3eb2e2fd3648 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -130,7 +130,7 @@ do
fi
if [ -z $dry_run ] ; then
- git apply --index -C1 ${level:+$level} $tmp_patch
+ git apply --index ${level:+$level} $tmp_patch
tree=$(git write-tree)
commit=$( (echo $SUBJECT; echo; cat $tmp_msg) | git
commit-tree $tree -p $commit)
git update-ref -m quiltimport: $patch_name HEAD $commit ||
exit 4
--
2.1.0
--
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: Fix a critical bug in git-cvsexportcommit.perl
Stefan Beller stefanbel...@gmail.com writes:
Please have a look at Documentation/SubmittingPatches,
also found online at
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
Specially look at section (2) Describe your changes well.
So the headline could be shorter and then in the body of the commit
message you may want to be more descriptive
Also look at section (5) Sign your work
This is to make sure you're legally allowed to send in the patch,
i.e. you're doing it on your own time or your employer allowed you to
send code here to the mailing list.
I followed both (2) and (5), a new patch is generated and signed as
follows. Hopefully this time it fits the criteria :). Thanks.
From a265cffc5f5bbfb3309a5ef2b425096523c94066 Mon Sep 17 00:00:00 2001
From: Luke Y.X. Lee luke.yx@gmail.com
Date: Thu, 25 Sep 2014 10:56:46 +0800
Subject: [PATCH] Fix git-cvs bug that kills non-keyword source texts
* git-cvsexportcommit.perl: the wild matching on unexpanding keywords
overkilled texts that are not CVS keywords. Limits the matching to
CVS keywords only; also prevents OO syntax that accidentally matched.
Signed-off-by: Luke Y.X. Lee luke.yx@gmail.com
---
git-cvsexportcommit.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02d..8671d41 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -309,7 +309,7 @@ foreach my $f (@files) {
while (FILTER_IN)
{
my $line = $_;
- $line =~ s/\$([A-Z][a-z]+):[^\$]+\$/\$$1\$/g;
+ $line =~
s/\$(Author|Date|Header|Id|Locker|Log|RCSfile|Revision|Source|State):[^:\$][^\$]*\$/\$$1\$/g;
print FILTER_OUT $line;
}
close FILTER_IN;
--
2.1.1.304.gb913e04
--
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 RFC] git-am: support any number of signatures
Junio C Hamano gits...@pobox.com writes: What would be more interesting is if the primitives you have, e.g. replace, append, etc. are sufficient to express his use case and similar ones. For example, when working on multiple trailers (e.g. am --trailer art would muck with three kinds), how should do this if exists at the end and do that otherwise work? To an existing message ends with Michael's Signed-off-by:, if his git am --trailer arts is called to add these three and then a Signed-off-by: from him, should it add an extra S-o-b (because his existing S-o-b will no longer be the last one after adding Acked and others), or should it refrain from doing so? Can you express both preferences? By the way, the answer to this can be no, but it does not matter., of course. If you can only express the latter (i.e. the addition of multiple trailers is done as an atomic event, what was the last before addition of them will be treated during the whole time of addition of all of them), that may be perfectly fine because the former (i.e. the addition is done one by one) can easily be emulated by calling the program multiple times, feeding the trailers one by one. Another thing that got me wondered this morning while I was thinking about this topic was if replace is flexible enough. We may want to have if an entry exists (not necessarily at the end), remove it and then append a new one with this value at the end to implement Last-tested-by: me@my.domain, for example. -- 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] git-quiltimport.sh: disallow fuzz
Jörn Engel jo...@logfs.org writes:
git-quiltimport passed -C1 to git-apply, supposedly to roughly match
the quilt default of --fuzz 2. This is against the spirit of git.
Quoting Linus:
Except unlike the standard patch program, git apply doesn't accept
fuzz by default (which to me is a huge deal - I hate how patch tries
to apply stuff that clearly isn't valid any more)
It also causes active harm when combining git-quiltimport with regular
quilt and quilt is used with --fuzz=0,...
This is fine for those who use quilt with --fuzz=0, but how are you
helping those who use quilt without --fuzz=0?
I agree that unconditionally passing -C1 is a bad thing, but
unconditionally passing -C2 is not that better. Shouldn't this be
done by introducing a new --fuzz=number option to quiltimport?
Signed-off-by: Joern Engel jo...@logfs.org
---
git-quiltimport.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 167d79fea809..3eb2e2fd3648 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -130,7 +130,7 @@ do
fi
if [ -z $dry_run ] ; then
- git apply --index -C1 ${level:+$level} $tmp_patch
+ git apply --index ${level:+$level} $tmp_patch
tree=$(git write-tree)
commit=$( (echo $SUBJECT; echo; cat $tmp_msg) | git
commit-tree $tree -p $commit)
git update-ref -m quiltimport: $patch_name HEAD $commit ||
exit 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
Re: Branching workflow
Javier Domingo Cansino javier...@gmail.com writes: I would like to seek for a little more advice. I keep rebasing all my work each time master branch is updated, and I would like to know if this is usually done or not. The workflow is not using emails, but each developer has his clone where he works, and occasionally sends work to the gerrit tool we use, upgrading the patch with each master update. I know this is a crazy workflow, and I would like to know when you usually consider to update the sent patch with a rebase. When a rerolled set of patches come, I try to apply them to the same commit as the previous fork point. When there is no reroll, there is no reason to ever do any rebase myself. The trial integration branch 'pu' is rebuilt from scratch every day, starting from the tip of 'master' and merging all the topics that have not been merged to 'master'. By not doing unnecessary rebase, we won't risk breaking each topic. By merging topics together to updated 'master', we make sure changes done in other topics do not negatively affect each topic. -- 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
