[PATCH 0/2] Another minor cleanup involving string_lists
Nothing really earthshattering here. But it's funny how every time I look closely at a site where I think string_lists could be used, I find problems with the old code. In this case is_absolute_path() is called with an argument that is not a null-terminated string, which is incorrect (though harmless because the function only looks at the first two bytes of the string). Another peculiarity of the (old and new) code is that it rejects comments even in paths taken from the colon-separated environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES. The fix would be to change link_alt_odb_entries() to take a string_list and let the callers strip out comments when appropriate. But it didn't seem worth the extra code. Michael Haggerty (2): link_alt_odb_entries(): use string_list_split_in_place() link_alt_odb_entries(): take (char *, len) rather than two pointers sha1_file.c | 50 ++ 1 file changed, 22 insertions(+), 28 deletions(-) -- 1.8.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
[PATCH 2/2] link_alt_odb_entries(): take (char *, len) rather than two pointers
Change link_alt_odb_entries() to take the length of the alt
parameter rather than a pointer to the end of the alt string. This
is the more common calling convention and simplifies the code a tiny
bit.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index c352413..40b2329 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -317,7 +317,7 @@ static int link_alt_odb_entry(const char *entry, const char
*relative_base, int
return 0;
}
-static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
+static void link_alt_odb_entries(const char *alt, int len, int sep,
const char *relative_base, int depth)
{
struct string_list entries = STRING_LIST_INIT_NODUP;
@@ -330,7 +330,7 @@ static void link_alt_odb_entries(const char *alt, const
char *ep, int sep,
return;
}
- alt_copy = xmemdupz(alt, ep - alt);
+ alt_copy = xmemdupz(alt, len);
string_list_split_in_place(entries, alt_copy, sep, -1);
for (i = 0; i entries.nr; i++) {
const char *entry = entries.items[i].string;
@@ -371,7 +371,7 @@ void read_info_alternates(const char * relative_base, int
depth)
map = xmmap(NULL, mapsz, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- link_alt_odb_entries(map, map + mapsz, '\n', relative_base, depth);
+ link_alt_odb_entries(map, mapsz, '\n', relative_base, depth);
munmap(map, mapsz);
}
@@ -385,7 +385,7 @@ void add_to_alternates_file(const char *reference)
if (commit_lock_file(lock))
die(could not close alternates file);
if (alt_odb_tail)
- link_alt_odb_entries(alt, alt + strlen(alt), '\n', NULL, 0);
+ link_alt_odb_entries(alt, strlen(alt), '\n', NULL, 0);
}
void foreach_alt_odb(alt_odb_fn fn, void *cb)
@@ -409,7 +409,7 @@ void prepare_alt_odb(void)
if (!alt) alt = ;
alt_odb_tail = alt_odb_list;
- link_alt_odb_entries(alt, alt + strlen(alt), PATH_SEP, NULL, 0);
+ link_alt_odb_entries(alt, strlen(alt), PATH_SEP, NULL, 0);
read_info_alternates(get_object_directory(), 0);
}
--
1.8.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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
Felipe Contreras venit, vidit, dixit 02.11.2012 17:09: On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38: On 11/01/2012 02:46 PM, René Scharfe wrote: Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. It goes further back than that. Suum cuique pulchrum est (To each his own is a beautiful thing) is a latin phrase said to be used frequently in the roman senate when senators politely agreed to disagree and let a vote decide the outcome rather than debating further. Please don't let the twisted views of whatever nazi idiot thought it meant you may have the wrong faith and therefore deserve to die, so you shall pollute it. The original meaning is both poetic and democratic, and I firmly believe most people have the original meaning to the fore of their mind when using it. After all, very few people knowingly quote nazi concentration camp slogans. In fact, many German terms and words are forbidden area since Nazi times, but I don't think this one carries the same connotation. But that is a side track. Collaboration (and code review is a form of collaboration) requires communication. The linked code of conduct pages describe quite well how to ensure a productive environment in which everyone feels comfortable communicating and collaborating. Yes, but that's assuming we want everyone to feel comfortable communicating and collaborating. I put everyone in quotes because you can never reach 100%, so everyone means almost everyone. Undeniably, the answers in this and the other threads show that on the git mailing list, everyone wants everyone to feel comfortable communicating and collaborating. I cite again the example of the Linux kernel, where certainly not everyone feels that way. But somehow It's a different list with different standards and tone, so it doesn't really matter for our list. That being said: they manage to be perhaps the most successful software project in history. And I would argue even more: it's _because_ not everyone feels comfortable, it's because ideas and code are criticized freely, and because only the ones that do have merit stand. If you are able to take criticism, and you are not emotionally and personally attacked to your code and your ideas, you would thrive in this environment. If you don't want your precious little baby code to fight against the big guys, then you shouldn't send it out to the world. For one thing, contributors on the kernel list are open to technical arguments, and that includes the arguments of others; just like we are here. On the other hand, you seem to rebuke any (most) technical argument in harsh words as if it were a personal attack; at least that's how your answers come across to me (and apparently others). That really makes it difficult for most of us here to argue with you technically, which is a pity. That lack of openness for the arguments of others would make your life difficult on the kernel list also. A completely different issue is that of language. You talk German on a German list and English on an international list. You talk kernel English on the kernel list, which is full of words and phrases you would never use in a normal social setting where you talk to people in person; it would be completely unacceptable. Here on the Git list, we prefer to talk like in a normal, albeit colloquial social setting. If you're open for advice: just imagine talking to the people here in person, to colleagues across your desk, and you have a good guideline. And no, using the same or similar language does not make us the same at all. Using the same language is the natural prerequisite for successful communication. Felipe, please try to see the efforts many of us are making here in order to keep you as a contributor, and reward it by accepting the advice to revise your language: colleague to colleague. Michael -- 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: git-p4 clone @all error
Hi, Here is my import : Importing from //depot@all into X Initialized empty Git repository in /home/arthur/projets_git/X/X/.git/ Importing revision 4258 (43%) Importing new branch depot/DEV_DATA Resuming with change 4258 Importing revision 5828 (63%) Importing new branch depot/RELEASE_1.0 Resuming with change 5828 Importing revision 7720 (88%) Importing new branch depot/RELEASE_1.0.0 Resuming with change 7720 Importing revision 8588 (100%) Updated branches: DEV_DATA RELEASE_1.0 MAINLINE/02_SubSystem/10_ARINC_429 MAINLINE RELEASE_1.0.0 fast-import failed: error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 git-fast-import statistics: - Alloc'd objects: 17 Total objects: 169644 (195421 duplicates ) blobs :92182 (186294 duplicates 74565 deltas) trees :70889 ( 9127 duplicates 57686 deltas) commits: 6573 ( 0 duplicates 0 deltas) tags :0 ( 0 duplicates 0 deltas) Total branches: 8 ( 8 loads ) marks: 1024 ( 0 unique) atoms: 19603 Memory total: 19217 KiB pools: 12576 KiB objects: 6640 KiB - pack_report: getpagesize()= 4096 pack_report: core.packedGitWindowSize = 33554432 pack_report: core.packedGitLimit = 268435456 pack_report: pack_used_ctr= 19803 pack_report: pack_mmap_calls = 65 pack_report: pack_open_windows= 10 / 11 pack_report: pack_mapped = 257715823 / 268009874 - Import crash after importing revision, my import have not files -- View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570575.html Sent from the git mailing list archive at Nabble.com. -- 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
git log --graph --oneline - false parent-child visualization
Hello, the combination of --graph and --oneline sometimes produces output which is -- at least for me -- not clear about parent-child relation between commits. I noticed it when using with --simplify-by-decoration switch but it should not be specific to the use of this switch. See this example output (git version 1.7.11.3) | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet | |_|/ |/| | | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit | | |/ | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore | | | * d623246 (origin/branchD) Ut enim ad minim veniam | | |/ | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris | | |/ Here it seems commit c4d6b9a is based on d623246. But when the format is more-than-oneline (or when checked with gitk), it is clear there is no relation between commits c4d6b9a and d623246. | | | * commit eead15f (origin/branchA) | |_|/ Author: John Doe john@example.net |/| | | | | Lorem ipsum dolor sit amet | | | | | | * commit 8da3b9f (origin/branchB) | | |/ Author: John Doe john@example.net | | | | | | Consectetur adipisicing elit | | | | | | * commit c4d6b9a (origin/branchC) | | | Author: John Doe john@example.net | | | | | | Sed do eiusmod tempor incididunt ut labore | | | | | | * commit d623246 (origin/branchD) | | |/ Author: John Doe john@example.net | | | | | | Ut enim ad minim veniam | | | | | | * commit 458d305 (origin/branchE) | | |/ Author: John Doe john@example.net | | | | | | Quis nostrud exercitation ullamco laboris | | | Correct output produced with --oneline switch should output an extra newline when commit has no parent listed: | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet | |_|/ |/| | | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit | | |/ | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore | | | | | | * d623246 (origin/branchD) Ut enim ad minim veniam | | |/ | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris | | |/ Best Regards, Martin -- 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: Support for a series of patches, i.e. patchset or changeset?
Eric Miao venit, vidit, dixit 05.11.2012 03:26: Hi All, Does anyone know if git has sort of support for a series of patches, i.e. a patchset or changeset? So whenever we know the SHA1 id of a single patch/commit, we know the patchset it belongs to. This is normal when we do big changes and split that into smaller pieces and doing only one simple thing in a single commit. This will be especially useful when tracking and cherry-picking changes, i.e. monitoring on the changes of some specific files, and if a specific patch is interesting, we may want to apply the whole changeset, not only that specific one. First of all, if you know the sha1 of a commit, then all its ancestors are determined by that. If you want to describe a set of patches, say based on rev1 and leading up to rev2, then the expression rev2 ^rev1 describes that set uniquely. Often you can do without ^rev1, e.g. if you know that all patch series are developed bases on origin/master, then specifying rev2 is enough as git rev-list rev2 ^origin/master will give you all commits in the series (unless they have been integrated, i.e. merged). Or are you thinking about patches independent of a base? Cheers, Michael -- 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: Support for a series of patches, i.e. patchset or changeset?
The problem is, most cases we have no idea of the base rev1, and commit rev2 which it's leading up to. E.g. for a single patch which is between commit rev1..rev2, how do we find out rev1 and rev2. On Mon, Nov 5, 2012 at 9:39 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Eric Miao venit, vidit, dixit 05.11.2012 03:26: Hi All, Does anyone know if git has sort of support for a series of patches, i.e. a patchset or changeset? So whenever we know the SHA1 id of a single patch/commit, we know the patchset it belongs to. This is normal when we do big changes and split that into smaller pieces and doing only one simple thing in a single commit. This will be especially useful when tracking and cherry-picking changes, i.e. monitoring on the changes of some specific files, and if a specific patch is interesting, we may want to apply the whole changeset, not only that specific one. First of all, if you know the sha1 of a commit, then all its ancestors are determined by that. If you want to describe a set of patches, say based on rev1 and leading up to rev2, then the expression rev2 ^rev1 describes that set uniquely. Often you can do without ^rev1, e.g. if you know that all patch series are developed bases on origin/master, then specifying rev2 is enough as git rev-list rev2 ^origin/master will give you all commits in the series (unless they have been integrated, i.e. merged). Or are you thinking about patches independent of a base? Cheers, Michael -- 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 v4 00/13] New remote-hg helper
Felipe Contreras venit, vidit, dixit 02.11.2012 19:01:
On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Nov 2, 2012 at 3:48 PM, Jeff King p...@peff.net wrote:
On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:
Turns out msysgit's remote-hg is not exporting the whole repository,
that's why it's faster =/
It seems the reason is that it would only export to the point where
the branch is checked out. After updating the to the tip I noticed
there was a performance difference.
I investigated and found two reasons:
1) msysgit's version doesn't export files twice, I've now implemented the
same
2) msysgit's version uses a very simple algorithm to find out file changes
This second point causes msysgit to miss some file changes. Using the
same algorithm I get the same performance, but the output is not
correct.
Do you have a test case that demonstrates this? It would be helpful for
reviewers, but also helpful to msysgit people if they want to fix their
implementation.
Cloning the mercurial repo:
% hg log --stat -r 131
changeset: 131:c9d51742471c
parent: 127:44538462d3c8
user:j...@edge2.net
date:Sat May 21 11:35:26 2005 -0700
summary: moving hgweb to mercurial subdir
hgweb.py | 377
--
mercurial/hgweb.py | 377
++
2 files changed, 377 insertions(+), 377 deletions(-)
% git show --stat 1f9bcfe7cc3d7af7b4533895181acd316ce172d8
commit 1f9bcfe7cc3d7af7b4533895181acd316ce172d8
Author: j...@edge2.net none@none
Date: Sat May 21 11:35:26 2005 -0700
moving hgweb to mercurial subdir
mercurial/hgweb.py | 377
++
1 file changed, 377 insertions(+)
I talked with some people in #mercurial, and apparently there is a
concept of a 'changelog' that is supposed to store these changes, but
since the format has changed, the content of it is unreliable. That's
not a big problem because it's used mostly for reporting purposes
(log, query), not for doing anything reliable.
Is the changelog stored in the repo (i.e. generated by the hg version at
commit time) or generated on the fly (i.e. generated by the hg version
at hand)? See also below.
To reliably see the changes, one has to compare the 'manifest' of the
revisions involved, which contain *all* the files in them.
'manifest' == '(exploded) tree', right? Just making sure my hg fu is not
subzero.
That's what I was doing already, but I found a more efficient way to
do it. msysGit is using the changelog, which is quite fast, but not
reliable.
Unfortunately while going trough mercurial's code, I found an issue,
and it turns out that 1) is not correct.
In mercurial, a file hash contains also the parent file nodes, which
means that even if two files have the same content, they would not
have the same hash, so there's no point in keeping track of them to
avoid extracting the data unnecessarily, because in order to make sure
they are different, you need to extract the data anyway, defeating the
purpose.
Do I understand correctly that neither the msysgit version nor yours can
detect duplicate blobs (without requesting them) because of that sha1 issue?
I'm really wondering why a file blob hash carries its history along in
the sha1. This appears completely strange to gitters (being brain washed
about content tracking), but may be due to hg's extensive use of
delta, or really: delta chains (which do have their merit on the server
side).
Which means mercurial doesn't really behave as one would expect:
# add files with the same content
$ echo a a
$ hg ci -Am adda
adding a
$ echo a a
$ hg ci -m changea
$ echo a a
$ hg st --rev 0
$ hg ci -m reverta
$ hg log -G --template '{rev} {desc}\n'
@ 2 reverta
|
o 1 changea
|
o 0 adda
# check the difference between the first and the last revision
$ hg st --rev 0:2
M a
$ hg cat -r 0 a
a
$ hg cat -r 2 a
a
That is really scary. What use is hg stat --rev then? Not blaming you
for hg, of course.
On that tangent, I just noticed recently that hg has no python api.
Seriously [1]. They even tell us not to use the internal python api.
msysgit has been lacking support for newer hg, and you've had to add
support for older versions (hg 1.9 will be around on quite some
stable/LTS/EL distro releases) after developing on newer/current ones.
I'm wondering how well that scales in the long term (telling from
git-svn experience: it does not scale well), or whether using some
stable api like 'hgapi' would be a huge bottleneck.
Cheers,
Michael
[1] http://mercurial.selenic.com/wiki/MercurialApi
Really funny to see they recommend the command line as api ;)
--
To
Re: git log --graph --oneline - false parent-child visualization
martyone venit, vidit, dixit 05.11.2012 13:57: Hello, the combination of --graph and --oneline sometimes produces output which is -- at least for me -- not clear about parent-child relation between commits. I noticed it when using with --simplify-by-decoration switch but it should not be specific to the use of this switch. See this example output (git version 1.7.11.3) | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet | |_|/ |/| | | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit | | |/ | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore | | | * d623246 (origin/branchD) Ut enim ad minim veniam | | |/ | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris | | |/ Here it seems commit c4d6b9a is based on d623246. But when the format is more-than-oneline (or when checked with gitk), it is clear there is no relation between commits c4d6b9a and d623246. | | | * commit eead15f (origin/branchA) | |_|/ Author: John Doe john@example.net |/| | | | | Lorem ipsum dolor sit amet | | | | | | * commit 8da3b9f (origin/branchB) | | |/ Author: John Doe john@example.net | | | | | | Consectetur adipisicing elit | | | | | | * commit c4d6b9a (origin/branchC) | | | Author: John Doe john@example.net | | | | | | Sed do eiusmod tempor incididunt ut labore | | | | | | * commit d623246 (origin/branchD) | | |/ Author: John Doe john@example.net | | | | | | Ut enim ad minim veniam | | | | | | * commit 458d305 (origin/branchE) | | |/ Author: John Doe john@example.net | | | | | | Quis nostrud exercitation ullamco laboris | | | Correct output produced with --oneline switch should output an extra newline when commit has no parent listed: | | | * eead15f (origin/branchA) Lorem ipsum dolor sit amet | |_|/ |/| | | | | * 8da3b9f (origin/branchB) Consectetur adipisicing elit | | |/ | | | * c4d6b9a (origin/branchC) Sed do eiusmod tempor incididunt ut labore | | | | | | * d623246 (origin/branchD) Ut enim ad minim veniam | | |/ | | | * 458d305 (origin/btanchE) Quis nostrud exercitation ullamco laboris | | |/ Best Regards, Martin Yes, you have the same problem when you simply have two disjoint branches: They're listed concatenated. The problem is that log --graph uses the single symbol * for many different cases, independent of the number of ingoing or outgoing lines. There are two solutions: - use more spacing - use more symbols (like tig does) and stay compact Feel free to experiment ;) Michael -- 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: Support for a series of patches, i.e. patchset or changeset?
Eric Miao venit, vidit, dixit 05.11.2012 15:12: The problem is, most cases we have no idea of the base rev1, and commit rev2 which it's leading up to. E.g. for a single patch which is between commit rev1..rev2, how do we find out rev1 and rev2. So, then the question is: What do you know/have? Is your patch the output of git format-patch, git diff, or just some sort of diff without any git information? Michael -- 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: checkout-index: unable to create file foo (File exists)
On 12-11-04 05:10 PM, Pete Wyckoff wrote: Fascinating problem and observations. I thought so as well. We've been using NFS with git for quite a while and have never seen such an error. Could be because NFS manages to operate more atomically given that it's just the network exporting of local filesystem. man 7 signal (linux man-pages 3.42) describes open() as restartable. Indeed. The question is just what is to be assumed by the code that has asked for the restartability. Which network filesystem and OS are you using? The filesystem is Lustre. So not only is it networked, it is distributed where the namespace and data store are handled by different nodes, to it's not at all as atomic as NFS-on-(say-)ext4. Given that, it's entirely possible to imagine a scenario where a namespace (MDT in the Lustre nomenclature) operation could get interrupted after the namespace entry has been created but before the open(2) completes. So the question here is who's responsibility is it to handle that situation? The third option is that there is a bug in the filesystem client. Yep. But before we can go on to determining a bug, the proper/expected behavior needs to be determined. I guess that's taking this a bit OT for this list though. I'm not really sure where else to go to determine this though. :-( b. signature.asc Description: OpenPGP digital signature
Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Felipe Contreras venit, vidit, dixit 02.11.2012 17:09: On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38: On 11/01/2012 02:46 PM, René Scharfe wrote: Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. It goes further back than that. Suum cuique pulchrum est (To each his own is a beautiful thing) is a latin phrase said to be used frequently in the roman senate when senators politely agreed to disagree and let a vote decide the outcome rather than debating further. Please don't let the twisted views of whatever nazi idiot thought it meant you may have the wrong faith and therefore deserve to die, so you shall pollute it. The original meaning is both poetic and democratic, and I firmly believe most people have the original meaning to the fore of their mind when using it. After all, very few people knowingly quote nazi concentration camp slogans. In fact, many German terms and words are forbidden area since Nazi times, but I don't think this one carries the same connotation. But that is a side track. Collaboration (and code review is a form of collaboration) requires communication. The linked code of conduct pages describe quite well how to ensure a productive environment in which everyone feels comfortable communicating and collaborating. Yes, but that's assuming we want everyone to feel comfortable communicating and collaborating. I put everyone in quotes because you can never reach 100%, so everyone means almost everyone. Undeniably, the answers in this and the other threads show that on the git mailing list, everyone wants everyone to feel comfortable communicating and collaborating. And that might be a mistake. Because everyone doesn't include the people that are able to put personal differences aside, and concentrate on technical merits. I cite again the example of the Linux kernel, where certainly not everyone feels that way. But somehow It's a different list with different standards and tone, so it doesn't really matter for our list. That being said: If you don't want to take into consideration what the most successful software project in history does... up to you. they manage to be perhaps the most successful software project in history. And I would argue even more: it's _because_ not everyone feels comfortable, it's because ideas and code are criticized freely, and because only the ones that do have merit stand. If you are able to take criticism, and you are not emotionally and personally attacked to your code and your ideas, you would thrive in this environment. If you don't want your precious little baby code to fight against the big guys, then you shouldn't send it out to the world. For one thing, contributors on the kernel list are open to technical arguments, and that includes the arguments of others; just like we are here. On the other hand, you seem to rebuke any (most) technical argument in harsh words as if it were a personal attack; at least that's how your answers come across to me (and apparently others). That really makes it difficult for most of us here to argue with you technically, which is a pity. That lack of openness for the arguments of others would make your life difficult on the kernel list also. It doesn't. And I don't. There is no lack of openness from my part. I hear all technical arguments, and I reply on a technical basis. The problem seems to be is that you expect the code submitted to be criticized, but not the criticism it receives. IOW; the submitter has to put up with anything anybody says about his/her code and ideas, but the *reviewer* is untouchable; the submitter cannot ever criticize the reviewer. I can tell you that doesn't happen in the Linux kernel; the review process is a _discussion_, not a one-way communication, and discussions can be heated up, but the end result is better code, *both* sides are open to criticism, the submitter, *and* the reviewer. It seems to me that you think in the git mailing list the submitter should never put in question the criticism of the reviewer. If that's not the case, show me a single instance when I rebuke technical arguments in *harsh* words... perhaps, you think any rebuking is harsh. Specifically, show me an instance were *I* was harsh, and the reviewer was not. If you cannot show instances of this, then your statement that I rebuke harshly doesn't stand; I rebuke, that's all. A completely different issue is that of language. You talk German on a German list and English on an international list. You talk kernel English on the kernel list,
Re: [PATCH v4 00/13] New remote-hg helper
On Mon, Nov 5, 2012 at 3:13 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Felipe Contreras venit, vidit, dixit 02.11.2012 19:01:
I talked with some people in #mercurial, and apparently there is a
concept of a 'changelog' that is supposed to store these changes, but
since the format has changed, the content of it is unreliable. That's
not a big problem because it's used mostly for reporting purposes
(log, query), not for doing anything reliable.
Is the changelog stored in the repo (i.e. generated by the hg version at
commit time) or generated on the fly (i.e. generated by the hg version
at hand)? See also below.
I don't know. I would expect it to be the former, and then when the
format changes, generated by the tool that did the conversion.
To reliably see the changes, one has to compare the 'manifest' of the
revisions involved, which contain *all* the files in them.
'manifest' == '(exploded) tree', right? Just making sure my hg fu is not
subzero.
Yeah, the tree. As I said, it contains all the files.
That's what I was doing already, but I found a more efficient way to
do it. msysGit is using the changelog, which is quite fast, but not
reliable.
Unfortunately while going trough mercurial's code, I found an issue,
and it turns out that 1) is not correct.
In mercurial, a file hash contains also the parent file nodes, which
means that even if two files have the same content, they would not
have the same hash, so there's no point in keeping track of them to
avoid extracting the data unnecessarily, because in order to make sure
they are different, you need to extract the data anyway, defeating the
purpose.
Do I understand correctly that neither the msysgit version nor yours can
detect duplicate blobs (without requesting them) because of that sha1 issue?
That's correct.
I'm really wondering why a file blob hash carries its history along in
the sha1. This appears completely strange to gitters (being brain washed
about content tracking), but may be due to hg's extensive use of
delta, or really: delta chains (which do have their merit on the server
side).
It is a surprise to me too. I see absolutely no reason why that would be useful.
It seems like bazaar does store the file hashes without the parent
info, like git.
Which means mercurial doesn't really behave as one would expect:
# add files with the same content
$ echo a a
$ hg ci -Am adda
adding a
$ echo a a
$ hg ci -m changea
$ echo a a
$ hg st --rev 0
$ hg ci -m reverta
$ hg log -G --template '{rev} {desc}\n'
@ 2 reverta
|
o 1 changea
|
o 0 adda
# check the difference between the first and the last revision
$ hg st --rev 0:2
M a
$ hg cat -r 0 a
a
$ hg cat -r 2 a
a
That is really scary. What use is hg stat --rev then? Not blaming you
for hg, of course.
On that tangent, I just noticed recently that hg has no python api.
Seriously [1]. They even tell us not to use the internal python api.
msysgit has been lacking support for newer hg, and you've had to add
support for older versions (hg 1.9 will be around on quite some
stable/LTS/EL distro releases) after developing on newer/current ones.
I'm wondering how well that scales in the long term (telling from
git-svn experience: it does not scale well), or whether using some
stable api like 'hgapi' would be a huge bottleneck.
I don't know. I have never really used mercurial until recently. I
don't know how often they change their APIs and/or repository formats.
I would say the burden of updating to newer APIs is probably much less
than the burden of implementing code that accesses their repositories
directly, and eventually possibly rewriting the code when they change
the format.
If we were to access the repository directly, I would choose to use
Ruby for that, but given that 'we' is increasingly looking like 'I'. I
probably wouldn't.
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
[PATCH v2 3/5] remote-bzr: add support for pushing
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 295 ++
1 file changed, 295 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index ed893b0..9e0062f 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -22,13 +22,17 @@ bzrlib.initialize()
import bzrlib.plugin
bzrlib.plugin.load_plugins()
+import bzrlib.generate_ids
+
import sys
import os
import json
import re
+import StringIO
NAME_RE = re.compile('^([^]+)')
AUTHOR_RE = re.compile('^([^]+?)? ?([^]*)$')
+RAW_AUTHOR_RE = re.compile('^(\w+) (.+)? (.*) (\d+) ([+-]\d+)')
def die(msg, *args):
sys.stderr.write('ERROR: %s\n' % (msg % args))
@@ -46,6 +50,7 @@ class Marks:
self.path = path
self.tips = {}
self.marks = {}
+self.rev_marks = {}
self.last_mark = 0
self.load()
@@ -58,6 +63,9 @@ class Marks:
self.marks = tmp['marks']
self.last_mark = tmp['last-mark']
+for rev, mark in self.marks.iteritems():
+self.rev_marks[mark] = rev
+
def dict(self):
return { 'tips': self.tips, 'marks': self.marks, 'last-mark' :
self.last_mark }
@@ -70,6 +78,9 @@ class Marks:
def from_rev(self, rev):
return self.marks[rev]
+def to_rev(self, mark):
+return self.rev_marks[mark]
+
def next_mark(self):
self.last_mark += 1
return self.last_mark
@@ -82,6 +93,11 @@ class Marks:
def is_marked(self, rev):
return self.marks.has_key(rev)
+def new_mark(self, rev, mark):
+self.marks[rev] = mark
+self.rev_marks[mark] = rev
+self.last_mark = mark
+
def get_tip(self, branch):
return self.tips.get(branch, None)
@@ -116,10 +132,35 @@ class Parser:
if self.line == 'done':
self.line = None
+def get_mark(self):
+i = self.line.index(':') + 1
+return int(self.line[i:])
+
+def get_data(self):
+if not self.check('data'):
+return None
+i = self.line.index(' ') + 1
+size = int(self.line[i:])
+return sys.stdin.read(size)
+
+def get_author(self):
+m = RAW_AUTHOR_RE.match(self.line)
+if not m:
+return None
+_, name, email, date, tz = m.groups()
+committer = '%s %s' % (name, email)
+tz = int(tz)
+tz = ((tz / 100) * 3600) + ((tz % 100) * 60)
+return (committer, int(date), tz)
+
def rev_to_mark(rev):
global marks
return marks.from_rev(rev)
+def mark_to_rev(mark):
+global marks
+return marks.to_rev(mark)
+
def fixup_user(user):
name = mail = None
user = user.replace('', '')
@@ -296,9 +337,255 @@ def do_import(parser):
sys.stdout.flush()
+def parse_blob(parser):
+global blob_marks
+
+parser.next()
+mark = parser.get_mark()
+parser.next()
+data = parser.get_data()
+blob_marks[mark] = data
+parser.next()
+
+class CustomTree():
+
+def __init__(self, repo, revid, parents, files):
+global files_cache
+
+self.repo = repo
+self.revid = revid
+self.parents = parents
+self.updates = files
+
+def copy_tree(revid):
+files = files_cache[revid] = {}
+tree = repo.repository.revision_tree(revid)
+repo.lock_read()
+try:
+for path, entry in tree.iter_entries_by_dir():
+files[path] = entry.file_id
+finally:
+repo.unlock()
+return files
+
+if len(parents) == 0:
+self.base_id = bzrlib.revision.NULL_REVISION
+self.base_files = {}
+else:
+self.base_id = parents[0]
+self.base_files = files_cache.get(self.base_id, None)
+if not self.base_files:
+self.base_files = copy_tree(self.base_id)
+
+self.files = files_cache[revid] = self.base_files.copy()
+
+def last_revision(self):
+return self.base_id
+
+def iter_changes(self):
+changes = []
+
+def get_parent(dirname, basename):
+parent_fid = self.base_files.get(dirname, None)
+if parent_fid:
+return parent_fid
+parent_fid = self.files.get(dirname, None)
+if parent_fid:
+return parent_fid
+if basename == '':
+return None
+d = add_entry(dirname, 'directory')
+return d[0]
+
+def add_entry(path, kind):
+dirname, basename = os.path.split(path)
+parent_fid = get_parent(dirname, basename)
+fid = bzrlib.generate_ids.gen_file_id(path)
+change = (fid,
+(None, path),
+True,
+(False, True),
+
Re: checkout-index: unable to create file foo (File exists)
br...@interlinx.bc.ca wrote on Mon, 05 Nov 2012 10:25 -0500: On 12-11-04 05:10 PM, Pete Wyckoff wrote: Which network filesystem and OS are you using? The filesystem is Lustre. So not only is it networked, it is distributed where the namespace and data store are handled by different nodes, to it's not at all as atomic as NFS-on-(say-)ext4. Given that, it's entirely possible to imagine a scenario where a namespace (MDT in the Lustre nomenclature) operation could get interrupted after the namespace entry has been created but before the open(2) completes. So the question here is who's responsibility is it to handle that situation? That's all in the filesystem. Hopefully it doesn't really work like that because the fs is incosistent at this point. ERESTARTSYS handling is done entirely in the kernel, not in glibc and not git. A possible in-kernel fix is not to handle any signals (except KILL) when waiting for the open mechanics to finish. The third option is that there is a bug in the filesystem client. Yep. But before we can go on to determining a bug, the proper/expected behavior needs to be determined. I guess that's taking this a bit OT for this list though. I'm not really sure where else to go to determine this though. :-( You could toss this to lustre support. Or try first to come up with a reduced testcase with lots of opens and SIGALRMs racing against each other. Maybe xfstests or some other suite might also tickle the bug. I don't think it is feasible to try to handle this error condition in applications. -- Pete -- 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: [PATCHv2 2/2] git p4: add support for 'p4 move' in P4Submit
vitor@gmail.com wrote on Mon, 05 Nov 2012 17:37 +: Pete Wyckoff pw at padd.com writes: From: Gary Gibbons ggibbons at perforce.com For -M option (detectRenames) in P4Submit, use 'p4 move' rather than 'p4 integrate'. Check Perforce server for exisitence of 'p4 move' and use it if present, otherwise revert to 'p4 integrate'. Hi Pete, I've just been hit by a situation where this command is available but is disabled in the server. I don't know what is the best approach to avoid this issue. Really? The command exists in the server because it returns the text output for p4 help move. But p4 move itself fails because it is somehow disabled in the server? I didn't even know it was possible to administratively disable commands. What's the actual error message? And versions of your client and server (p4 -V, p4d -V, p4 info). Any ideas Gary? -- Pete -- 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: how the commit ID come from in GIT?
On Monday, November 05, 2012 at 15:04 EST, hong zhang henryzhan...@yahoo.com wrote: Could anyone explain how the git commit ID will include all the files that devloper makes changes on? How git commit ID works? In short, a Git commit points to a tree object that describes the full state of the source tree plus metadata like the commit author, date, description, and a pointer to the commit object(s) that preceded the commit. The commit id itself is the SHA-1 of the contents of the commit object. Any change of the source tree will affect the top-level tree object's SHA-1 which in turn affects the SHA-1 of the commit. Also, because a commit contains the timestamp of the commit object's creation even two commits that are content-wise identical will have different SHA-1s. If you haven't read it, the Pro Git books explains Git's object model in detail: http://git-scm.com/book/en/Git-Internals-Git-Objects That description is quite detailed, and most users don't need to go that deep. -- Magnus Bäck ba...@google.com -- 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: Like commit -a, but...
On Mon, 05 Nov 2012 21:29:48 +, Andreas Krey wrote: ... But still I'd like to know if there is a cleaner solution, esp. with respect to the index. Actually, it seems commit -m 'index' commit -a -m 'worktree' ...push git reset HEAD^ git reset --soft HEAD^ might do the index trick. But is there a direct way to convert the current working tree into a tree object? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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
Like commit -a, but...
Hi all, I have a workflow for which I can't quite find the git tooling. Essentially what I want is like 'git commit -a', except that I want the resulting commit on a branch I name instead of the current one, and I want my current index not being modified. At the moment I emulate that via git commit -a -m TEMP: `date` $* \ git push -f nsd master:temp \ git reset HEAD^ \ but that a) changes the index (ok, not that bad), and it will change my current commit in the case that there are no unmodified files (no commit - head doesn't point where I want). Ok, that can be prevented by --allow-empty. But still I'd like to know if there is a cleaner solution, esp. with respect to the index. (Ah, the point of all this is to take the exact current worktree and push it to a compiledeploy server; I don't want to chop my work into commits before I even could compile it.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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: why '--init' in git-submodule update
Hi, On Mon, Nov 05, 2012 at 05:30:51PM +0100, Francis Moreau wrote: I'm wondering why the --init option from git-submodule-update is not at least the defaut. Or even wilder, why this option exists at all and git-submodule-update always behave like --init was always passed. That was a design decision. People may not be interested in all submodules but just a subset they are working with. E.g. think of a large media directory as a submodule the developers might not be interested in having it around all the time because only the designers are heavily working with it. So the rationale is that you should ask for a certain submodule to be initialized to get it. If there is demand for it we could of course think about offering a config option in .gitmodules to allow enabling it by default for some submodules. Cheers Heiko -- 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: Like commit -a, but...
On Mon, 05 Nov 2012 21:56:28 +0100, Andreas Krey a.k...@gmx.de wrote: On Mon, 05 Nov 2012 21:29:48 +, Andreas Krey wrote: ... But still I'd like to know if there is a cleaner solution, esp. with respect to the index. Actually, it seems commit -m 'index' commit -a -m 'worktree' ...push git reset HEAD^ git reset --soft HEAD^ might do the index trick. But is there a direct way to convert the current working tree into a tree object? PARENT=$(git rev-parse HEAD) TREE=$(git write-tree) COMMIT=$(git commit-tree -p $PARENT -m message' $TREE) git push origin $COMMIT:refs/heads/teh-branch write-tree+commit-tree is what git-commit does internally. -- 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: git-p4 clone @all error
a.fou...@amesys.fr wrote on Mon, 05 Nov 2012 02:02 -0800: Hi, Here is my import : Importing from //depot@all into X Initialized empty Git repository in /home/arthur/projets_git/X/X/.git/ Importing revision 4258 (43%) Importing new branch depot/DEV_DATA Resuming with change 4258 Importing revision 5828 (63%) Importing new branch depot/RELEASE_1.0 Resuming with change 5828 Importing revision 7720 (88%) Importing new branch depot/RELEASE_1.0.0 Resuming with change 7720 Importing revision 8588 (100%) Updated branches: DEV_DATA RELEASE_1.0 MAINLINE/02_SubSystem/10_ARINC_429 MAINLINE RELEASE_1.0.0 fast-import failed: error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 error: unable to resolve reference refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory error: Unable to lock refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429 git-fast-import statistics: - Alloc'd objects: 17 Total objects: 169644 (195421 duplicates ) blobs :92182 (186294 duplicates 74565 deltas) trees :70889 ( 9127 duplicates 57686 deltas) commits: 6573 ( 0 duplicates 0 deltas) tags :0 ( 0 duplicates 0 deltas) Total branches: 8 ( 8 loads ) marks: 1024 ( 0 unique) atoms: 19603 Memory total: 19217 KiB pools: 12576 KiB objects: 6640 KiB - pack_report: getpagesize()= 4096 pack_report: core.packedGitWindowSize = 33554432 pack_report: core.packedGitLimit = 268435456 pack_report: pack_used_ctr= 19803 pack_report: pack_mmap_calls = 65 pack_report: pack_open_windows= 10 / 11 pack_report: pack_mapped = 257715823 / 268009874 - Import crash after importing revision, my import have not files Thanks, that is interesting output. Adding Vitor who knows his way around the branch detection code. The first mail by Arthur is here, which focuses more on the backtrace from p4 describe errors, but also suggests something is dodgy in branch detection: http://thread.gmane.org/gmane.comp.version-control.git/208693 I'm not sure if this is a --verbose run, though, as I don't see any chatter like branch is xxx. So I'm not sure if the auto-parent detection code got run. The unable to resolve reference comes from refs.c, which is when fast-import calls update_branch() on each of the changed branches as it is finishing. Vitor, what could git-p4 have done to create a branch name called refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429? Any other questions for Arthur? -- Pete -- 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: Like commit -a, but...
Andreas Krey a.k...@gmx.de writes: But is there a direct way to convert the current working tree into a tree object? You can create a temporary index by setting the GIT_INDEX_FILE env var. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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: git am crash (builtin/apply.c:2108) + small repro
Thanks for looking into this, guys!
I seem to run into this with some regularity, but my setting is
apply.whitespace=strip rather than 'fix'.
Is there an obvious workaround?
Here are my remaining settings, sanitized for file paths and URLs:
svn.rmdir=true
push.default=upstream
color.ui=auto
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.branch.current=white blue bold
color.branch.local=blue
color.branch.remote=green
color.diff.plain=white
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red
color.diff.new=green
color.diff.whitespace=red blink
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
svn.followparent=true
log.date=relative
blame.date=short
diff.renames=copies
diff.copies=true
diff.mnemonicprefix=true
apply.whitespace=strip
merge.tool=emerge
status.relativepaths=true
web.browser=lynx
rebase.stat=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
rerere.enabled=true
branch.autosetuprebase=always
-a
On Fri, Oct 12, 2012 at 3:53 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
I've never been a fan of update_pre_post_images(). I think I know
what is going on (--whitespace=fix). Will post a fix sometime
later.
It bisects down to 5166714 (apply: Allow blank context lines to
match beyond EOF, 2010-03-06).
I do not like this patch at all (I _think_ it should somehow check
the corresponding postimage is sane when the ah, we ran out of
preimage because the caller fixed it to reduce trailing blank lines
case), but at least this should get the ball rolling.
Björn, both of the changes involved are yours, so I am thinking that
you may be a good person to give a sanity check on this. No need to
hurry, as this is not a recent regression and we are in a pre-release
freeze.
Thanks.
-- 8 --
Subject: apply.c:update_pre_post_images(): the preimage can be truncated
5166714 (apply: Allow blank context lines to match beyond EOF,
2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
context lines to match beyond EOF, 2010-04-08) taught git apply
to trim new blank lines at the end in the patch text when matching
the contents being patched and the preimage recorded in the patch,
under --whitespace=fix mode.
When a preimage is modified to match the current contents in
preparation for such a fixed patch application, the context lines
in the postimage must be updated to match (otherwise, it would
reintroduce whitespace breakages), and update_pre_post_images()
function is responsible for doing this. However, this function was
not updated to take into account a case where the removal of
trailing blank lines reduces the number of lines in the preimage,
and triggered an assertion error.
The logic to fix the postimage by copying the corrected context
lines from the preimage was not prepared to handle this case,
either, but it was protected by the assert() and only got exposed
when the assertion is corrected.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/apply.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git c/builtin/apply.c w/builtin/apply.c
index 156b3ce..6c11e8b 100644
--- c/builtin/apply.c
+++ w/builtin/apply.c
@@ -2095,7 +2095,7 @@ static void update_pre_post_images(struct image
*preimage,
char *buf,
size_t len, size_t postlen)
{
- int i, ctx;
+ int i, ctx, reduced;
char *new, *old, *fixed;
struct image fixed_preimage;
@@ -2105,8 +2105,10 @@ static void update_pre_post_images(struct image
*preimage,
* free oldlines.
*/
prepare_image(fixed_preimage, buf, len, 1);
- assert(fixed_preimage.nr == preimage-nr);
- for (i = 0; i preimage-nr; i++)
+ assert(postlen
+ ? fixed_preimage.nr == preimage-nr
+ : fixed_preimage.nr = preimage-nr);
+ for (i = 0; i fixed_preimage.nr; i++)
fixed_preimage.line[i].flag = preimage-line[i].flag;
free(preimage-line_allocated);
*preimage = fixed_preimage;
@@ -2126,7 +2128,8 @@ static void update_pre_post_images(struct image
*preimage,
else
new = old;
fixed = preimage-buf;
- for (i = ctx = 0; i postimage-nr; i++) {
+
+ for (i = reduced = ctx = 0; i postimage-nr; i++) {
size_t len = postimage-line[i].len;
if (!(postimage-line[i].flag LINE_COMMON)) {
/* an added line -- no counterparts in preimage */
@@ -2145,8 +2148,15 @@ static void update_pre_post_images(struct image
*preimage,
fixed += preimage-line[ctx].len;
ctx++;
}
- if (preimage-nr = ctx)
-
Re: how the commit ID come from in GIT?
On Mon, Nov 05, 2012 at 12:04:06PM -0800, hong zhang wrote: Could anyone explain how the git commit ID will include all the files that devloper makes changes on? How git commit ID works? To expand on the answer provided by Magnus, I would also suggest reading the classic Git from the bottom up document [1], and if you want a totally informal and fun introduction to how these cryptographic hashes come about and why they are useful, I suggest reading The Git Parable [2]. 1. http://newartisans.com/2008/04/git-from-the-bottom-up/ 2. http://tom.preston-werner.com/2009/05/19/the-git-parable.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
git log --follow --reverse ignores --follow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I found something looking like a bug: The following lines prepares a small exmaple: # create git repo git init # create file a and commit it touch a git add a git commit -m first # rename a to b and commit it git mv a b git commit -m second After this git log's behavior differs from my expectations, when run like this: git log --follow --reverse b Expected result: A list of both commits starting with second or a error message if git log cannot run with --follow and --reverse combined. Actual result: A list showing only the second commit. It looks like git log silently ignores --follow when run with --reverse. Observed with git versions 1.7.8.6 and 1.7.11.2 Valentin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQmEL/AAoJEANdk65I57uzbE0P/i0p8mlBcGWI+WyPqU7dhAmO 3jHLMmqNV12bm9zeNKuKxQPDS5IzMWRwDpO6GXdn8BQauQtpwB0POLXBIWl9pP2g TOGJjIUL/Rd7+G4FF1vcSUxd9LESlPDQTL+J2F3B7+KRMRzxxsbNv/5826w7HQHg ck6XfrmkFxoIn6w6CH6pCncRFl6cb7EqrMZIhGclJvDqXKi4DHRa3XpPRCle/Xa1 2P65kb0va+LzX2nUdfKR/WeH0V0XPURyObr/NN0ecVIrLj3roV/0OZBg/AsQwu3Z Zw4CM5nL0DsgD81FEc8cToe5eJwi5/VH56+CbDyr+wcLj4BO4niS3eQqQKmyiJS7 2/Pny+IZOZmIJzh5+6d0puufKut877PIRoJTs0P8l+dXU9xIbzwVTTcWDpKQt5Mx Mzi6oSpCLDuvBo+WCjanqtF2oNoLnbfq9nD/KgmIH/XTLKsryL48PFXx1b+7vGuG hmzlcRies3Xpkx0cegzqSngl3/I1Rq8hEbJhcJA4SrJFS2sVj8lGALPgFQdhif2L N0c5DNUD9F5pH/U11a0YnOxtkFyB+LjXqE2zN9Mz+t0TZ69+y6qZMrxHbAoeNDMX Do22J9jgSc80VE3Cdn8Cwe/xVLoJCvc7wSUpBbTQjDhOZbv7Zbtjl1venS3/q4fk wcOSFLYb0Heqm8Qxwf+d =D+B2 -END PGP SIGNATURE- -- 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
Fwd: [PATCH] Remove terminal symbols from non-terminal console
As per discussion on msysgit user group: https://groups.google.com/forum/?fromgroups=#!topic/msysgit/U_a982_a3rc/discussion we found the following patch is required to get rid of weird terminal characters for other tools such as GitExtensions for Windows ---8--- diff --git a/sideband.c b/sideband.c index d5ffa1c..bd3e5a8 100644 --- a/sideband.c +++ b/sideband.c @@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int out) memcpy(buf, PREFIX, pf); term = getenv(TERM); - if (term strcmp(term, dumb)) + if (isatty(out) term strcmp(term, dumb)) suffix = ANSI_SUFFIX; else suffix = DUMB_SUFFIX; ---8--- -- 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] gitweb: make remote_heads config setting work.
Git configuration items can not contain underscores in their name; the
'remote_heads' feature can not be enabled on a per-repository basis with
that name.
This changes the git-config option to be `gitweb.remoteheads` but does
not change the gitweb.conf option, to avoid backwards compatibility
issues. We strip underscores from keys before looking through
git-config output for them.
Signed-off-by: Phil Pennock p...@apcera.com
---
gitweb/gitweb.perl |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..f2144c8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -541,7 +541,7 @@ our %feature = (
# $feature{'remote_heads'}{'default'} = [1];
# To have project specific config enable override in $GITWEB_CONFIG
# $feature{'remote_heads'}{'override'} = 1;
- # and in project config gitweb.remote_heads = 0|1;
+ # and in project config gitweb.remoteheads = 0|1;
'remote_heads' = {
'sub' = sub { feature_bool('remote_heads', @_) },
'override' = 0,
@@ -2702,6 +2702,7 @@ sub git_get_project_config {
$key = lc($key);
}
$key =~ s/^gitweb\.//;
+ $key =~ s/_//g;
return if ($key =~ m/\W/);
# type sanity check
--
1.7.10.3
--
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: git-p4 clone @all error
On Mon, 5 Nov 2012 17:12:12 -0500 Pete Wyckoff p...@padd.com wrote: Thanks, that is interesting output. Adding Vitor who knows his way around the branch detection code. The first mail by Arthur is here, which focuses more on the backtrace from p4 describe errors, but also suggests something is dodgy in branch detection: http://thread.gmane.org/gmane.comp.version-control.git/208693 I'm not sure if this is a --verbose run, though, as I don't see any chatter like branch is xxx. So I'm not sure if the auto-parent detection code got run. The unable to resolve reference comes from refs.c, which is when fast-import calls update_branch() on each of the changed branches as it is finishing. Vitor, what could git-p4 have done to create a branch name called refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429? Any other questions for Arthur? Hi Arthur, Could you please share with us your git-p4.branchList configuration? Would it also be possible to describe a bit more on your depot structure? I'm particularly concerned about its integration history. I suspect the error you are experiencing is connected to a wrong configuration. Please take into account that each entry must be in the form of origin:destination, where origin is the folder used as the source of the integration to destination when first created. Vitor -- 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: [git-users] git compilation problem
On Mon, Nov 05, 2012 at 09:21:13AM -0800, Mathieu Dutour wrote: First, note that this list is a support channel for Git newbies, and your question appears to be more about Git source code itself so I'd say it better fits the main Git list which is git at vger.kernel.org. I Cc'ed this my response here in the hope someone with the platform similar to yours might chime in; so please keep the Cc list in your responses. I tried to install git on an IBM power 6 computer and I had the following problem when doing gmake install This doesn't sound quite descriptive. From what I gather from the Internet, IBM POWER 6 is a CPU brand, targeted at mainframes. I vaguely recall IBM mainframes typically run their own OS (z/OS?) but have extensive support for virtualization so I recall I read somewhere it's customary to run, say, a virtualized Linux-based OS on it. Since what matters here is a *software* platform, please be (way) more precise about this. ./configure[6213]: syntax error at line 6367 : `;' unexpected configure is just a shell script usually generated by the autoconf program from a template file named configure.in. configure is meant to be über-portable, but it assumes your /bin/sh is a shell implementing the command language defined by POSIX, plus a standard set of text-processing tools (such as sed and grep) is available. I can make a guess that whatever is available as /bin/sh in your system might not quite fit the expectations of configure. I envision two ways to fix this: 1) Install autoconf and run it to regenerate the configure script; then try the compilation again. 2) Try to force configure using a different shell, if available. GNU bash should cut it, ash and dash [1] too. In either case note that there isn't any indication that that syntax error actually made the build process to fail; the only failing error in the output you quoted is that of the `install` command which runs after the compilation is done to install things (obviously). By this I mean, if you will be able to fix that `install` error it might turn out you could ignore the configure error whatsoever. gmake[2]: `GIT-VERSION-FILE' is up to date. GEN git-instaweb SUBDIR git-gui SUBDIR gitk-git gmake[1]: Nothing to be done for `all'. SUBDIR perl SUBDIR git_remote_helpers SUBDIR templates install -d -m 755 '/home/ar69ovim/opt/git-1.8.0/bin' /usr/bin/getopt: Not a recognized flag: d Usage: install [-c DirectoryA] [-f DirectoryB] [-i] [-m] [-M Mode] [-O Owner] [-G Group] [-S] [-n DirectoryC] [-o] [-s] File [DirectoryX ...] Supposedly Git makefiles expect the `install` program to support the -d command line option. On my Linux system with `install` provided by GNU coreutils [2], the -d command line option of this tool is used to create the whole directory hierarchy according to the argument passed to that option. Obviously your `install` does not support this option. Moreover, from the error output it follows, that your `install` is implemented as a shell script which calls /usr/bin/getopt to parse its command-line options. Again, I can see several ways to fix that: 1) Patch Git makefile(s) to use some other means to create directory hierarchies. For instance, some versions of `mkdir` support the -p command line option to do this. You could combine `mkdir -p` with `chmod 755` to do what `install -d -m 755` would do. 2) (Somehow) get GNU coreutils and make Git makefiles see /usr/bin/install provided by this package. 3) Patch your `install` to support -d. gmake: *** [install] Error 2 That's what makes the whole thing fail. 1. http://en.wikipedia.org/wiki/Debian_Almquist_shell 2. http://gnu.org/software/coreutils -- 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: Support for a series of patches, i.e. patchset or changeset?
On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Eric Miao venit, vidit, dixit 05.11.2012 15:12: The problem is, most cases we have no idea of the base rev1, and commit rev2 which it's leading up to. E.g. for a single patch which is between commit rev1..rev2, how do we find out rev1 and rev2. So, then the question is: What do you know/have? Is your patch the output of git format-patch, git diff, or just some sort of diff without any git information? That doesn't matter, all the info can be obtained from the SHA1 id, the question is: do we have a mechanism in git (or hopefully we could add) to record the patchset or series the patch belongs to, without people to guess heuristically. E.g. when we merged a series of patches: [PATCH 00/08] [PATCH 01/08] ... [PATCH 08/08] How do we know this whole series after merged when only one of these commits are known? -- 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: Support for a series of patches, i.e. patchset or changeset?
Am 11/6/2012 1:58, schrieb Eric Miao: On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Eric Miao venit, vidit, dixit 05.11.2012 15:12: The problem is, most cases we have no idea of the base rev1, and commit rev2 which it's leading up to. E.g. for a single patch which is between commit rev1..rev2, how do we find out rev1 and rev2. E.g. when we merged a series of patches: [PATCH 00/08] [PATCH 01/08] ... [PATCH 08/08] How do we know this whole series after merged when only one of these commits are known? You can use git name-rev. For example: $ git name-rev 9284bdae3 9284bdae3 remotes/origin/pu~2^2~7 This tell you that the series was merged two commits before origin/pu, and then it is the 7th from the tip of the series. Now you can $ git log origin/pu~2^..origin/pu~2^2 to see the whole series. -- Hannes -- 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: Support for a series of patches, i.e. patchset or changeset?
On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 11/6/2012 1:58, schrieb Eric Miao: On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Eric Miao venit, vidit, dixit 05.11.2012 15:12: The problem is, most cases we have no idea of the base rev1, and commit rev2 which it's leading up to. E.g. for a single patch which is between commit rev1..rev2, how do we find out rev1 and rev2. E.g. when we merged a series of patches: [PATCH 00/08] [PATCH 01/08] ... [PATCH 08/08] How do we know this whole series after merged when only one of these commits are known? You can use git name-rev. For example: $ git name-rev 9284bdae3 9284bdae3 remotes/origin/pu~2^2~7 This tell you that the series was merged two commits before origin/pu, and then it is the 7th from the tip of the series. Now you can $ git log origin/pu~2^..origin/pu~2^2 to see the whole series. I'm just curious how this is implemented in git, are we keeping the info of the series that's applied in a whole? But this still looks like be inferred basing on a branch head, and I'm afraid this may not be applicable in every case. -- Hannes -- 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 v4 6/8] longest_ancestor_length(): require prefix list entries to be normalized
On 10/30/2012 07:23 PM, Ramsay Jones wrote: [...] Just to be clear, this is true for the MinGW port to Windows, but *not* the cygwin port. [...] ditto Thanks for clarifying these points. It seems like this patch series is not going to be usable (because of fears that it might cause performance degradation in some as-yet-unexplained scenarios), but if that situation seems to change then I will incorporate your corrections. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: Support for a series of patches, i.e. patchset or changeset?
Am 11/6/2012 7:56, schrieb Eric Miao: On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 11/6/2012 1:58, schrieb Eric Miao: E.g. when we merged a series of patches: [PATCH 00/08] [PATCH 01/08] ... [PATCH 08/08] How do we know this whole series after merged when only one of these commits are known? You can use git name-rev. For example: $ git name-rev 9284bdae3 9284bdae3 remotes/origin/pu~2^2~7 This tell you that the series was merged two commits before origin/pu, and then it is the 7th from the tip of the series. Now you can $ git log origin/pu~2^..origin/pu~2^2 to see the whole series. I'm just curious how this is implemented in git, are we keeping the info of the series that's applied in a whole? If the maintainer did his job well, then everything that you had in [PATCH 01/08] ... [PATCH 08/08] is in the commits of the series, and [PATCH 00/08] (the cover letter) is in the commit that merged the series. Anything else that I didn't mention but you consider as the info of the series? But this still looks like be inferred basing on a branch head, and I'm afraid this may not be applicable in every case. What's the problem? That it's inferred? Or that it needs a branch head? -- Hannes -- 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/4] strbuf_split_buf(): use ALLOC_GROW()
On 11/04/2012 12:41 PM, Jeff King wrote: On Sun, Nov 04, 2012 at 07:46:51AM +0100, Michael Haggerty wrote: Use ALLOC_GROW() rather than inline code to manage memory in strbuf_split_buf(). Rename pos to nr because it better describes the use of the variable and it better conforms to the ALLOC_GROW idiom. I suspect this was not used originally because ALLOC_GROW relies on alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with 24 slots for the first allocation. We are typically splitting 1 or 2 values. It probably doesn't make a big difference in practice, though, as we're talking about wasting less than 200 bytes on a 64-bit platform, and we do not tend to keep large numbers of split lists around. I did a little bit of archeology, and found out that * ALLOC_GROW() did indeed exist when this code was developed, so it *could have* been used. * OTOH, I didn't find any indication on the mailing list that the choice not to use ALLOC_GROW() was a conscious decision. So history doesn't give us much guidance. If the size of the initial allocation is a concern, then I would suggest adding a macro like ALLOC_SET_SIZE(ary,nr,alloc) that could be called to initialize the size to some number less than 24. Such a macro might be useful elsewhere, too. It wouldn't, of course, slow the growth rate *after* the first allocation. FWIW, the max parameter of strbuf_split*() is only used in one place, though strbuf_split*() is used in some other places where not too many substrings would be expected. I am working on some patch series that will eliminate even more uses of strbuf_split*(), so I won't work more on optimizing its resource usage unless somebody gives me a stronger nudge. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
