* [PATCH] grep.h: Fix compilation error on mingw
From: Ramsay Jones @ 2011-12-16 22:56 UTC (permalink / raw)
To: trast; +Cc: Junio C Hamano, GIT Mailing-list
In particular, gcc complains as follows:
CC bisect.o
In file included from revision.h:5,
from bisect.c:4:
grep.h:138: error: expected '=', ',', ';', 'asm' or \
'__attribute__' before 'grep_attr_mutex'
make: *** [bisect.o] Error 1
In order to fix the error, we include the 'thread-utils.h' header
file in grep.h, since it provides a definition of pthread_mutex_t
(indirectly via compat/win32/pthread.h).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Thomas,
If you need to re-roll your grep-threading series, could you please
squash this patch into your commit 53f4b6f7 (grep: enable threading
with -p and -W using lazy attribute lookup, 12-12-2011).
[Note: you could also remove the '#include "thread-utils.h"' in both
grep.c and builtin/grep.c, since it is now included from grep.h.]
Thanks!
ATB,
Ramsay Jones
grep.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/grep.h b/grep.h
index 15d227c..b6f06cb 100644
--- a/grep.h
+++ b/grep.h
@@ -8,6 +8,7 @@ typedef int pcre;
typedef int pcre_extra;
#endif
#include "kwset.h"
+#include "thread-utils.h"
enum grep_pat_token {
GREP_PATTERN,
--
1.7.8
^ permalink raw reply related
* [PATCH] Fix an "variable might be used uninitialized" gcc warning
From: Ramsay Jones @ 2011-12-16 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In particular, gcc issues the following warning:
CC builtin/checkout.o
builtin/checkout.c: In function `cmd_checkout':
builtin/checkout.c:160: warning: 'mode' might be used uninitialized \
in this function
However, the analysis performed by gcc is too conservative, in this
case, since the mode variable will not be used uninitialised. Note that,
if the mode variable is not set in the loop, then "threeway[1]" will
also still be set to the null SHA1. This will then result in control
leaving the function, almost directly after the loop, well before the
potential use in the call to make_cache_entry().
In order to suppress the warning, we initialise the mode variable to
zero in it's declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Just in case you haven't found the time to apply your own patch!
[Note that only 2 out of the 3 versions of gcc I use issues this
warning]
ATB,
Ramsay Jones
builtin/checkout.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 787d468..f1984d9 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -157,7 +157,7 @@ static int checkout_merged(int pos, struct checkout *state)
unsigned char sha1[20];
mmbuffer_t result_buf;
unsigned char threeway[3][20];
- unsigned mode;
+ unsigned mode = 0;
memset(threeway, 0, sizeof(threeway));
while (pos < active_nr) {
--
1.7.8
^ permalink raw reply related
* Re: [bug?] checkout -m doesn't work without a base version
From: Ramsay Jones @ 2011-12-16 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Michael Schubert, Pete Harlan, git
In-Reply-To: <7v4nx1pwjg.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> You could do the usual "unnecessary initialization" trick, though.
Yes, I wrote exactly this patch some days ago (when it first appeared
in pu), but haven't found the time to send it ... :-D
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH] lf_to_crlf_filter(): tell the caller we added "\n" when draining
From: Junio C Hamano @ 2011-12-16 22:43 UTC (permalink / raw)
To: Git Mailing list; +Cc: Carlos Martín Nieto, Henrik Grubbström
In-Reply-To: <7viplggoq9.fsf@alter.siamese.dyndns.org>
This can only happen when the input size is multiple of the
buffer size of the cascade filter (16k) and ends with an LF,
but in such a case, the code forgot to tell the caller that
it added the "\n" it could not add during the last round.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
convert.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/convert.c b/convert.c
index c2c2c11..c028275 100644
--- a/convert.c
+++ b/convert.c
@@ -879,7 +879,7 @@ int is_null_stream_filter(struct stream_filter *filter)
struct lf_to_crlf_filter {
struct stream_filter filter;
- int want_lf;
+ unsigned want_lf:1;
};
static int lf_to_crlf_filter_fn(struct stream_filter *filter,
@@ -895,8 +895,11 @@ static int lf_to_crlf_filter_fn(struct stream_filter *filter,
lf_to_crlf->want_lf = 0;
}
- if (!input)
- return 0; /* We've already dealt with the state */
+ /* We are told to drain */
+ if (!input) {
+ *osize_p -= o;
+ return 0;
+ }
count = *isize_p;
if (count) {
@@ -931,10 +934,9 @@ static struct stream_filter_vtbl lf_to_crlf_vtbl = {
static struct stream_filter *lf_to_crlf_filter(void)
{
- struct lf_to_crlf_filter *lf_to_crlf = xmalloc(sizeof(*lf_to_crlf));
+ struct lf_to_crlf_filter *lf_to_crlf = xcalloc(1, sizeof(*lf_to_crlf));
lf_to_crlf->filter.vtbl = &lf_to_crlf_vtbl;
- lf_to_crlf->want_lf = 0;
return (struct stream_filter *)lf_to_crlf;
}
--
1.7.8.351.g9111b
^ permalink raw reply related
* Re: [BUG] attribute "eol" with "crlf"
From: Ralf Thielow @ 2011-12-16 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vehw4go0v.fsf@alter.siamese.dyndns.org>
Basicly I want to force the line endings of the files on my
project. :/
2011/12/16 Junio C Hamano <gitster@pobox.com>:
> Ralf Thielow <ralf.thielow@googlemail.com> writes:
>
>> So i have to commit ".gitattributes" and everything is fine for me after!?
>
> No. Sorry if I was unclear, but I do not see which part was unclear in
> what I wrote, so...
>
>>> The sequence adds "test\r\n" file without .gitattributes to have the
>>> repository record that exact byte sequence for the file. But then later
>>> goes around and says "This file wants to express the end of line with CRLF
>>> on the filesystem, so please replace LF in the repository representation
>>> to CRLF when checking out, and replace CRLF in the working tree to LF when
>>> checking in".
>>>
>>> So it is not surprising that "\r\n" coming from the repository is replaced
>>> to "\r\r\n" when checked out. As far as the repository data is concerned,
>>> that line has a funny byte with value "\r" at the end, immediately before
>>> the line terminator "\n".
>>>
>>> What you said is _technically_ correct in that sense.
>>>
>>> However, I think the CRLF filter used to have a hack to strip "\r" if the
>>> repository data records "\r" at the end of line. This was intended to help
>>> people who checked in such a broken text file (if it is a text file, then
>>> raw ascii CR does not have a place in it in the repository representation)
>>> and it was a useful hack to help people recover from such mistakes to
>>> start the project from DOS-only world (with CRLF in the repository data)
>>> and migrate to cross platform world (with LF in the repository data, CRLF
>>> in the DOS working tree). I suspect that the streaming filter conversion
>>> may not have the same hack in it.
^ permalink raw reply
* Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path
From: Jakub Narebski @ 2011-12-16 22:27 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Junio C Hamano, Martin von Zweigbergk, Paul Mackerras, git
In-Reply-To: <8739clzdzw.fsf@fox.patthoyts.tk>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> I have this slight suspicion that Paul would appreciate if somebody who
>> cares about gitk who is capable and willing steps forward and takes over
>> the maintainership of gitk, as he is busy in his other projects.
>
> I can do this one along with git-gui if this is the case.
I wonder if having common maintainer for both gitk and git-gui would
lead to first, splitting gitk into smaller files like git-gui was, and
second sharing common Tcl/Tk bindings / wrappers between gitk and
git-gui...
--
Jakub Narębski
^ permalink raw reply
* Strange behaviour with git-add, .gitignore and a tracked file
From: David ‘Bombe’ Roden @ 2011-12-16 21:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 875 bytes --]
Hi.
I stumbled across some strange behaviour today:
---
git init git-test
cd git-test
echo '*' > .gitignore
git add -f .gitignore
git commit -m "Add gitignore."
mkdir dir
echo a > dir/file
git add -f dir/file
git commit -m "Add dir/file."
echo b >> dir/file
git add dir/file
---
The last git-add results in the following error message:
---
The following paths are ignored by one of your .gitignore files:
dir
Use -f if you really want to add them.
fatal: no files added
---
While it is true that the file specification matches a pattern in .gitignore,
the file is already tracked and should not be ignored.
This behaviour was reproduced with 1.7.7.4 (on OS X), 1.7.5.4, 1.7.1,
1.7.8-247-g10f4eb6 (latest master as of a couple of hours ago) (all Linux).
Greetings,
David
--
David ‘Bombe’ Roden <bombe@pterodactylus.net>
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Junio C Hamano @ 2011-12-16 22:17 UTC (permalink / raw)
To: Ralf Thielow; +Cc: Matthieu Moy, git
In-Reply-To: <CAN0XMOL674Hw_LctTC+8NNqA84Of6dMjdKT0SU+DWMG7EYShYQ@mail.gmail.com>
Ralf Thielow <ralf.thielow@googlemail.com> writes:
> So i have to commit ".gitattributes" and everything is fine for me after!?
No. Sorry if I was unclear, but I do not see which part was unclear in
what I wrote, so...
>> The sequence adds "test\r\n" file without .gitattributes to have the
>> repository record that exact byte sequence for the file. But then later
>> goes around and says "This file wants to express the end of line with CRLF
>> on the filesystem, so please replace LF in the repository representation
>> to CRLF when checking out, and replace CRLF in the working tree to LF when
>> checking in".
>>
>> So it is not surprising that "\r\n" coming from the repository is replaced
>> to "\r\r\n" when checked out. As far as the repository data is concerned,
>> that line has a funny byte with value "\r" at the end, immediately before
>> the line terminator "\n".
>>
>> What you said is _technically_ correct in that sense.
>>
>> However, I think the CRLF filter used to have a hack to strip "\r" if the
>> repository data records "\r" at the end of line. This was intended to help
>> people who checked in such a broken text file (if it is a text file, then
>> raw ascii CR does not have a place in it in the repository representation)
>> and it was a useful hack to help people recover from such mistakes to
>> start the project from DOS-only world (with CRLF in the repository data)
>> and migrate to cross platform world (with LF in the repository data, CRLF
>> in the DOS working tree). I suspect that the streaming filter conversion
>> may not have the same hack in it.
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Ralf Thielow @ 2011-12-16 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vmxasgqlm.fsf@alter.siamese.dyndns.org>
So i have to commit ".gitattributes" and everything is fine for me after!?
> The sequence adds "test\r\n" file without .gitattributes to have the
> repository record that exact byte sequence for the file. But then later
> goes around and says "This file wants to express the end of line with CRLF
> on the filesystem, so please replace LF in the repository representation
> to CRLF when checking out, and replace CRLF in the working tree to LF when
> checking in".
>
> So it is not surprising that "\r\n" coming from the repository is replaced
> to "\r\r\n" when checked out. As far as the repository data is concerned,
> that line has a funny byte with value "\r" at the end, immediately before
> the line terminator "\n".
>
> What you said is _technically_ correct in that sense.
>
> However, I think the CRLF filter used to have a hack to strip "\r" if the
> repository data records "\r" at the end of line. This was intended to help
> people who checked in such a broken text file (if it is a text file, then
> raw ascii CR does not have a place in it in the repository representation)
> and it was a useful hack to help people recover from such mistakes to
> start the project from DOS-only world (with CRLF in the repository data)
> and migrate to cross platform world (with LF in the repository data, CRLF
> in the DOS working tree). I suspect that the streaming filter conversion
> may not have the same hack in it.
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Johannes Sixt @ 2011-12-16 22:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <20111216192104.GA19924@sigill.intra.peff.net>
Am 16.12.2011 20:21, schrieb Jeff King:
> I'm not clear from what you wrote on whether you were saying it is
> simply sub-optimal, or whether on balance it is way worse than the
> default funcname matching.
I'm saying the latter. Okay, we're talking "only" about hunk headers.
But when you are reviewing patches, they are *extremely* useful and a
time-saver; when they are wrong or not present, they are exactly the
opposite.
> So, I'm confused. If you are using this, surely you have "*.c diff=xcpp"
> in your attributes file, and my patch has no effect for you,
Sure I have. What I didn't say (sorry for that!), but wanted to hint at
is that this is to experiment with a pattern in order to ultimately
improve the built-in pattern. The topic came up just the other day, and
I took Thomas Rast's suggestion to experiment with a simplified pattern:
http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439
But as is, the built-in pattern misses way too many anchor points in C++
code.
-- Hannes
^ permalink raw reply
* Re: Infinite loop in cascade_filter_fn()
From: Junio C Hamano @ 2011-12-16 22:01 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <20111128104812.GA2386@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
>
> There may not be enough space to store CRLF in the output. If we don't
> fill the buffer, then the filter will keep getting called with the same
> short buffer and will loop forever.
>
> Instead, always store the CR and record whether there's a missing LF
> if so we store it in the output buffer the next time the function gets
> called.
>
> Reported-by: Henrik Grubbström <grubba@roxen.com>
> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
> ---
> convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 86e9c29..1c91409 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
> /*
> * LF-to-CRLF filter
> */
> +
> +struct lf_to_crlf_filter {
> + struct stream_filter filter;
> + int want_lf;
> +};
> +
> static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> const char *input, size_t *isize_p,
> char *output, size_t *osize_p)
> {
> - size_t count;
> + size_t count, o = 0;
> + struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
> +
> + /* Output a pending LF if we need to */
> + if (lfcrlf->want_lf) {
> + output[o++] = '\n';
> + lfcrlf->want_lf = 0;
> + }
>
> if (!input)
> - return 0; /* we do not keep any states */
> + return 0; /* We've already dealt with the state */
> +
Shouldn't we be decrementing *osize_p by 'o' to signal that we used that
many bytes in the output buffer here before returning to the caller?
> count = *isize_p;
> if (count) {
> - size_t i, o;
> - for (i = o = 0; o < *osize_p && i < count; i++) {
> + size_t i;
> + for (i = 0; o < *osize_p && i < count; i++) {
> char ch = input[i];
> if (ch == '\n') {
> - if (o + 1 < *osize_p)
> - output[o++] = '\r';
> - else
> - break;
> + output[o++] = '\r';
> + if (o >= *osize_p) {
> + lfcrlf->want_lf = 1;
> + continue; /* We need to increase i */
> + }
> }
> output[o++] = ch;
> }
^ permalink raw reply
* Re: How to automatically correct an almost correct auto-merge?
From: Neal Kreitzinger @ 2011-12-16 21:32 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20111216203215.GG1868@goldbirke>
On 12/16/2011 2:32 PM, SZEDER Gábor wrote:
> Hi,
>
>
> Briefly:
>
> Neighboring areas of a file are modified in two branches. Git
> merges the two branches without conflicts, but the result is not
> semantically correct. How can I teach git to produce the correct
> merge result when performing the same merge later on?
>
>
> Longer:
>
> The following commands create a file and two branches, both of them
> modifying the file by adding lines in the same area:
>
> git init cat>file<<\EOF 1
>
> 2 EOF git add file git commit -m file git apply<<\EOF diff --git
> a/file b/file index 1c3e7efc..121366a2 100644 --- a/file +++ b/file
> @@ -1,3 +1,5 @@ 1
>
> +a + 2 EOF git commit -a -m a git checkout -b branch HEAD^ git
> apply<<\EOF diff --git a/file b/file index 1c3e7efc..f2e91d4f 100644
> --- a/file +++ b/file @@ -1,3 +1,6 @@ 1 +b + +c
>
> 2 EOF git commit -a -m 'b c' git checkout master
>
>
> At this point I merge 'branch' and git produces the following
> result:
>
> $ git merge branch Auto-merging file Merge made by the 'recursive'
> strategy. file | 3 +++ 1 files changed, 3 insertions(+), 0
> deletions(-) $ cat file 1 b
>
> c
>
> a
>
> 2
>
>
> Now, these changes and the merge above are the minimal receipe which
> corresponds to a real merge I'm having trouble with at dayjob. Just
> imagine that '1' and '2' are the beginning and end of a function,
> 'b' is the declaration of a new local variable, and 'a' and 'c' are
> new code blocks. As it happens, the semantically correct result
> would be the following:
>
> 1 b
>
> a
>
> c
>
> 2
>
> i.e. 'a' must be executed before 'c'.
>
> I corrected the merge result manually, but these two branches are
> merged a couple of times a day into an integration branch, and they
> will likely cook for a few weeks, which means a lot of merges, and a
> lot of manual corrections. So I'm looking for a way to teach git to
> produce the semantically correct merge result. Something like
> 'rerere' would be great, but of course I can't use 'rerere' in this
> case, because there are no merge conflicts at all...
>
> Any ideas? Did someone deal with similar issues before?
>
You can produce conflicts by implementing keyword expansion on "line 1"
(or whatever the first commentable line is in your language) of your
source changes during your pre-commit hook. We do a keyword expansion
on "user" (whomai) and "date" (date) keywords. This will cause "line 1"
to conflict on same file edits in a merge. As for trusting rerere, we
don't. We do it manually with kdiff3 as the mergetool. If rerere works
for you reliably in this scenario then I'd like to know about it.
v/r,
neal
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Junio C Hamano @ 2011-12-16 21:21 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ralf Thielow, git
In-Reply-To: <vpqr504wf70.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Ralf Thielow <ralf.thielow@googlemail.com> writes:
>
>> There's a bug in git-1.7.8 if you use the attribute "eol" with "crlf".
>>
>> Steps to reproduce:
>> - add and commit a text file which uses 0d0a for line breaks
>> 7465 7374 0d0a 0d0a 7465 7374 0d0a test....test..
>> - add ".gitattributes" with "*.txt eol=crlf"
>> - change a line in the file
>> - execute "git checkout [file]"
>>
>> The result is:
>> 7465 7374 0d0d 0a0d 0d0a 7465 7374 0d0d test......test..
>
> It seems to me to be the expected behavior. You committed a file whose
> line endings are not normalized to LF in the repository, and asked for a
> conversion LF -> CRLF on checkout, which Git did.
>
> Git can't know exactly the moment when you edit .gitattributes, so it
> can't do the conversion at the time you add the eol=crlf attribute. It
> does it on checkout.
>
>> 0d0a was replaced by 0d0d0a.
>
> I'd say 0a (LF) was replaced by 0d0a (CRLF).
>
> What behavior would you have expected?
The sequence adds "test\r\n" file without .gitattributes to have the
repository record that exact byte sequence for the file. But then later
goes around and says "This file wants to express the end of line with CRLF
on the filesystem, so please replace LF in the repository representation
to CRLF when checking out, and replace CRLF in the working tree to LF when
checking in".
So it is not surprising that "\r\n" coming from the repository is replaced
to "\r\r\n" when checked out. As far as the repository data is concerned,
that line has a funny byte with value "\r" at the end, immediately before
the line terminator "\n".
What you said is _technically_ correct in that sense.
However, I think the CRLF filter used to have a hack to strip "\r" if the
repository data records "\r" at the end of line. This was intended to help
people who checked in such a broken text file (if it is a text file, then
raw ascii CR does not have a place in it in the repository representation)
and it was a useful hack to help people recover from such mistakes to
start the project from DOS-only world (with CRLF in the repository data)
and migrate to cross platform world (with LF in the repository data, CRLF
in the DOS working tree). I suspect that the streaming filter conversion
may not have the same hack in it.
^ permalink raw reply
* Re: [PATCH] pretty: give placeholders to reflog identity
From: Junio C Hamano @ 2011-12-16 21:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111216114024.GA16965@sigill.intra.peff.net>
Makes sense; thanks.
With the existing helper format_person_part(), this is surprisingly
simple. Perhaps I should not be surprised ;-).
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Ralf Thielow @ 2011-12-16 20:53 UTC (permalink / raw)
To: Adam Borowski; +Cc: Matthieu Moy, git
In-Reply-To: <20111216200955.GA8499@angband.pl>
> And how exactly can it change the file back the way it was?
It shouldn't need to change the file back. That's actually the bug. :/
^ permalink raw reply
* Re: [PATCH] docs: brush up obsolete bits of git-fsck manpage
From: Junio C Hamano @ 2011-12-16 20:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111216113310.GA16601@sigill.intra.peff.net>
Makes sense; thanks.
By the way did you hand-tweak your patch in any way?
I am not complaining that it does not apply (it does), but I am curious
how you got the line that begins with "corruption it finds ..." neatly in
preimage and postimage; it could become a common line but doing so makes
the patch unreadable and that is what I am getting from "git show" after
applying the patch.
^ permalink raw reply
* Re: How to automatically correct an almost correct auto-merge?
From: Seth Robertson @ 2011-12-16 20:39 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20111216203215.GG1868@goldbirke>
> How can I teach git to produce the correct merge result when
> performing the same merge later on?
Custom merge driver.
Type `man gitattributes` and search for "custom merge driver"
Your merge driver can have whatever policy you can program, on a per
file basis.
-Seth Robertson
^ permalink raw reply
* Re: [PATCH] use custom rename score during --follow
From: Junio C Hamano @ 2011-12-16 20:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111216112749.GA16314@sigill.intra.peff.net>
Makes sense; thanks.
^ permalink raw reply
* How to automatically correct an almost correct auto-merge?
From: SZEDER Gábor @ 2011-12-16 20:32 UTC (permalink / raw)
To: git
Hi,
Briefly:
Neighboring areas of a file are modified in two branches. Git merges
the two branches without conflicts, but the result is not semantically
correct. How can I teach git to produce the correct merge result when
performing the same merge later on?
Longer:
The following commands create a file and two branches, both of them
modifying the file by adding lines in the same area:
git init
cat >file <<\EOF
1
2
EOF
git add file
git commit -m file
git apply <<\EOF
diff --git a/file b/file
index 1c3e7efc..121366a2 100644
--- a/file
+++ b/file
@@ -1,3 +1,5 @@
1
+a
+
2
EOF
git commit -a -m a
git checkout -b branch HEAD^
git apply <<\EOF
diff --git a/file b/file
index 1c3e7efc..f2e91d4f 100644
--- a/file
+++ b/file
@@ -1,3 +1,6 @@
1
+b
+
+c
2
EOF
git commit -a -m 'b c'
git checkout master
At this point I merge 'branch' and git produces the following result:
$ git merge branch
Auto-merging file
Merge made by the 'recursive' strategy.
file | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
$ cat file
1
b
c
a
2
Now, these changes and the merge above are the minimal receipe which
corresponds to a real merge I'm having trouble with at dayjob. Just
imagine that '1' and '2' are the beginning and end of a function, 'b'
is the declaration of a new local variable, and 'a' and 'c' are new
code blocks. As it happens, the semantically correct result would be
the following:
1
b
a
c
2
i.e. 'a' must be executed before 'c'.
I corrected the merge result manually, but these two branches are
merged a couple of times a day into an integration branch, and they
will likely cook for a few weeks, which means a lot of merges, and a
lot of manual corrections. So I'm looking for a way to teach git to
produce the semantically correct merge result. Something like
'rerere' would be great, but of course I can't use 'rerere' in this
case, because there are no merge conflicts at all...
Any ideas? Did someone deal with similar issues before?
Thanks,
Gábor
^ permalink raw reply related
* Re: [BUG] attribute "eol" with "crlf"
From: Adam Borowski @ 2011-12-16 20:09 UTC (permalink / raw)
To: Ralf Thielow; +Cc: Matthieu Moy, git
In-Reply-To: <CAN0XMOJFCwORt_VaddgeeCNp3S-nm8DxYDPDyPCsVngRhuEP6A@mail.gmail.com>
On Fri, Dec 16, 2011 at 07:28:22PM +0100, Ralf Thielow wrote:
> > What behavior would you have expected?
>
> I've expected that git doesn't change the line endings
> because it's already CRLF.
And how exactly can it change the file back the way it was?
s/\n/\r\n/g is roundtrippable, s/\r?\n/\r\n/g is not.
--
1KB // Yo momma uses IPv4!
^ permalink raw reply
* git-svn: multiple fetch lines
From: Nathan Gray @ 2011-12-16 19:51 UTC (permalink / raw)
To: git
Hello,
I'm in a conversation with the support fellow of the very nice Tower
git interface for OS X and we need clarification on a point. Does
git-svn explicitly support multiple "fetch =" lines in an svn-remote
section or is it just an accident that it works? My belief is that
such support is intended and his is that it is accidental.
You can see a more detailed explanation of why you would want to use
multiple fetch lines on this fellow's blog post:
http://davegoodell.blogspot.com/2009/04/multiple-remote-branches-in-git-svn.html
My company's svn server layout is a bit of a mess and to work around
that I've been using multiple "fetch" lines in git-svn's config:
[svn-remote "svn"]
url = https://...
# The trunk
fetch = foo/trunk/Product:refs/remotes/trunk
# Some individual branches from messy directories that I can't use globs on
fetch = foo/branches/Developers/Nathan/Project/Product:refs/remotes/product-orig
fetch = foo/branches/august-demo/Product:refs/remotes/august-demo
# A well-organized branches folder that I can use a glob for
branches = foo/branches/Product/*:refs/remotes/branches/*
# etc...
Tower doesn't currently support such configurations and I'd like to
convince them that this is a perfectly sensible thing to do.
Thanks,
-Nathan
--
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org
^ permalink raw reply
* Re: git-p4.skipSubmitEdit
From: Luke Diamand @ 2011-12-16 19:50 UTC (permalink / raw)
To: Michael Horowitz; +Cc: Pete Wyckoff, L. A. Linden Levy, git
In-Reply-To: <CAFLRboo8DBk3zFEBF9OqKmre=d5PM7+3J9V0pHNz53MPtqjOWA@mail.gmail.com>
On 16/12/11 15:38, Michael Horowitz wrote:
> All,
>
> It appears that this change has introduced a bug that causes submit to
> fail every time if you do not skip the submit edit.
>
> From what I can tell, this is because the new edit_template method
> does not return True at the end.
Could you say exactly what you're doing?
I've just tried it myself and it seems to work fine:
git-p4 clone
git commit -m 'a change'
git-p4 submit
<quit from editor, with/without modifying it>
And I couldn't see any paths in edit_template that returned without a
value of True, except the one where the user decides to bail out.
This is with Pete's skipSubmitEdit change.
Thanks!
Luke
^ permalink raw reply
* Re: git-p4 using notes
From: Luke Diamand @ 2011-12-16 19:55 UTC (permalink / raw)
To: Michael Horowitz; +Cc: git
In-Reply-To: <CAFLRbori1Dinc2epputWfjgCOWp7M2f=+TA0w2jHq_fmRC=y3w@mail.gmail.com>
On 16/12/11 16:07, Michael Horowitz wrote:
> For those of you using git-p4 because of a company requirement to use
> Perforce, but really wish you could use git only, the most frustrating
> part is the fact that when changes are submitted, the commit message
> is rewritten to include a reference to the P4 change number which is
> used by the sync. When syncing back changes, this causes the commit
> hash to be different, and so blows away your old commit and any parent
> commit references and such.
>
> I read someplace, I can't remember where at this point, that if git-p4
> used notes to write the P4 change information, that would not impact
> the commit hash, so when merging back, things would not be
> overwritten, and you can maintain branches and commit history properly
> in git.
>
> I just ran into this project, where it seems that someone has
> re-written git-p4 to use notes: https://github.com/ermshiperete/git-p4
>
> I was wondering if any of the maintainers of git-p4 has considered
> this, and might want to leverage this work to merge into the main git
> repo, possibly with an option to choose between the two behaviors.
I'm not sure I qualify for such a grand title as maintainer, but I was
going to give this a go in the new year as it would be quite useful,
unless someone beat me to it. I want to fix some problems with labels
first though.
Regards!
Luke
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Junio C Hamano @ 2011-12-16 19:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: Jeff King, git, Brandon Casey
In-Reply-To: <A8E08CC616E248EC8F9000DD86F228E0@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
Administrivia: do not quote the whole message if you are only responding
to one small detail; cull the part you are not responding to. Thanks.
>> + "*.m diff=objc",
>
> There is a conflict here with the Matlab community which also uses "*.m"
> files for its scripts and code. They fit the "It's not that hard to do,
> but it's an extra step that the user might not even know is an option."
> rationale.
> ...
>
> If the objc.m is used as a default it must be overidable easily, and
> listed in the appropriate documentation to mitigate the "might not
> even know" risk.
Even if we did so, I suspect that projects around Matlab would have to say
"Give attributes *.m diff=matlab" in their README files anyway, so if we
accept that, it wouldn't be too much additional trouble for the same
README files to also say "Specify diff.matlab.xfuncname to this pattern"
as well. So in a sense, it might help reducing the confusion if we
dropped the built-in Matlab pattern rule we recently added.
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Junio C Hamano @ 2011-12-16 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git, Brandon Casey
In-Reply-To: <20111216192104.GA19924@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm not clear from what you wrote on whether you were saying it is
> simply sub-optimal, or whether on balance it is way worse than the
> default funcname matching.
I think we recently saw that the optional built-in one for C did not even
understand a function that returns a pointer, and nobody complained about
it for a long time, and what was even more funny was that a patch to fix
it got a comment from somebody who wasn't using the optional built-in one
saying "The default works fine; what problem are you fixing?". That is
clearly one example where the default one is still better than the pattern
based one, iow, the pattern based one is way premature to be turned on by
default.
> And if it is bad on balance, is the right solution to avoid exposing
> people to it, or is it to make our patterns better?
Can't we do both, by avoid exposing normal users to broken one while
people who want to improve the pattern based one work on unbreak it?
> I.e., is it fixable,
> or is it simply too hard a problem to get right in the general case, and
> we shouldn't turn it on by default?
I do not think that is the "either-or" question. My impression has been
that even if it is fixable, it is too broken and produces worse result
than the simple default in its current form.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox