* Re: [RFC/PATCH 3/7] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Christian Couder @ 2009-01-15 9:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4esf0tv.fsf@gitster.siamese.dyndns.org>
Le mardi 13 janvier 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > diff --git a/replace_object.c b/replace_object.c
> > new file mode 100644
> > index 0000000..25b3ef3
> > --- /dev/null
> > +++ b/replace_object.c
> > @@ -0,0 +1,116 @@
> > +#include "cache.h"
> > +#include "refs.h"
> > +
> > +static struct replace_object {
> > + unsigned char sha1[2][20];
> > +} **replace_object;
> > +
> > +static int replace_object_alloc, replace_object_nr;
> > +
> > +static int replace_object_pos(const unsigned char *sha1)
> > +{
> > + int lo, hi;
> > + lo = 0;
> > + hi = replace_object_nr;
> > + while (lo < hi) {
> > + int mi = (lo + hi) / 2;
> > + struct replace_object *rep = replace_object[mi];
> > + int cmp = hashcmp(sha1, rep->sha1[0]);
> > + if (!cmp)
> > + return mi;
> > + if (cmp < 0)
> > + hi = mi;
> > + else
> > + lo = mi + 1;
> > + }
> > + return -lo - 1;
> > +}
>
> Hmm, this is a tangent of this topic, but I wonder if we can do something
> more generic to factor out many binary search like this we have
> throughout the code. Also I wonder if they can be made more efficient by
> taking advantage of the fact that our hash is expected to produce a good
> uniform distribution, similar to the way patch-ids.c::patch_pos() does
> this.
>
> I guess the performance should not matter much for this table, as we
> expect there won't be massive object replacements.
>
> Also I recall Dscho muttered something about hashmap I didn't quite
> understand.
Yeah, maybe it's possible to get faster code and to refactor the
many binary search we have, but I will leave that for latter or for other
people interested in these topics, if you let me.
> > +static int register_replace_ref(const char *refname,
> > + const unsigned char *sha1,
> > + int flag, void *cb_data)
> > +{
> > + /* Get sha1 from refname */
> > + const char *slash = strrchr(refname, '/');
> > + const char *hash = slash ? slash + 1 : refname;
> > + struct replace_object * repl_obj = xmalloc(sizeof(*repl_obj));
>
> struct replace_object *repl_obj = ...
Ok.
> > + if (strlen(hash) != 40 || get_sha1_hex(hash, repl_obj->sha1[0])) {
> > + free(repl_obj);
> > + warning("bad replace ref name: %s", refname);
> > + }
> > +
> > + /* Copy sha1 from the read ref */
> > + hashcpy(repl_obj->sha1[1], sha1);
>
> Upon an error, you free and warn and then still copy into it?
Ooops, I forgot a "return 0;" statement after the warning.
> > + /* Register new object */
> > + if (register_replace_object(repl_obj, 1))
> > + warning("duplicate replace ref: %s", refname);
>
> I'd say this is a grave error and should be reported as a repository
> corruption.
If we let people have a set of replace refs in "refs/replace/" and another
one in "refs/replace/bisect/", and the latter one is used only when
bisecting, then it may happen that the same commit has one ref
in "refs/replace/" and another one in "refs/replace/bisect/". In this case
it should probably be considered as something we should not even warn on,
and the replace ref in "refs/replace/bisect/" should be used when
bisecting.
But, as we don't have a mechanism to do that yet, you are right, we should
probably "die" for now here.
> > +static void prepare_replace_object(void)
> > +{
> > + static int replace_object_prepared;
> > +
> > + if (replace_object_prepared)
> > + return;
> > +
> > + for_each_replace_ref(register_replace_ref, NULL);
> > + replace_object_prepared = 1;
> > +}
> > +
> > +/* We allow "recursive" replacement. Only within reason, though */
> > +#define MAXREPLACEDEPTH 5
> > +
> > +const unsigned char *lookup_replace_object(const unsigned char *sha1)
> > +{
> > + int pos, depth = MAXREPLACEDEPTH;
> > + const unsigned char *cur = sha1;
> > +
> > + prepare_replace_object();
> > +
> > + /* Try to recursively replace the object */
> > + do {
> > + if (--depth < 0)
> > + die("replace depth too high for object %s",
> > + sha1_to_hex(sha1));
> > +
> > + pos = replace_object_pos(cur);
> > + if (0 <= pos)
> > + cur = replace_object[pos]->sha1[1];
> > + } while (0 <= pos);
> > +
> > + return cur;
> > +}
>
> Since your paradigm is prepare replacement once at the beginning, never
> allowing to update it, I think you can update the table while you look it
> up. E.g. if A->B and B->C exists, and A is asked for, you find A->B (to
> tentatively make cur to point at B) and then you find B->C, and before
> returning you can rewrite the first mapping to A->C. Later look-up won't
> need to dereference the table twice that way.
>
> This assumes that there will be small number of replacements, but the
> same object can be asked for more than once during the process.
If we allow different sets of replace refs, for example A->B
in "refs/replace/" and B->C in "refs/replace/bisect/", then we cannot
rewrite as you suggest. We could add A->C in "refs/replace/bisect/", so
that it overcomes A->B and B->C when we bisect, but we would not gain much.
So I prefer not to do that right now. Maybe later if we decide we really
don't want to allow different sets of replace refs, we can do what you
suggest.
> > diff --git a/sha1_file.c b/sha1_file.c
> > index f08493f..4f2fd10 100644
> > --- a/sha1_file.c
> > +++ b/sha1_file.c
> > @@ -2163,10 +2163,18 @@ static void *read_object(const unsigned char
> > *sha1, enum object_type *type, void *read_sha1_file(const unsigned char
> > *sha1, enum object_type *type, unsigned long *size)
> > {
> > - void *data = read_object(sha1, type, size);
> > + const unsigned char *repl = lookup_replace_object(sha1);
> > + void *data = read_object(repl, type, size);
> > +
> > + /* die if we replaced an object with one that does not exist */
> > + if (!data && repl != sha1)
> > + die("replacement %s not found for %s",
> > + sha1_to_hex(repl), sha1_to_hex(sha1));
> > +
> > /* legacy behavior is to die on corrupted objects */
> > - if (!data && (has_loose_object(sha1) || has_packed_and_bad(sha1)))
> > - die("object %s is corrupted", sha1_to_hex(sha1));
> > + if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
> > + die("object %s is corrupted", sha1_to_hex(repl));
> > +
> > return data;
> > }
>
> Later we'd need a global switch to forbid the replacement for
> connectivity walkers,
Yeah, I am slowly working on it. My next series (hopefully in a few days)
where the above errors are fixed will include it.
> but other than that I think this is sane.
>
> I also looked at 1/ and 2/ which looked Ok.
Thanks,
Christian.
^ permalink raw reply
* Re: [StGit PATCH] Check for local changes with "goto"
From: Karl Hasselström @ 2009-01-15 8:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090114225945.11098.88671.stgit@localhost.localdomain>
I'm not opposed to the change as such (even if I personally think it's
very convenient to allow operations like goto if the local changes
don't touch the same files), but ...
On 2009-01-14 22:59:45 +0000, Catalin Marinas wrote:
> stgit/commands/common.py | 7 +++++++
> stgit/commands/goto.py | 8 +++++++-
... are you sure it wouldn't be better to build the check into
transaction.py, so that all new-infrastructure command would share it?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH replacement for take 3 4/4] color-words: take an optional regular expression describing words
From: Thomas Rast @ 2009-01-15 8:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Santi Béjar, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901150235122.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Johannes Schindelin wrote:
> If a hunk header '@@ -2 +1,0 @@' is found that logically should be
> '@@ -2 +2,0 @@', diff_words got confused.
[...]
> This might be a libxdiff issue, though.
Looks like it's just bug-for-bug compatible with diff. At least my
GNU diffutils 2.8.7 show the same behaviour.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [StGit PATCH] Add --file option to pick
From: Karl Hasselström @ 2009-01-15 8:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090114225930.11098.2144.stgit@localhost.localdomain>
On 2009-01-14 22:59:30 +0000, Catalin Marinas wrote:
> + opt('-f', '--files', action = 'append',
> + short = 'Only fold the given files'),
The long form should probably be "--file", since you only list one
file for every flag (and since you call it "--file" in the last hunk).
And the help text could be something like
Only fold the given file (for multiple files, use -f more than once)
> + raise CmdException, 'Patch folding failed'
This is not important, but I believe the recommended syntax for
raising exceptions nowadays is
CmdException('Patch folding failed')
since that's what'll continue to work in Python 3, or something like
that. (I see you already use it in the multi-line case in the other
patch, where this syntax is clearly the better choice.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Clemens Buchacher @ 2009-01-15 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes
In-Reply-To: <7vvdshzfpk.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 14, 2009 at 02:27:03PM -0800, Junio C Hamano wrote:
> In places we read paths from the index or from the work tree and add them
> as pathspec elements---you would want to mark them as non-globbing, too.
> Which probably means that "is it Ok to glob this" setting has to be per
> pathspec array elements.
Right. This certainly complicates things. Also note that this invalidates
1/3, because even if '?' matched exactly, it can still match '*', and vice
versa. Depending on ordering one of these two cases would pose a problem.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Sixt @ 2009-01-15 7:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Anders Melchiorsen, git, gitster
In-Reply-To: <alpine.DEB.1.00.0901150149130.3586@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
>> Previously, the interactive rebase edit mode placed the user after the
>> commit in question. That was awkward because a commit is supposedly
>> immutable. Thus, she was forced to use "git commit --amend" for her
>> changes.
>
> Maybe, maybe not. I frequently rebase with "edit" when I actually mean
> "stop" (but "s" was taken from "squash" already). Then I test things,
> possibly fixing them.
>
> So in that case, I do not want a git reset --soft HEAD^.
Absolutely! I use "edit" for this purpose as well quite frequently.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Sixt @ 2009-01-15 7:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1231978322-21228-1-git-send-email-trast@student.ethz.ch>
Thomas Rast schrieb:
> Let git-checkout save the old branch as a symref in LAST_HEAD, and
> make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> the shell.
/me likes this feature.
git rebase (-i or not) calls checkout behind the scenes if the
two-argument form is used:
git rebase [-i] master topic
and 'topic' is not the current branch. You may want to add a test that
ensures that rebase sets LAST_HEAD in this case.
You must make sure that commits referenced by LAST_HEAD are not
garbage-collected. (I don't know if this happens anyway for symrefs in .git.)
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Junio C Hamano @ 2009-01-15 6:13 UTC (permalink / raw)
To: Miles Bader
Cc: Boyd Stephen Smith Jr., Anders Melchiorsen, git,
Johannes.Schindelin
In-Reply-To: <buo8wpdfbv9.fsf@dhapc248.dev.necel.com>
Miles Bader <miles@gnu.org> writes:
> [I do wonder how on earth the current awkward behavior was accepted in
> the first place...]
That's actually very easy to explain. Both the contributor and the
maintainer were rather familiar with the workflow using tools before
"rebase -i" appeared, and to them, editing an existing commit was
equivalent to first plant yourself on the commit to be amended, issue
"commit --amend", and continue on with other tasks (similarly, "picking" an
existing commit is to cherry-pick the commit to the state whatever the
previous sequence of commands left). In other words, they both thought in
terms of the underlying command sequence and it did not appear unnatural
at all to them.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Boyd Stephen Smith Jr. @ 2009-01-15 5:00 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <buo8wpdfbv9.fsf@dhapc248.dev.necel.com>
[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]
On Wednesday 14 January 2009, Miles Bader <miles@gnu.org> wrote about 'Re:
[RFC PATCH] Make the rebase edit mode really end up in an edit state':
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>>>We may need a version bump to 1.7.0 to update the UI for this command,
>>> but please do test rigorously to build a stronger case for a saner UI.
>>
>> Instead of changing the meaning of edit, how about introducing a
>> "replace" command?
>
>That seems like at best an awkward workaround, not a real solution to
>the problem,
Actually, I think it's a better solution (or rather a solution to the real
problem) because others have already said they like and expect the current
edit behavior.
The "real problem" is you need different behavior for your interactive
rebasing.
>which is that the term "edit XXXX" suggests you're starting
>with XXXX and modifying it.
Exactly. "edit" is: While interactively rebuilding history (rebase -i), you
get to the first place that commit existed and then modify it
(commit --amend or other tools).
>The term "replace" by contrast, seems more
>to connote entirely removing XXXX and substituting something else.
Exactly. "replace" is: While rebasing you stop just before the commit
existed (changes are even staged) and decide to do something else (like
using add -i and a few commit commands to split the thing up or whatever).
>[I do wonder how on earth the current awkward behavior was accepted in
>the first place...]
(Actually, I do too, but it's accepted and expected behavior now--good
reason not to change it.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Teemu Likonen @ 2009-01-15 4:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Junio C Hamano, git, Santi Béjar
In-Reply-To: <alpine.DEB.1.00.0901142258250.3586@pacific.mpi-cbg.de>
Johannes Schindelin (2009-01-14 23:06 +0100) wrote:
> On Wed, 14 Jan 2009, Thomas Rast wrote:
>> -aaa [aaa]
>> +aaa (aaa) aaa
>>
>> would still give you
>>
>> aaa (aaa)<GREEN> aaa<RESET>
>>
>> which may be unexpected.
>
> But why should it be unexpected? If people say that every length of "a"
> makes a word, and consequently everything else is clutter, then that's
> that, no?
It works logically but I'd very much like to see a some kind of advice
in the man page. I already faced this (unexpected) situation and wasn't
able to fix the regexp myself.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Miles Bader @ 2009-01-15 4:10 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Junio C Hamano, Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <200901142049.54775.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>>We may need a version bump to 1.7.0 to update the UI for this command,
>> but please do test rigorously to build a stronger case for a saner UI.
>
> Instead of changing the meaning of edit, how about introducing a "replace"
> command?
That seems like at best an awkward workaround, not a real solution to
the problem, which is that the term "edit XXXX" suggests you're starting
with XXXX and modifying it. The term "replace" by contrast, seems more
to connote entirely removing XXXX and substituting something else.
[I do wonder how on earth the current awkward behavior was accepted in
the first place...]
-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I
^ permalink raw reply
* Re: jgit merge question
From: Shawn O. Pearce @ 2009-01-15 4:01 UTC (permalink / raw)
To: David Birchfield; +Cc: git
In-Reply-To: <7F1F22DF-7E4F-4888-A404-2A68F663989A@asu.edu>
David Birchfield <dbirchfield@asu.edu> wrote:
> thanks again for your help, and really sorry for the newbie questions.
>
> how do I grab those 8 commits?
>
> I did originally use git clone on this uri: git://
> android.git.kernel.org/tools/egit.git - but I don't see the
> modifications there.
They are in a side branch:
git pull git://android.git.kernel.org/tools/egit.git for-gerrit2
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3] parse-opt: migrate builtin-ls-files.
From: Miklos Vajna @ 2009-01-15 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vljtdw961.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
On Wed, Jan 14, 2009 at 07:16:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I am not fundamentally opposed to the parseopt conversion, but I was
> somewhat discouraged from taking another one, after we got burned by the
> one that converted git-apply without much visible gain but with a new bug.
>
> Because ls-files is a plumbing, it has somewhat lower priority for user
> friendliness than any other patches currently in-flight on the list; hence
> it has been backburnered. It still is kept in my Inbox.
Makes sense, thanks for the answer.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: jgit merge question
From: David Birchfield @ 2009-01-15 3:47 UTC (permalink / raw)
To: git
In-Reply-To: <20090114231222.GB10179@spearce.org>
thanks again for your help, and really sorry for the newbie questions.
how do I grab those 8 commits?
I did originally use git clone on this uri: git://
android.git.kernel.org/tools/egit.git - but I don't see the
modifications there.
thanks again,
david
On Jan 14, 2009, at 4:12 PM, Shawn O. Pearce wrote:
>>
>
> Instead of copying 4 files, why don't you actually fetch the 8
> commits and merge them into your local repository? You are getting
> build errors because you didn't get an exception type in the errors
> directory, and at least two existing classes had new methods added
> to them in order to support the merge API.
>
> --
> Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Zooko's merge testcase
From: Johannes Schindelin @ 2009-01-15 3:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, zooko
In-Reply-To: <1231980818-24812-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Thu, 15 Jan 2009, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
I think the idea can be simplified. Given lines A, B, C in the base
commit, one branch _prepending_ the same triplet, and the other branch
changing the B to a D.
Only this time, nobody has a chance, even Darcs, because from the diff,
you would not know if it was prepended or appended.
(Which happens to be the same problem as 3-way merge has with the example
you were implementing; only when looking at the detailed history becomes
it clear what was done.)
This all just proves again that there can be no perfect merge strategy;
you'll always have to verify that the right thing was done.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make t3411 executable
From: Junio C Hamano @ 2009-01-15 3:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1231979599-24534-1-git-send-email-vmiklos@frugalware.org>
Thanks.
^ permalink raw reply
* Re: [PATCH v3] parse-opt: migrate builtin-ls-files.
From: Junio C Hamano @ 2009-01-15 3:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pierre Habouzit, git
In-Reply-To: <20090115001410.GE30710@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Was this dropped on the floor by accident?
I am not fundamentally opposed to the parseopt conversion, but I was
somewhat discouraged from taking another one, after we got burned by the
one that converted git-apply without much visible gain but with a new bug.
Because ls-files is a plumbing, it has somewhat lower priority for user
friendliness than any other patches currently in-flight on the list; hence
it has been backburnered. It still is kept in my Inbox.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Boyd Stephen Smith Jr. @ 2009-01-15 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <7vfxjlxuu5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Wednesday 14 January 2009, Junio C Hamano <gitster@pobox.com> wrote
about 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit
state':
>Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>> I always have a hard time figuring out what to do during an
>> interactive rebase. Recently, it dawned on me that the reason is that
>> I have to do different things: one thing when editing on purpose, and
>> a different thing when resolving a conflict.
>>
>> With this change, I propose to make the UI more uniform. I think that
>> the new way is more intuitive, too, if you will agree that a Git UI
>> can be intuitive.
>>
>> I expect this to not be acceptable due to compatibility concerns.
>
>We may need a version bump to 1.7.0 to update the UI for this command,
> but please do test rigorously to build a stronger case for a saner UI.
Instead of changing the meaning of edit, how about introducing a "replace"
command?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: bill lam @ 2009-01-15 1:46 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20090114235607.GA5546@diku.dk>
On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> Yes, it works. You can either create a file called config.make with a
> line saying:
>
> LDLIBS = -lncursesw
>
> or use the configure file. If you are not using the tarball generate it
> with:
>
> make configure
I use the git source. Even after make configure and ./configure, it
still links to the non-unicode ncurses. Should it make ncursesw as
default if detected available albeit this can be changed manually?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩319 李白 清平調三首之三
名花傾國兩相歡 常得君王帶笑看 解釋春風無限恨 沈香亭北倚闌干
^ permalink raw reply
* Re: [PATCH 4/4] color-words: make regex configurable via attributes
From: Johannes Schindelin @ 2009-01-15 1:43 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901150233121.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> @@ -136,10 +131,11 @@ cat > expect <<\EOF
> aaa (aaa) <GREEN>aaa<RESET>
> EOF
>
> -test_expect_success "test parsing words for newline" '
> +test_expect_success 'test parsing words for newline' '
> +
> + word_diff --color-words="a+"
>
> - word_diff --color-words="a+" &&
> - word_diff_check expect
> + word_diff --color-words=.
>
> '
D'oh. please remove the last word_diff, this comes from my "fix" for your
smiley issue.
Ciao,
Dscho "off to bed"
--
"The night was so dark that he hardly coulx srr tje keuboarf."
^ permalink raw reply
* Re: how to apply patch in the middle
From: Shawn O. Pearce @ 2009-01-15 1:39 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090115013535.GB6937@b2j>
bill lam <cbill.lam@gmail.com> wrote:
> I want to change history to rewrite
>
> - A - B - C - D - E - ..
>
> as
>
> - A - C' - D - E - ..
Uh, "git rebase -i A", change "pick" on line "C" to "squash".
This should have the same impact as what you are trying.
> because rebase/squash cannot automatically resolve conflicts, I
> generate a patch file from A to C
>
> git diff A C >pat
>
> However I don't know how apply this patch and cancel the old B and C.
One way you can insert this is:
git rebase -i A^
change "pick" on line "A" to "edit"
delete lines "B" and "C".
when it stops for amend, don't amend.
git apply --index pat
git commit -m "my new B and C"
git rebase --continue
--
Shawn.
^ permalink raw reply
* Re: [PATCH replacement for take 3 4/4] color-words: take an optional regular expression describing words
From: Johannes Schindelin @ 2009-01-15 1:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901150211120.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Thomas Rast wrote:
>
> > Johannes Schindelin wrote:
> > > This basically contains the fix I sent earlier.
> >
> > Unfortunately I found another case where it breaks. It even comes
> > with a fairly neat test case:
> >
> > $ g diff --no-index test_a test_b
> > diff --git 1/test_a 2/test_b
> > index 289cb9d..2d06f37 100644
> > --- 1/test_a
> > +++ 2/test_b
> > @@ -1 +1 @@
> > -(:
> > +(
>
> The diff of the words would look like this:
>
> diff --git a/a1 b/a2
> index 8309acb..2d06f37 100644
> --- a/a1
> +++ b/a2
> @@ -2 +1,0 @@
> -:
>
>
> Notice the "+1,0"? I fully expected this to be "+2,0", but apparently I
> was mistaken...
>
> Can anybody explain to me why this is so?
[PATCH to be squashed into the word regex patch] Fix for strange '@@ -2 +1,0 @@' hunk header
If a hunk header '@@ -2 +1,0 @@' is found that logically should be
'@@ -2 +2,0 @@', diff_words got confused.
It would bee squashed into 4/4.
This might be a libxdiff issue, though.
Not sure yet.
---
diff.c | 18 ++++++++++++++++++
t/t4034-diff-words.sh | 16 ++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index c5f7c57..3709651 100644
--- a/diff.c
+++ b/diff.c
@@ -360,6 +360,24 @@ static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
plus_end = plus_len == 0 ? plus_begin :
diff_words->plus.orig[plus_first + plus_len - 1].end;
+ /*
+ * since this is a --unified=0 diff, it can result in a single hunk
+ * with a header like this: @@ -2 +1,0 @@
+ *
+ * This breaks the assumption that minus_first == plus_first.
+ *
+ * So we have to fix it: whenever we reach the end of pre and post
+ * texts, but nothing was added, we need to shift the plus part
+ * to the end of the buffer.
+ *
+ * It is only necessary for the plus part, as we show the common
+ * words from that buffer.
+ */
+ if (plus_len == 0 && minus_first + minus_len
+ == diff_words->minus.orig_nr)
+ plus_begin = plus_end =
+ diff_words->plus.orig[diff_words->plus.orig_nr - 1].end;
+
if (diff_words->current_plus != plus_begin)
fwrite(diff_words->current_plus,
plus_begin - diff_words->current_plus, 1,
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 07e48d1..817fba6 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -135,6 +135,22 @@ test_expect_success 'test parsing words for newline' '
word_diff --color-words="a+"
+'
+
+echo '(:' > pre
+echo '(' > post
+
+cat > expect <<\EOF
+<WHITE>diff --git a/pre b/post<RESET>
+<WHITE>index 289cb9d..2d06f37 100644<RESET>
+<WHITE>--- a/pre<RESET>
+<WHITE>+++ b/post<RESET>
+<BROWN>@@ -1 +1 @@<RESET>
+(<RED>:<RESET>
+EOF
+
+test_expect_success 'test when words are only removed at the end' '
+
word_diff --color-words=.
'
--
1.6.1.300.gbc493
^ permalink raw reply related
* how to apply patch in the middle
From: bill lam @ 2009-01-15 1:35 UTC (permalink / raw)
To: git
I want to change history to rewrite
- A - B - C - D - E - ..
as
- A - C' - D - E - ..
because rebase/squash cannot automatically resolve conflicts, I
generate a patch file from A to C
git diff A C >pat
However I don't know how apply this patch and cancel the old B and C.
Sorry for this newbie question.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩008 杜甫 望嶽
岱宗夫如何 齊魯青未了 造化鍾神秀 陰陽割昏曉
盪胸生層雲 決眥入歸鳥 會當凌絕頂 一覽眾山小
^ permalink raw reply
* Re: [PATCH 4/4] color-words: make regex configurable via attributes
From: Johannes Schindelin @ 2009-01-15 1:33 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <b404fdfe0f5af535b35d1f239a68f6a7911ede19.1231971446.git.trast@student.ethz.ch>
Hi Thomas,
could you please squash this in?
-- snipsnap --
[PATCH to be squashed into the attributes patch] Decomplicate t4034 again
---
t/t4034-diff-words.sh | 50 ++++++++++++++++++++++--------------------------
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 631ca44..07e48d1 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -22,10 +22,8 @@ decrypt_color () {
word_diff () {
test_must_fail git diff --no-index "$@" pre post > output &&
- decrypt_color < output > output.decrypted
-}
-word_diff_check () {
- test_cmp "$1" output.decrypted
+ decrypt_color < output > output.decrypted &&
+ test_cmp expect output.decrypted
}
cat > pre <<\EOF
@@ -82,12 +80,25 @@ EOF
test_expect_success 'word diff with a regular expression' '
- word_diff --color-words="[a-z]+" &&
- word_diff_check expect
+ word_diff --color-words="[a-z]+"
'
-cat > expect-by-chars <<\EOF
+test_expect_success 'set a diff driver' '
+ git config diff.testdriver.wordregex "[^[:space:]]" &&
+ cat <<EOF > .gitattributes
+pre diff=testdriver
+post diff=testdriver
+EOF
+'
+
+test_expect_success 'option overrides default' '
+
+ word_diff --color-words="[a-z]+"
+
+'
+
+cat > expect <<\EOF
<WHITE>diff --git a/pre b/post<RESET>
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
@@ -102,25 +113,9 @@ a = b + c<RESET>
<GREEN>aeff = aeff * ( aaa )<RESET>
EOF
-test_expect_success 'set a diff driver' '
- git config diff.testdriver.wordregex "[^[:space:]]" &&
- cat <<EOF > .gitattributes
-pre diff=testdriver
-post diff=testdriver
-EOF
-'
-
test_expect_success 'use default supplied by driver' '
- word_diff --color-words &&
- word_diff_check expect-by-chars
-
-'
-
-test_expect_success 'option overrides default' '
-
- word_diff --color-words="[a-z]+" &&
- word_diff_check expect
+ word_diff --color-words
'
@@ -136,10 +131,11 @@ cat > expect <<\EOF
aaa (aaa) <GREEN>aaa<RESET>
EOF
-test_expect_success "test parsing words for newline" '
+test_expect_success 'test parsing words for newline' '
+
+ word_diff --color-words="a+"
- word_diff --color-words="a+" &&
- word_diff_check expect
+ word_diff --color-words=.
'
--
1.6.1.300.gbc493
^ permalink raw reply related
* Re: [PATCH replacement for take 3 4/4] color-words: take an optional regular expression describing words
From: Johannes Schindelin @ 2009-01-15 1:12 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901150132.14106.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > This basically contains the fix I sent earlier.
>
> Unfortunately I found another case where it breaks. It even comes
> with a fairly neat test case:
>
> $ g diff --no-index test_a test_b
> diff --git 1/test_a 2/test_b
> index 289cb9d..2d06f37 100644
> --- 1/test_a
> +++ 2/test_b
> @@ -1 +1 @@
> -(:
> +(
The diff of the words would look like this:
diff --git a/a1 b/a2
index 8309acb..2d06f37 100644
--- a/a1
+++ b/a2
@@ -2 +1,0 @@
-:
Notice the "+1,0"? I fully expected this to be "+2,0", but apparently I
was mistaken...
Can anybody explain to me why this is so?
Ciao,
Dscho
^ permalink raw reply related
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