* Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Johannes Schindelin @ 2007-07-08 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <7vabu765r0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 7 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -643,6 +643,20 @@ int threeway_merge(struct cache_entry **stages,
> > index = stages[0];
> > head = stages[o->head_idx];
> >
> > + /*
> > + * Special case: do not care about a dir/file conflict, when
> > + * the entries have not been touched.
> > + * IOW if the ancestors are identical to the remote, and the
> > + * index is the same as head, just take head.
> > + */
>
> Suppose paths "A" and "A/B" are involved, and you resolved with
> this logic to have "A" as a blob (so your HEAD does not have
> "A/B"). If the remote adds "A/B", what prevents the resulting
> index to have both "A" and "A/B" resolved at stage #0?
Hmm.
> A logic to do "if it is unchanged on one and changed in another,
> take changed one" already exists in later part of the code; your
> patch just circumvents D/F checks built into threeway_merge for
> this one case, and only because this one case happens to have
> reported. It doesn't feel right.
Well, for me the code in threeway_merge does not feel right. There is a
table in technical/trivial-merge.txt (which I not fully understand, since
nowhere in the table, there is a mention of the index, and nowhere is
explained what "ALT" is supposed to mean), but threeway_merge only
references the numbers. The code is not obvious to me.
I spent some hours staring on, and trying to make sense of it. Alas, I am
an idiot or something, since my brain feels like a mashed potato, and I
still do not understand the code. For example, it is not apparent to me
why the variable "head" should be set to NULL, when it was the
df_conflict_entry.
So yeah, this patch was marked as "PATCH", but the subject line is not
long enough for the proper prefix, which would have started like
"[This PATCH works for me, and I do not know how to make it better, since
I do not understand the code in threeway_merge(), and that does not make
me happy, but that is the way things are, and maybe someone more
intelligent than me recognizes what is meant by my little patch, and can
fix it up, ...]".
> IOW, don't make unpack-trees to make policy decisions on final
> resolution, unless it is operating under aggressive rule (where the
> caller explicitly allows it to make more than the "trivial" decisions).
> The caller (in this case, merge-recursive) should see A at stage #2 with
> A/B at stages #1 and #3 and decide what to do.
Okay, so you're saying that merge-recursive should use the aggressive
strategy?
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/3] rebase -i: handle --continue more like non-interactive rebase
From: Johannes Schindelin @ 2007-07-08 2:01 UTC (permalink / raw)
To: git, gitster
Non-interactive rebase requires the working tree to be clean, but
applies what is in the index without requiring the user to do it
herself. Imitate that, but (since we are interactive, after all)
fire up an editor with the commit message.
It also fixes a subtle bug: a forgotten "continue" was removed, which
led to an infinite loop when continuing without remaining patches.
Both issues noticed by Frank Lichtenheld.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 25 ++++++++++++++++---------
t/t3404-rebase-interactive.sh | 16 +++++++++++++++-
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0c2a969..67f2ee2 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -59,6 +59,10 @@ make_patch () {
}
die_with_patch () {
+ test -f "$DOTEST"/message ||
+ git cat-file commit $sha1 | sed "1,/^$/d" > "$DOTEST"/message
+ test -f "$DOTEST"/author-script ||
+ get_author_ident_from_commit $sha1 > "$DOTEST"/author-script
make_patch "$1"
die "$2"
}
@@ -140,10 +144,7 @@ pick_one_preserving_merges () {
if ! git merge $STRATEGY -m "$msg" $new_parents
then
echo "$msg" > "$GIT_DIR"/MERGE_MSG
- warn Error redoing merge $sha1
- warn
- warn After fixup, please use
- die "$author_script git commit"
+ die Error redoing merge $sha1
fi
;;
*)
@@ -154,11 +155,12 @@ pick_one_preserving_merges () {
}
do_next () {
+ test -f "$DOTEST"/message && rm "$DOTEST"/message
+ test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
read command sha1 rest < "$TODO"
case "$command" in
\#|'')
mark_action_done
- continue
;;
pick)
comment_for_reflog pick
@@ -201,6 +203,7 @@ do_next () {
git cat-file commit $sha1 | sed -e '1,/^$/d' >> "$MSG"
git reset --soft HEAD^
author_script=$(get_author_ident_from_commit $sha1)
+ echo "$author_script" > "$DOTEST"/author-script
case $failed in
f)
# This is like --amend, but with a different message
@@ -212,10 +215,6 @@ do_next () {
cp "$MSG" "$GIT_DIR"/MERGE_MSG
warn
warn "Could not apply $sha1... $rest"
- warn "After you fixed that, commit the result with"
- warn
- warn " $(echo $author_script | tr '\012' ' ') \\"
- warn " git commit -F \"$GIT_DIR\"/MERGE_MSG -e"
die_with_patch $sha1 ""
esac
;;
@@ -265,6 +264,14 @@ do
test -d "$DOTEST" || die "No interactive rebase running"
+ # commit if necessary
+ git rev-parse --verify HEAD > /dev/null &&
+ git update-index --refresh &&
+ git diff-files --quiet &&
+ ! git diff-index --cached --quiet HEAD &&
+ . "$DOTEST"/author-script &&
+ git commit -F "$DOTEST"/message -e
+
require_clean_work_tree
do_rest
;;
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 883cf29..c251336 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -63,7 +63,10 @@ test_expect_success 'setup' '
cat > fake-editor.sh << EOF
#!/bin/sh
-test "\$1" = .git/COMMIT_EDITMSG && exit
+test "\$1" = .git/COMMIT_EDITMSG && {
+ test -z "\$FAKE_COMMIT_MESSAGE" || echo "\$FAKE_COMMIT_MESSAGE" > "\$1"
+ exit
+}
test -z "\$FAKE_LINES" && exit
grep -v "^#" < "\$1" > "\$1".tmp
rm "\$1"
@@ -181,6 +184,7 @@ test_expect_success 'preserve merges with -p' '
echo C > file1 &&
test_tick &&
git commit -m K file1 &&
+ test_tick &&
git rebase -i -p --onto branch1 master &&
test $(git rev-parse HEAD^^2) = $(git rev-parse to-be-preserved) &&
test $(git rev-parse HEAD~3) = $(git rev-parse branch1) &&
@@ -188,4 +192,14 @@ test_expect_success 'preserve merges with -p' '
test $(git show HEAD~2:file1) = B
'
+test_expect_success '--continue tries to commit' '
+ test_tick &&
+ ! git rebase -i --onto new-branch1 HEAD^ &&
+ echo resolved > file1 &&
+ git add file1 &&
+ FAKE_COMMIT_MESSAGE="chouette!" git rebase --continue &&
+ test $(git rev-parse HEAD^) = $(git rev-parse new-branch1) &&
+ git show HEAD | grep chouette
+'
+
test_done
--
1.5.3.rc0.2712.g125b7f
^ permalink raw reply related
* [PATCH 2/3] rebase -i: actually show the diffstat when being verbose
From: Johannes Schindelin @ 2007-07-08 2:02 UTC (permalink / raw)
To: git, gitster
The "while" loop in the function do_rest is not supposed to ever be
exited. Instead, the function do_one checks if there is nothing left,
and cleans up and exits if that is the case. So the diffstat code
belongs there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 67f2ee2..84148a9 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -239,7 +239,10 @@ do_next () {
fi &&
message="$GIT_REFLOG_ACTION: $HEADNAME onto $SHORTONTO)" &&
git update-ref -m "$message" $HEADNAME $NEWHEAD $OLDHEAD &&
- git symbolic-ref HEAD $HEADNAME &&
+ git symbolic-ref HEAD $HEADNAME && {
+ test ! -f "$DOTEST"/verbose ||
+ git diff --stat $(cat "$DOTEST"/head)..HEAD
+ } &&
rm -rf "$DOTEST" &&
warn "Successfully rebased and updated $HEADNAME."
@@ -251,9 +254,6 @@ do_rest () {
do
do_next
done
- test -f "$DOTEST"/verbose &&
- git diff --stat $(cat "$DOTEST"/head)..HEAD
- exit
}
while case $# in 0) break ;; esac
--
1.5.3.rc0.2712.g125b7f
^ permalink raw reply related
* [PATCH 3/3] rebase -i: remember the settings of -v, -s and -p when interrupted
From: Johannes Schindelin @ 2007-07-08 2:02 UTC (permalink / raw)
To: git, gitster
After interruption, be that an edit, or a conflicting commit, reset
the variables VERBOSE, STRATEGY and PRESERVE_MERGES, so that the
user does not have to respecify them with "rebase --continue".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 4 ++++
t/t3404-rebase-interactive.sh | 10 ++++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 84148a9..a9bb622 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -23,6 +23,9 @@ REWRITTEN="$DOTEST"/rewritten
PRESERVE_MERGES=
STRATEGY=
VERBOSE=
+test -d "$REWRITTEN" && PRESERVE_MERGES=t
+test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
+test -f "$DOTEST"/verbose && VERBOSE=t
warn () {
echo "$*" >&2
@@ -365,6 +368,7 @@ do
echo $HEAD > "$DOTEST"/head
echo $UPSTREAM > "$DOTEST"/upstream
echo $ONTO > "$DOTEST"/onto
+ test -z "$STRATEGY" || echo "$STRATEGY" > "$DOTEST"/strategy
test t = "$VERBOSE" && : > "$DOTEST"/verbose
if [ t = "$PRESERVE_MERGES" ]
then
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index c251336..43a6675 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -202,4 +202,14 @@ test_expect_success '--continue tries to commit' '
git show HEAD | grep chouette
'
+test_expect_success 'verbose flag is heeded, even after --continue' '
+ git reset --hard HEAD@{1} &&
+ test_tick &&
+ ! git rebase -v -i --onto new-branch1 HEAD^ &&
+ echo resolved > file1 &&
+ git add file1 &&
+ git rebase --continue > output &&
+ grep "^ file1 | 2 +-$" output
+'
+
test_done
--
1.5.3.rc0.2712.g125b7f
^ permalink raw reply related
* Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Johannes Schindelin @ 2007-07-08 2:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707080248320.4093@racer.site>
Hi,
On Sun, 8 Jul 2007, Johannes Schindelin wrote:
> On Sat, 7 Jul 2007, Junio C Hamano wrote:
>
> > IOW, don't make unpack-trees to make policy decisions on final
> > resolution, unless it is operating under aggressive rule (where the
> > caller explicitly allows it to make more than the "trivial"
> > decisions). The caller (in this case, merge-recursive) should see A
> > at stage #2 with A/B at stages #1 and #3 and decide what to do.
>
> Okay, so you're saying that merge-recursive should use the aggressive
> strategy?
To refine on that: from my (limited, I admit) understanding of the code,
by the time it hits that "if (o->aggressive)", in case of a df conflict,
the chance has long whizzed by to decide anything useful, since either
head or remote were set to NULL. So they are no longer what they would
have to be in order to make any sense.
Well, I try to cobble up a patch for merge-recursive like you suggested,
and stay away from threeway_merge() as far as I can, for the rest of my
life.
However, it feels somehow wrong that I have to check all the files in the
unmerged index, when unpack_trees could have easily seen that the tree did
not change between all (in that case, just one) ancestors and the remote,
but that head has changed that path to a file, and head agrees with index
on that, and remote can stay where it is with its darned directory.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn failed on apr
From: Eric Wong @ 2007-07-08 3:35 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Git Mailing List
In-Reply-To: <4b3406f0707030205g3521cff5p1d5150b6a81af51b@mail.gmail.com>
Dongsheng Song <dongsheng.song@gmail.com> wrote:
> [ ~/wc/git-svn]$ mkdir apr
> [ ~/wc/git-svn]$ cd apr/
> [ ~/wc/git-svn/apr]$ ls
> [ ~/wc/git-svn/apr]$ git-svn init -T trunk -b branches -t tags
> http://svn.apache.org/repos/asf/apr/apr
> Initialized empty Git repository in .git/
> Using higher level of URL: http://svn.apache.org/repos/asf/apr/apr =>
> http://svn.apache.org/repos/asf
> [ ~/wc/git-svn/apr]$ git-svn fetch
> W: Ignoring error from SVN, path probably does not exist: (175002): RA
> layer request failed: REPORT request failed on
> '/repos/asf/!svn/bc/2200': REPORT of '/repos/asf/!svn/bc/2200': 200 OK
> (http://svn.apache.org)
>
> What's wrong?
Nothing.
The "W:" there means it's just a warning. git-svn looks into the
beginning of history in an attempt to fetch all history, and if
the directory you're tracking doesn't exist, it'll spit out that
warning message once (it used to spit it out a lot more).
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Johannes Schindelin @ 2007-07-08 4:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707080311280.4093@racer.site>
Hi,
On Sun, 8 Jul 2007, Johannes Schindelin wrote:
> Well, I try to cobble up a patch for merge-recursive like you suggested,
> and stay away from threeway_merge() as far as I can, for the rest of my
> life.
Here is a WIP. Note: it only does half of the job. For performance
reasons, we do not write out the working tree changes for intermediate
merges. However, in the last step, we do. And this patch does not reflect
that, but only updates the index.
Ciao,
Dscho
merge-recursive.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index dbd06aa..99da2bb 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -243,6 +243,92 @@ static int git_merge_trees(int index_only,
return rc;
}
+/*
+ * If there were dir/file conflicts, which are not really dir/file
+ * conflicts, because only one side changed anything, take that
+ * side instead of outputting silly conflicts.
+ *
+ * NOTE! unpack_trees() would have a much better chance at resolving
+ * these conflicts, since it gets the _tree_ objects we have to
+ * reconstruct tediously, and it could get away with one simple
+ * comparison between sha1's, while that is not possible here.
+ */
+static inline int is_df(struct cache_entry *in_dir, struct cache_entry *file)
+{
+ int len = ce_namelen(file);
+ const char *name = in_dir->name;
+ return !memcmp(name, file->name, len) && name[len] == '/';
+}
+
+static int try_to_fix_up_df_conflicts_which_are_none(const unsigned char *base,
+ const unsigned char *head, const unsigned char *merge)
+{
+ int i;
+ for (i = 0; i + 2 < active_nr; i++) {
+ int last;
+ unsigned char sha1[20], sha2[20];
+ unsigned dummy;
+ char *name;
+ struct cache_entry *ce = active_cache[i], *ce1, *ce2;
+
+ if (ce_stage(ce) == 0)
+ continue;
+ ce1 = active_cache[i + 1];
+ ce2 = active_cache[i + 2];
+ if (ce_same_name(ce, ce2) || !is_df(ce2, ce)) {
+ /* not a d/f conflict */
+ i += 2;
+ continue;
+ }
+ for (last = i + 3; last < active_nr &&
+ is_df(active_cache[last], ce); last++)
+ ; /* do nothing */
+ /* check if HEAD as an unchanged file, remote a dir */
+ if (ce_same_name(ce, ce1)) {
+ if (ce_stage(ce) != 1 ||
+ hashcmp(ce->sha1, ce1->sha1)) {
+ /* file was changed */
+ i = last - 1;
+ continue;
+ }
+ /* other side removed file, added dir */
+ if (!remove_file_from_cache(ce->name))
+ return error("index error");
+ for (i -= 2, last -= 2; i < last; i++)
+ active_cache[i]->ce_flags &=
+ ~ntohs(CE_STAGEMASK);
+ i--;
+ continue;
+ }
+ if (i + 1 == last)
+ continue;
+ /* check if HEAD changed dir to a file */
+ if (ce_stage(ce) == 1) {
+ i = last - 1;
+ continue;
+ }
+ name = xstrndup(ce->name, ce_namelen(ce));
+ if (get_tree_entry(base, name, sha1, &dummy) ||
+ get_tree_entry(ce_stage(ce) == 2 ?
+ merge : head,
+ name, sha2, &dummy)) {
+ free(name);
+ i = last - 1;
+ continue;
+ }
+ free(name);
+ if (!hashcmp(sha1, sha2)) {
+ /* remove tree */
+ memmove(active_cache + i + 1, active_cache + last,
+ (active_nr - last) *
+ sizeof(struct cache_entry *));
+ active_nr -= last - i - 1;
+ ce->ce_flags &= ~ntohs(CE_STAGEMASK);
+ }
+ }
+ return 0;
+}
+
static int unmerged_index(void)
{
int i;
@@ -1520,6 +1606,8 @@ static int merge_trees(struct tree *head,
sha1_to_hex(head->object.sha1),
sha1_to_hex(merge->object.sha1));
+ try_to_fix_up_df_conflicts_which_are_none(common->object.sha1,
+ head->object.sha1, merge->object.sha1);
if (unmerged_index()) {
struct path_list *entries, *re_head, *re_merge;
int i;
^ permalink raw reply related
* Re: [PATCH 1/3] rebase -i: handle --continue more like non-interactive rebase
From: Johannes Schindelin @ 2007-07-08 4:40 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707080300440.4093@racer.site>
Hi,
On Sun, 8 Jul 2007, Johannes Schindelin wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 0c2a969..67f2ee2 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
>
> [...]
>
> @@ -265,6 +264,14 @@ do
>
> test -d "$DOTEST" || die "No interactive rebase running"
>
> + # commit if necessary
> + git rev-parse --verify HEAD > /dev/null &&
> + git update-index --refresh &&
> + git diff-files --quiet &&
> + ! git diff-index --cached --quiet HEAD &&
> + . "$DOTEST"/author-script &&
> + git commit -F "$DOTEST"/message -e
> +
Oh well. For this to work, there has to be a line
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
before the "git commit" line, I think.
Ciao,
Dscho
^ permalink raw reply
* Re: git cvsimport branches not consistent with CVS branches
From: Brian Downing @ 2007-07-08 5:45 UTC (permalink / raw)
To: Gordon Heydon; +Cc: git
In-Reply-To: <46903396.1010507@heydon.com.au>
On Sun, Jul 08, 2007 at 10:45:10AM +1000, Gordon Heydon wrote:
> After some investigation I found that git cvsimport was not importing
> branches 100% correctly with CVS.
>
> Git and CVS do branching very differently in that CVS this is done at
> the file level (like everything else) and git does it repository wide.
>
> So if I have a CVS repository with the files a, b and c and I branch b
> with a `cvs tab -b BRANCH test` on the branch test I will just have the
> file b.
>
> If I do a git cvsimport on the test branch there will actually be the
> files a, b and c
>
> What I think needs to happen is that when git cvsimport created the
> branch in the git repository it needs to delete all files from the
> branch that were not branched.
I've been vaguely working on Yet Another CVS Importer (an incremental
one; both git-cvsimport (thanks to cvsps) and tailor take about ten
minutes and a gigabyte of RAM to figure out that nothing has to happen
with my repository. I think I can do better than that).
In thinking about this case, I think I've decided that you want an
option on what to do here. For some repositories you're not going to
care about having extra files with the tag, and would greatly prefer
that to having to create a branch for each and every tag (assuming you
can arrange to have the correct files present otherwise; this isn't
always possible.)
For other cases, you really only want to get the subset of the files
that are tagged. For this, I think the best arrangement would be to
make your branch, then make a commit that only deletes the files that
are not present in the CVS branch, as you said. Then immediately make
an empty commit to the mainline (wherever you branched from) merging
from the deletion commit. Then proceed to commit normally to the
branch. This way, if a user chooses to merge from the branch in Git,
it won't try to delete a bunch of files in the target branch. (I'm
having a hard time coming up with a situation where you'd want that
behavior assuming the missing files were never tagged in CVS. A sane
usage pattern would be to tag the whole repository then "cvs rm" the
files you don't want otherwise...)
A fun third case is when a file in CVS doesn't have a branch tag,
but then you go and "cvs add" a file with the same name in a branch.
What CVS does then is to place the branch tag off the current HEAD.
I /think/ you can detect this situation by noticing that the date of
the HEAD revision and the date of the "file was created on branch ..."
revision are exactly the same. You really need to detect this case,
because when this happens there is no real parent relationship between
the branch and the branch point. Since CVS has that "wait for a second
to tick" delay at the end this might even be safe. Sigh.
Don't get me started about the abomination that is vendor branches.
I /hate/ CVS.
-bcd
^ permalink raw reply
* Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Junio C Hamano @ 2007-07-08 5:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <Pine.LNX.4.64.0707080248320.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> IOW, don't make unpack-trees to make policy decisions on final
>> resolution, unless it is operating under aggressive rule (where the
>> caller explicitly allows it to make more than the "trivial" decisions).
>> The caller (in this case, merge-recursive) should see A at stage #2 with
>> A/B at stages #1 and #3 and decide what to do.
>
> Okay, so you're saying that merge-recursive should use the aggressive
> strategy?
I do not think so. Isn't the whole "see if there are renames" thing
depend on threeway_merge() not resolving "one side removes other
side leaves intact" case itself? Aggressive resolves it saying
"Ok that is a remove", which risks it to miss the case in which
that the side that apparently "removed" the path in fact moved
it somewhere else.
The last time I looked at merge-recursive's D/F check, I found
that it was not quite doing things right. I may be able to dig
up what I posted to the list...
^ permalink raw reply
* Re: [PATCH 3/3] rebase -i: remember the settings of -v, -s and -p when interrupted
From: Junio C Hamano @ 2007-07-08 5:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707080302370.4093@racer.site>
All three makes sense. Thanks.
^ permalink raw reply
* Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Junio C Hamano @ 2007-07-08 6:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <7v644v5tr3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> Okay, so you're saying that merge-recursive should use the aggressive
>> strategy?
>
> I do not think so. Isn't the whole "see if there are renames" thing
> depend on threeway_merge() not resolving "one side removes other
> side leaves intact" case itself? Aggressive resolves it saying
> "Ok that is a remove", which risks it to miss the case in which
> that the side that apparently "removed" the path in fact moved
> it somewhere else.
>
> The last time I looked at merge-recursive's D/F check, I found
> that it was not quite doing things right. I may be able to dig
> up what I posted to the list...
It was from around April 7th-10th this year.
http://thread.gmane.org/gmane.comp.version-control.git/43970/focus=44158
http://thread.gmane.org/gmane.comp.version-control.git/43971/focus=43997
I think the case described in the latter message is almost the
opposite case of what your patch tries to deal with.
In the web interface of
http://news.gmane.org/gmane.comp.version-control.git
the patch series that led to my complaints are at around page 76
for me.
^ permalink raw reply
* Re: [PATCH] Per-path attribute based hunk header selection.
From: Junio C Hamano @ 2007-07-08 7:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ,
Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707071317060.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > + if (!strcmp(ident, "tex"))
>> > + return "^\\\\\\(sub\\)*section{";
>
> It is always easier, and will never require C skills, to put this into the
> config. With Junio's current version:
>
> echo '*.tex funcname=tex' >> .gitattributes
> echo '[funcname] tex = ^\(\\\(sub\)*section{.*\)' >> .git/config
>
> The problem is of course that the backslashes have to be escaped _both_ in
> C and in regexps.
I think giving a reasonable set of basic language support as
built-in patterns is important for usability. Otherwise the
users end up needing to have them in their $HOME/.gitconfig.
I am not sure if Java and LaTeX qualify as the first two most
important cases, but they are what we already have
demonstrated. How about doing something like this?
-- >8 --
diff.c: make built-in hunk header pattern a separate table
This would hopefully make it easier to maintain. Initially we
would have "java" and "tex" defined, as they are the only ones
we already have.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/diff.c b/diff.c
index b8473f5..cd6b0c4 100644
--- a/diff.c
+++ b/diff.c
@@ -1216,9 +1216,22 @@ static const char *funcname_pattern(const char *ident)
return NULL;
}
+static struct builtin_funcname_pattern {
+ const char *name;
+ const char *pattern;
+} builtin_funcname_pattern[] = {
+ { "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
+ "new\\|return\\|switch\\|throw\\|while\\)\n"
+ "^[ ]*\\(\\([ ]*"
+ "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
+ "[ ]*([^;]*$\\)" },
+ { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+};
+
static const char *diff_funcname_pattern(struct diff_filespec *one)
{
const char *ident, *pattern;
+ int i;
diff_filespec_check_attr(one);
ident = one->funcname_pattern_ident;
@@ -1240,12 +1253,9 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
* And define built-in fallback patterns here. Note that
* these can be overriden by the user's config settings.
*/
- if (!strcmp(ident, "java"))
- return "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
- "new\\|return\\|switch\\|throw\\|while\\)\n"
- "^[ ]*\\(\\([ ]*"
- "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
- "[ ]*([^;]*$\\)";
+ for (i = 0; i < ARRAY_SIZE(builtin_funcname_pattern); i++)
+ if (!strcmp(ident, builtin_funcname_pattern[i].name))
+ return builtin_funcname_pattern[i].pattern;
return NULL;
}
^ permalink raw reply related
* Re: Possible BUG in 'git log --parents'
From: Junio C Hamano @ 2007-07-08 7:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550707071517o776db380v9f3a68c3e46d9d3c@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 7/7/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> On 7/7/07, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>
>> > git-log. However, I have a slight suspicion that we earlier
>> > decided not to do so on purpose with git-log and for a good
>> > reason. I do not have much energy left tonight to dig into this
>> > right now, but mailing list log and commit log messages for
>> > rev-list.c, builtin-log.c and builtin-rev-list.c might tell you
>> > more.
>> >
>>
>> I will take a look ...
>>
>
> The commit with the patch for git-rev-list is 884944239f2
That's correct. And I do not think of a reason for log and
rev-list to behave differently in this case now, so let's change
the behaviour of log.
There still is one thing I am a bit worried about, though. You
can get the list of true, immediate parents in the raw format
("parent" lines) while getting the list of simplified parents on
the commit line (the topic of this thread). Aren't there cases
where Porcelains would want to match up which immediate parent
lead to which simplified parent? Using the illustration from
the commit log mesage of 88494423:
.---A---.
/ \
.---*---B---.
/ 93b74bc \
---*---o---o-----o---C-----o addafaf
d8f6b34 \ /
.---o---D---.
\ /
.---E---.
3815f42
If we always show the five simplified parents as the response to
the --parent request, you would get:
commit addafaf... d8f6b34... 93b74bc... d8f6b34... d8f6b34... 3815f42...
tree e3be15f54f01e3aa1f8ec830ac87da5f85a23480
parent 6b94f1e404afc552e5139c4357331843f5be61ad
parent 93b74bca86f59b8df410b6fd4803b88ee0f304bf
parent ea726d02e9677a66586d7ffebe97f112ab6dab33
parent b33aba518456bee97bde1fef4fe17ab6bf401bbe
parent 6b1ddbdd6e02719ae2be55dc141a176187e5027e
and you can tell 6b94f1e4 (the first immediate parent)
corresponds to d8f6b34, the first simplified parent, while
93b74bc (the second immediate parent) corresponds to 93b74bc
(the second simplified parent). If we do the duplicate
omission, as we do for rev-list (and not for log as you found
out), you would not be able to tell which branch you can find by
reading the immediate parent list corresponds to what simplified
parent you can find from the --parent output.
But this worry applies to both rev-list and log, and it is no
reason to leave their behaviours different.
-- >8 --
Match "log --parent" output to "rev-list --parent" output.
We updated "rev-list --parent" output to omit duplicated parents
from the output long time ago, but this change was not side-ported
to "git-log". There is no reason to leave them inconsistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/log-tree.c b/log-tree.c
index 8624d5a..24aea6b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -6,13 +6,32 @@
struct decoration name_decoration = { "object names" };
+static void clear_tmp_mark(struct commit_list *p)
+{
+ while (p) {
+ struct commit *c = p->item;
+ c->object.flags &= ~TMP_MARK;
+ p = p->next;
+ }
+}
+
static void show_parents(struct commit *commit, int abbrev)
{
struct commit_list *p;
+
+ /* TMP_MARK is a general purpose flag that can
+ * be used locally, but the user should clean
+ * things up after it is done with them.
+ */
+ clear_tmp_mark(commit->parents);
for (p = commit->parents; p ; p = p->next) {
struct commit *parent = p->item;
+ if (parent->object.flags & TMP_MARK)
+ continue;
printf(" %s", diff_unique_abbrev(parent->object.sha1, abbrev));
+ parent->object.flags |= TMP_MARK;
}
+ clear_tmp_mark(commit->parents);
}
static void show_decorations(struct commit *commit)
^ permalink raw reply related
* Re: [RFC/PATCH] git-branch: default to --track
From: Junio C Hamano @ 2007-07-08 8:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Paolo Bonzini
In-Reply-To: <Pine.LNX.4.64.0707062252390.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> "git branch --track" will setup config variables when branching from
> a remote branch, so that if you say "git pull" while being on that
> branch, it automatically fetches the correct remote, and merges the
> correct branch.
While I think it would have been the right thing to do if the
code did this only for a remote branch, I think there is a bug
somewhere. I just saw this:
... some random changes ...
master$ git commit -a -s -m 'Some work meant for topic.'
master$ git branch jc/new-topic
Branch jc/new-topic set up to track local branch refs/heads/master
Eh? I did not want this to get applied for my local branches.
The intention of the above command sequence was to do a branch
and then "reset --hard HEAD^" to rewind the 'master', as if I
did not commit but instead did "checkout -b jc/new-topic &&
commit && checkout master".
But "checkout -b jc/newtopic" has the same problem, as it
eventually uses the same "git-branch" that defaults to --track
even for a case where I branch off of a local branch.
I do not necessarily think the command line --track is broken.
If the user explicitly says a branch tracks a local branch, so
be it. If --track comes from autosetupmerge or built-in default
like your patch, however, I do not think it makes much sense to
pollute the config file with useless "tracking" information.
I am very tempted to revert this, but won't do so tonight, yet.
^ permalink raw reply
* Re: [PATCH] Fix "apply --reverse" with regard to whitespace
From: Junio C Hamano @ 2007-07-08 9:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, gitster
In-Reply-To: <Pine.LNX.4.64.0707071849430.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> "git apply" used to take check the whitespace in the wrong
> direction.
>
> Noticed by Daniel Barkalow.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Fri, 6 Jul 2007, Daniel Barkalow wrote:
>
> > If you apply in reverse a patch which adds junk (e.g., terminal
> > whitespace), it complains about the junk you're adding, even
> > though (since it's in reverse) you're actually removing that
> > junk.
>
> This fixes it.
Hmm. Does this cover the "trailing blank lines removal" as
well?
^ permalink raw reply
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Junio C Hamano @ 2007-07-08 9:06 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <7vir8w6inf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> This however will break people's existing gitweb configuration,
> so if we were to do this it should be post 1.5.3, I would say.
We have swallowed some changes that breaks details of user
experience so far, and compared to one of them, the
incompatibility this brings in is much more benign. We haven't
declared -rc1 when the command set and features for the next
release is cast in stone.
I am tempted to change my mind and am inclined to apply this.
^ permalink raw reply
* Re: Possible BUG in 'git log --parents'
From: Marco Costalba @ 2007-07-08 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vodin2unr.fsf@assigned-by-dhcp.cox.net>
On 7/8/07, Junio C Hamano <gitster@pobox.com> wrote:
> Match "log --parent" output to "rev-list --parent" output.
>
Thanks. It works for me.
^ permalink raw reply
* Re: Possible BUG in 'git log --parents'
From: Marco Costalba @ 2007-07-08 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <e5bfff550707080232q3e27581t45c0e4c5a1ea3b0f@mail.gmail.com>
On 7/8/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/8/07, Junio C Hamano <gitster@pobox.com> wrote:
> > Match "log --parent" output to "rev-list --parent" output.
> >
>
> Thanks. It works for me.
>
Sorry, I have to correct, it does *not* work for me.
Please apply your patch and give a look at:
git log --parents -n1 addafaf92e -r -m -- diff.h
What seems to happen is that duplicated entries are not removed by
diff machinery.
Although duplicated parents are correctly removed from parent list as
in git-rev-list, probably we should consider that git-log has also the
diff machinery attached.
Marco
P.S: Hope this little issue does not make you revert the patch ;-)
^ permalink raw reply
* Re: git cvsimport branches not consistent with CVS branches
From: Robin Rosenberg @ 2007-07-08 10:53 UTC (permalink / raw)
To: Brian Downing; +Cc: Gordon Heydon, git
In-Reply-To: <20070708054520.GD4087@lavos.net>
söndag 08 juli 2007 skrev Brian Downing:
> On Sun, Jul 08, 2007 at 10:45:10AM +1000, Gordon Heydon wrote:
> > After some investigation I found that git cvsimport was not importing
> > branches 100% correctly with CVS.
> >
> > Git and CVS do branching very differently in that CVS this is done at
> > the file level (like everything else) and git does it repository wide.
> >
> > So if I have a CVS repository with the files a, b and c and I branch b
> > with a `cvs tab -b BRANCH test` on the branch test I will just have the
> > file b.
> >
> > If I do a git cvsimport on the test branch there will actually be the
> > files a, b and c
> >
> > What I think needs to happen is that when git cvsimport created the
> > branch in the git repository it needs to delete all files from the
> > branch that were not branched.
>
> I've been vaguely working on Yet Another CVS Importer (an incremental
> one; both git-cvsimport (thanks to cvsps) and tailor take about ten
> minutes and a gigabyte of RAM to figure out that nothing has to happen
> with my repository. I think I can do better than that).
Corecode's fromcvs is pretty fast and incremental and AFAIK accurate. I had
plenty problems with cvsimport, but fromcvs keeps in sync with the CVS repo.
Get it at http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/ .
It does not convert regular tags, only branches, however so there is something to
do for those that want a complete cvs import.
> In thinking about this case, I think I've decided that you want an
> option on what to do here. For some repositories you're not going to
> care about having extra files with the tag, and would greatly prefer
> that to having to create a branch for each and every tag (assuming you
> can arrange to have the correct files present otherwise; this isn't
> always possible.)
>
> For other cases, you really only want to get the subset of the files
> that are tagged. For this, I think the best arrangement would be to
> make your branch, then make a commit that only deletes the files that
> are not present in the CVS branch, as you said. Then immediately make
fromcvs drops the files that do not have the branch tag. It is pretty simple to change
the behaviour ( http://rosenberg.homelinux.net/gitweb/gitweb.cgi?p=FROMCVS.git;a=commitdiff;h=eb1c159bcc0d79eab182da3d7040ac62b52fd297 )
although this should be a switch and not hard coded.
-- robin
^ permalink raw reply
* [PATCH v3] revision: allow selection of commits that do not match a pattern
From: Sven Verdoolaege @ 2007-07-08 10:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707071957370.4093@racer.site>
We do this by maintaining two lists of patterns, one for
those that should match and one for those that should not match.
A negative pattern is specified by putting a '!' in front.
For example, to show the commits of Jakub Narebski that
are not about gitweb, you'd do a
git log --author='Narebski' --grep='!gitweb' --all-match
As an added bonus, this patch also documents --all-match.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
Documentation/git-rev-list.txt | 17 ++++++++++
revision.c | 64 +++++++++++++++++++++++++++++++++------
revision.h | 1 +
3 files changed, 72 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 20dcac6..c462f5d 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -214,11 +214,19 @@ limiting may be applied.
Limit the commits output to ones with author/committer
header lines that match the specified pattern (regular expression).
+ A pattern starting with a '!' will show only commits that do
+ not match the remainder of the pattern.
+ To match lines starting with '!', escape the initial '!'
+ with a backslash.
--grep='pattern'::
Limit the commits output to ones with log message that
matches the specified pattern (regular expression).
+ A pattern starting with a '!' will show only commits that do
+ not match the remainder of the pattern.
+ To match lines starting with '!', escape the initial '!'
+ with a backslash.
--regexp-ignore-case::
@@ -229,6 +237,15 @@ limiting may be applied.
Consider the limiting patterns to be extended regular expressions
instead of the default basic regular expressions.
+--all-match::
+
+ Without this option, a commit is shown if any of the
+ (positive or negative) patterns matches, i.e., there
+ is at least one positive match or not all of the negative
+ patterns match. With this options, a commit is only
+ shown if all of the patterns match, i.e., all positive
+ patterns match and no negative pattern matches.
+
--remove-empty::
Stop when a given path disappears from the tree.
diff --git a/revision.c b/revision.c
index 5184716..0035d40 100644
--- a/revision.c
+++ b/revision.c
@@ -821,34 +821,50 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
-static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
+static void add_grep(struct rev_info *revs, const char *ptn,
+ enum grep_pat_token what)
{
- if (!revs->grep_filter) {
+ int negated = 0;
+ struct grep_opt **filter;
+
+ if (ptn[0] == '\\' && ptn[1] == '!')
+ ptn++;
+ if (*ptn == '!') {
+ negated = 1;
+ ptn++;
+ }
+ filter = negated ? &revs->grep_neg_filter : &revs->grep_filter;
+ if (!*filter) {
struct grep_opt *opt = xcalloc(1, sizeof(*opt));
opt->status_only = 1;
opt->pattern_tail = &(opt->pattern_list);
opt->regflags = REG_NEWLINE;
- revs->grep_filter = opt;
+ *filter = opt;
}
- append_grep_pattern(revs->grep_filter, ptn,
- "command line", 0, what);
+ append_grep_pattern(*filter, ptn, "command line", 0, what);
}
-static void add_header_grep(struct rev_info *revs, const char *field, const char *pattern)
+static void add_header_grep(struct rev_info *revs, const char *field,
+ const char *pattern)
{
char *pat;
- const char *prefix;
+ const char *prefix, *negated;
int patlen, fldlen;
fldlen = strlen(field);
patlen = strlen(pattern);
pat = xmalloc(patlen + fldlen + 10);
+ negated = "";
+ if (*pattern == '!') {
+ negated = "!";
+ pattern++;
+ }
prefix = ".*";
if (*pattern == '^') {
prefix = "";
pattern++;
}
- sprintf(pat, "^%s %s%s", field, prefix, pattern);
+ sprintf(pat, "%s^%s %s%s", negated, field, prefix, pattern);
add_grep(revs, pat, GREP_PATTERN_HEAD);
}
@@ -1212,6 +1228,9 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (revs->grep_filter)
revs->grep_filter->regflags |= regflags;
+ if (revs->grep_neg_filter)
+ revs->grep_neg_filter->regflags |= regflags;
+
if (show_merge)
prepare_show_merge(revs);
if (def && !revs->pending.nr) {
@@ -1249,6 +1268,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
compile_grep_patterns(revs->grep_filter);
}
+ if (revs->grep_neg_filter) {
+ revs->grep_neg_filter->all_match = !all_match;
+ compile_grep_patterns(revs->grep_neg_filter);
+ }
+
return left;
}
@@ -1327,11 +1351,31 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
return 0;
}
+/*
+ * If all_match is set, then a commit matches if all the positive
+ * patterns match and not one of the negative patterns matches.
+ * If all_match is not set, then a commit matches if at least one
+ * of the positive patterns matches or not all of the negative
+ * patterns match.
+ */
static int commit_match(struct commit *commit, struct rev_info *opt)
{
- if (!opt->grep_filter)
+ int pos_match, all_match;
+
+ pos_match = !opt->grep_filter ||
+ grep_buffer(opt->grep_filter,
+ NULL, /* we say nothing, not even filename */
+ commit->buffer, strlen(commit->buffer));
+ if (!opt->grep_neg_filter)
+ return pos_match;
+
+ all_match = !opt->grep_neg_filter->all_match;
+ if (!all_match && opt->grep_filter && pos_match)
return 1;
- return grep_buffer(opt->grep_filter,
+ if (all_match && !pos_match)
+ return 0;
+
+ return !grep_buffer(opt->grep_neg_filter,
NULL, /* we say nothing, not even filename */
commit->buffer, strlen(commit->buffer));
}
diff --git a/revision.h b/revision.h
index f46b4d5..9728d4c 100644
--- a/revision.h
+++ b/revision.h
@@ -84,6 +84,7 @@ struct rev_info {
/* Filter by commit log message */
struct grep_opt *grep_filter;
+ struct grep_opt *grep_neg_filter;
/* special limits */
int skip_count;
--
1.5.3.rc0.65.ge75d-dirty
^ permalink raw reply related
* Re: git cvsimport branches not consistent with CVS branches
From: Johannes Schindelin @ 2007-07-08 11:47 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Brian Downing, Gordon Heydon, git
In-Reply-To: <200707081253.06129.robin.rosenberg.lists@dewire.com>
Hi,
On Sun, 8 Jul 2007, Robin Rosenberg wrote:
> Corecode's fromcvs is pretty fast and incremental and AFAIK accurate.
The only problem is that it is a misnomer: it is not fromcvs, but fromrcs,
since you have to have access at the _files_. This is not always
possible.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Per-path attribute based hunk header selection.
From: Johannes Schindelin @ 2007-07-08 11:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Linus Torvalds, git
In-Reply-To: <7v1wfj4auu.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 8 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > + if (!strcmp(ident, "tex"))
> >> > + return "^\\\\\\(sub\\)*section{";
> >
> > It is always easier, and will never require C skills, to put this into the
> > config. With Junio's current version:
> >
> > echo '*.tex funcname=tex' >> .gitattributes
> > echo '[funcname] tex = ^\(\\\(sub\)*section{.*\)' >> .git/config
> >
> > The problem is of course that the backslashes have to be escaped _both_ in
> > C and in regexps.
>
> I think giving a reasonable set of basic language support as
> built-in patterns is important for usability. Otherwise the
> users end up needing to have them in their $HOME/.gitconfig.
I agree.
> I am not sure if Java and LaTeX qualify as the first two most important
> cases, but they are what we already have demonstrated.
Java and LaTeX are the two languages I use, for which the inbuilt funcname
default is absolutely unusable. Given that Java is the only language with
a notable git-related code base, for which the default fails, Java is the
prime (if not the only) reason I wanted this whole patch series in the
first place.
> How about doing something like this?
I do not see how a table in diff.c could be easier to maintain than a
small part in a small function in diff.c. It would make sense, though, to
move the table to xdiff-interface.[ch].
Ciao,
Dscho
^ permalink raw reply
* Re: git cvsimport branches not consistent with CVS branches
From: Robin Rosenberg @ 2007-07-08 12:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Downing, Gordon Heydon, git
In-Reply-To: <Pine.LNX.4.64.0707081246040.4248@racer.site>
söndag 08 juli 2007 skrev Johannes Schindelin:
> Hi,
>
> On Sun, 8 Jul 2007, Robin Rosenberg wrote:
>
> > Corecode's fromcvs is pretty fast and incremental and AFAIK accurate.
>
> The only problem is that it is a misnomer: it is not fromcvs, but fromrcs,
> since you have to have access at the _files_. This is not always
> possible.
A small problem considering that fromcvs works and the other don't. My guess
is that fromcvs kan be "fixed" to do remote access much more easily than cvsimport
can be "fixed" to import an archive properly.
-- robin
^ permalink raw reply
* [PATCH] branch.autosetupmerge: allow boolean values, or "all"
From: Johannes Schindelin @ 2007-07-08 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Paolo Bonzini
In-Reply-To: <7vhcof2rur.fsf@assigned-by-dhcp.cox.net>
Junio noticed that switching on autosetupmerge unilaterally started
cluttering the config for local branches. That is not the original
intention of branch.autosetupmerge, which was meant purely for
convenience when branching off of remote branches, but that semantics
got lost somewhere.
If you still want that "new" behavior, you can switch
branch.autosetupmerge to the value "all". Otherwise, it is interpreted
as a boolean, which triggers setting up defaults _only_ when branching
off of a remote branch, i.e. the originally intended behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sun, 8 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > "git branch --track" will setup config variables when
> > branching from a remote branch, so that if you say "git pull"
> > while being on that branch, it automatically fetches the
> > correct remote, and merges the correct branch.
>
> While I think it would have been the right thing to do if the
> code did this only for a remote branch, I think there is a bug
> somewhere. I just saw this:
>
> ... some random changes ...
> master$ git commit -a -s -m 'Some work meant for topic.'
> master$ git branch jc/new-topic
> Branch jc/new-topic set up to track local branch refs/heads/master
>
> Eh? I did not want this to get applied for my local branches.
That is certainly unexpected and unwelcomed. Alas, I think it is
one of the consequences of rarely executed (and thus, tested)
code.
I rarely branch, but use one long running branch to commit and
revert, so that a "git log -S<keyword> -p" brings me back my huge
debug output changes, and therefore I did not catch it.
> I do not necessarily think the command line --track is broken.
Me, neither. Therefore, this patch does not change the semantics
of that one. But it was really unexpected for me to see that this
works with anything but remote branches.
> I am very tempted to revert this, but won't do so tonight, yet.
Well, I marked it as RFC, and was surprised to wake up to it being
applied. But thanks for not reverting right away; I think this
patch should fix the issue.
builtin-branch.c | 18 ++++++++++++------
t/t3200-branch.sh | 9 +++++++++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 507b47c..49195a1 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -22,7 +22,7 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
-static int branch_track_remotes = 1;
+static int branch_track = 1; /* 0 = none, 1 = remotes, 2 = all */
static int branch_use_color;
static char branch_colors[][COLOR_MAXLEN] = {
@@ -66,8 +66,12 @@ static int git_branch_config(const char *var, const char *value)
color_parse(value, var, branch_colors[slot]);
return 0;
}
- if (!strcmp(var, "branch.autosetupmerge"))
- branch_track_remotes = git_config_bool(var, value);
+ if (!strcmp(var, "branch.autosetupmerge")) {
+ if (!strcmp(value, "all"))
+ branch_track = 2;
+ else
+ branch_track = git_config_bool(var, value);
+ }
return git_default_config(var, value);
}
@@ -525,7 +529,9 @@ static void create_branch(const char *name, const char *start_name,
/* When branching off a remote branch, set up so that git-pull
automatically merges from there. So far, this is only done for
remotes registered via .git/config. */
- if (real_ref && track)
+ if (real_ref && (track == 2 ||
+ (track == 1 &&
+ !prefixcmp(real_ref, "refs/remotes/"))))
set_branch_defaults(name, real_ref);
if (write_ref_sha1(lock, sha1, msg) < 0)
@@ -586,7 +592,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int i;
git_config(git_branch_config);
- track = branch_track_remotes;
+ track = branch_track;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -598,7 +604,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
break;
}
if (!strcmp(arg, "--track")) {
- track = 1;
+ track = 2;
continue;
}
if (!strcmp(arg, "--no-track")) {
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index c6f472a..a19e961 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -148,6 +148,15 @@ test_expect_success 'test tracking setup via config' \
test $(git config branch.my3.remote) = local &&
test $(git config branch.my3.merge) = refs/heads/master'
+test_expect_success 'autosetupmerge = all' '
+ git config branch.autosetupmerge true &&
+ git branch all1 master &&
+ test -z "$(git config branch.all1.merge)" &&
+ git config branch.autosetupmerge all &&
+ git branch all2 master &&
+ test $(git config branch.all2.merge) = refs/heads/master
+'
+
test_expect_success 'test overriding tracking setup via --no-track' \
'git config branch.autosetupmerge true &&
git config remote.local.url . &&
--
1.5.3.rc0.2742.g2050
^ 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