* [PATCH 1/4] remote: add a new 'origin' variable to the struct
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This allows one to track where was the remote's original source, so that
it's possible to decide if it makes sense to migrate it to the config
format or not.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
remote.c | 3 +++
remote.h | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index e530a21..cbb3e48 100644
--- a/remote.c
+++ b/remote.c
@@ -201,6 +201,7 @@ static void read_remotes_file(struct remote *remote)
if (!f)
return;
+ remote->origin = REMOTE_REMOTES;
while (fgets(buffer, BUF_SIZE, f)) {
int value_list;
char *s, *p;
@@ -261,6 +262,7 @@ static void read_branches_file(struct remote *remote)
s++;
if (!*s)
return;
+ remote->origin = REMOTE_BRANCHES;
p = s + strlen(s);
while (isspace(p[-1]))
*--p = 0;
@@ -350,6 +352,7 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!subkey)
return error("Config with no key for remote %s", name);
remote = make_remote(name, subkey - name);
+ remote->origin = REMOTE_CONFIG;
if (!strcmp(subkey, ".mirror"))
remote->mirror = git_config_bool(key, value);
else if (!strcmp(subkey, ".skipdefaultupdate"))
diff --git a/remote.h b/remote.h
index d2e170c..a46a5be 100644
--- a/remote.h
+++ b/remote.h
@@ -1,8 +1,15 @@
#ifndef REMOTE_H
#define REMOTE_H
+enum {
+ REMOTE_CONFIG,
+ REMOTE_REMOTES,
+ REMOTE_BRANCHES
+};
+
struct remote {
const char *name;
+ int origin;
const char **url;
int url_nr;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] git-remote: document the migration feature of the rename subcommand
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-remote.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 7b227b3..fad983e 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -66,6 +66,10 @@ was passed.
Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
++
+In case <old> and <new> are the same, and <old> is a file under
+`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+the configuration file format.
'rm'::
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] Implement git remote rename
From: Miklos Vajna @ 2008-11-10 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7v63nh1sc7.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 24, 2008 at 04:33:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> I suspect that if you record where you read the configuration from in
> "struct remote" and add necessary code to remove the original when
> rename.old is *not* coming from in-config definition, you would make
> it possible for repositories initialized with older git that has
> either $GIT_DIR/branches/origin or $GIT_DIR/remotes/origin to be
> migrated to the in-config format using "git remote rename origin
> origin".
Here are 4 patches to implement this + add the related
testcases/documentation.
Miklos Vajna (4):
remote: add a new 'origin' variable to the struct
git-remote rename: support remotes->config migration
git-remote rename: support branches->config migration
git-remote: document the migration feature of the rename subcommand
Documentation/git-remote.txt | 4 ++++
builtin-remote.c | 35 +++++++++++++++++++++++++++++++++++
remote.c | 3 +++
remote.h | 7 +++++++
t/t5505-remote.sh | 33 +++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 3/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This is similar to the remotes->config one, but it makes the
branches->config conversion possible.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 2 ++
t/t5505-remote.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d9d0ba3..3af1876 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -384,6 +384,8 @@ static int migrate_file(struct remote *remote)
remote->fetch_refspec[i], buf.buf);
if (remote->origin == REMOTE_REMOTES)
path = git_path("remotes/%s", remote->name);
+ else if (remote->origin == REMOTE_BRANCHES)
+ path = git_path("branches/%s", remote->name);
if (path && unlink(path))
warning("failed to remove '%s'", path);
return 0;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 1567631..1f59960 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -364,4 +364,16 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
'
+test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' '
+ git clone one six &&
+ origin_url=$(pwd)/one &&
+ (cd six &&
+ git remote rm origin &&
+ echo "$origin_url" > .git/branches/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/branches/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] git-remote rename: support remotes->config migration
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This patch makes it possible to migrate a remote stored in a
$GIT_DIR/remotes/nick file to the configuration file format.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 33 +++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 21 +++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 1ca6cdb..d9d0ba3 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -359,6 +359,36 @@ static int read_remote_branches(const char *refname,
return 0;
}
+static int migrate_file(struct remote *remote)
+{
+ struct strbuf buf = STRBUF_INIT;
+ int i;
+ char *path = NULL;
+
+ strbuf_addf(&buf, "remote.%s.url", remote->name);
+ for (i = 0; i < remote->url_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->url[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->url[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.push", remote->name);
+ for (i = 0; i < remote->push_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->push_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->push_refspec[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", remote->name);
+ for (i = 0; i < remote->fetch_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->fetch_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->fetch_refspec[i], buf.buf);
+ if (remote->origin == REMOTE_REMOTES)
+ path = git_path("remotes/%s", remote->name);
+ if (path && unlink(path))
+ warning("failed to remove '%s'", path);
+ return 0;
+}
+
static int mv(int argc, const char **argv)
{
struct option options[] = {
@@ -381,6 +411,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
+ if (!strcmp(rename.old, rename.new) && oldremote->origin != REMOTE_CONFIG)
+ return migrate_file(oldremote);
+
newremote = remote_get(rename.new);
if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
die("remote %s already exists.", rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0c956ba..1567631 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -343,4 +343,25 @@ test_expect_success 'rename a remote' '
test "$(git config branch.master.remote)" = "upstream")
'
+
+cat > remotes_origin << EOF
+URL: $(pwd)/one
+Push: refs/heads/master:refs/heads/upstream
+Pull: refs/heads/master:refs/heads/origin
+EOF
+
+test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
+ git clone one five &&
+ origin_url=$(pwd)/one &&
+ (cd five &&
+ git remote rm origin &&
+ mkdir -p .git/remotes &&
+ cat ../remotes_origin > .git/remotes/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/remotes/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.push)" = "refs/heads/master:refs/heads/upstream" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Junio C Hamano @ 2008-11-10 20:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Linus Torvalds, Miles Bader, git
In-Reply-To: <alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 9 Nov 2008, Alex Riesen wrote:
>
>> Oh, I am. But it is just so convenient to have range support for
>> commands which just show commits. Besides, git-show just errors out,
>> instead of producing the commits like git-log does.
>
> Have fun implementing the support, and then explaining to users why this
> shows only one commit:
>
> git show HEAD^..HEAD HEAD~10
I find what Alex says somewhat silly because show is always "no walk", and
range by definition means you need to walk.
But when you give that command line, Alex could also change the command to
show the HEAD and HEAD~10, by changing the way series of range parameters
are evaluated by the revision parsing machinery. You take HEAD^..HEAD and
come up with one set (that has only one commit, HEAD), you take the next
parameter HEAD~10 and come up with another set (that also has only one
commit, HEAD~10, because show does not walk), then you take union.
I personally do not want to see that happen, though. The way multiple
"ranges" that come from separate command line parameters combine using set
operator semantics is so useful to do something like...
git log ko/master..master ^maint
which is my way to ask "Which commits on master are the ones that I
haven't pushed out? By the way, I have pushed out maint already so I do
not want to see anything that is already in maint", where ko/master tracks
what I pushed out to the public repository at k.org; this query is used to
see if I can still rewrite commits when I find typo/thinko in them.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Junio C Hamano @ 2008-11-10 20:50 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <200811101522.13558.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> A very nice git feature, without even going as far as merges, is the cherry
> pick feature.
I thought cherry-picking needs to be done in terms of 3-way merge, not
diff piped to patch, for correctness's sake.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Shawn O. Pearce @ 2008-11-10 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Git Mailing List, Robin Rosenberg
In-Reply-To: <7v63mv5mro.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Francis Galiegue <fg@one2team.net> writes:
>
> > A very nice git feature, without even going as far as merges, is the cherry
> > pick feature.
>
> I thought cherry-picking needs to be done in terms of 3-way merge, not
> diff piped to patch, for correctness's sake.
Yea, the 3-way merge cherry-pick is better. But in a pinch you
can (usually) get correct results from a "diff | patch" pipeline.
Of course that doesn't always work, resulting in patches that don't
apply cleanly, or worse, that apply at the wrong place silently.
--
Shawn.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Brian Gernhardt @ 2008-11-10 20:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Francis Galiegue, Michal Nazarewicz, git
In-Reply-To: <200811102132.05472.jnareb@gmail.com>
On Nov 10, 2008, at 3:32 PM, Jakub Narebski wrote:
> Dnia poniedziałek 10. listopada 2008 21:24, Francis Galiegue
> napisał:
>> Le Monday 10 November 2008 21:17:29 Jakub Narebski, vous avez
>> écrit :
>
>>> Well, _some_ command has to be invoked to expand keywords. "git add"
>>> doesn't do that (perhaps it should?), so you need to use checkout.
>>>
>>
>> If "git add" aims to do that, you'd have to be very, VERY careful,
>> not to
>> substitute in the wrong place to start with, not to attempt
>> substitution in
>> binary files...
>>
>> And this would have a sizeable cost, imho. If you really want to do
>> this,
>> isn't there a hook somewhere that can do that for you, instead of
>> modifying
>> git add directly?
>
> If I remember correctly there was idea to add 'pre-add' or 'post-add'
> hook...
Without adding any additional hooks, you could use the post-commit
hook to look for any added/changed files containing $Id$ lines and
force a checkout of them.
Perhaps something as simple as the following in your .git/hooks/post-
commit (untested, caveat emptor, YMMV):
git diff --name-only --diff-filter=AM HEAD^ HEAD | \
while read file; do
rm "$file" && git checkout -- "$file"
end
~~ Brian
^ permalink raw reply
* Re: recognize loose local objects during repack
From: Junio C Hamano @ 2008-11-10 21:03 UTC (permalink / raw)
To: drafnel; +Cc: git, spearce, nico, ae
In-Reply-To: <2390436.1226296705080.JavaMail.teamon@b307.teamon.com>
drafnel@gmail.com writes:
> This was developed on top of the previous repack/pack-objects series.
Thanks. Looked alright from a cursory reading.
By the way, I've been meaning to suggest that we should straighten out the
semantics of "unpacked" vs "incremental".
What the latter means is quite clear. We are creating a new packfile to
bundle loose ones into one, and after the new packfile is installed we can
remove the loose objects.
But what --unpacked means often confuses people, primarily because it is a
performance heuristics that makes certain assumptions on how the objects
are packed.
Namely, "unpacked" is about discovery process of objects to be packed.
Without the option, we enumerate all objects that are reachable from the
commits in the given range, excluding the trees and blobs that should
exist in commits that are excluded (e.g, if you say "--objects A..B", we
exclude trees and blobs referenced by commit A).
With the option, we also omit commits that are packed. What's funny is
that their trees and blobs are omitted, even if they are loose ;-)
This is typically not an issue, because you do not say "pack only this
commit object, without its trees or blobs" when repacking, and because you
must have all the trees and blobs necessary for a commit available when
you pack a commit; for these reasons, the trees and blobs are typically
packed together with the commit. It is not an issue that the rev-list
with --unpacked option does not list loose trees and blobs that belong to
a packed commit for this reason.
You could however arrange so that a commit itself is packed but some of
the tree and blob objects it refers to are loose, in which case these
loose objects may not ever get repacked incrementally.
In an empty directory, try this:
git init &&
echo 0 >file && git add file && git commit -m initial &&
P=$(git rev-list HEAD | git pack-objects pack) &&
mv pack-$P.* .git/objects/pack/ &&
git prune && git count-objects -v
git repack && git count-objects -v
It packs only the commit object (and prunes it), leaving a tree and a blob
loose. The repack won't find anything to pack.
This is not so bad in the sense that it will never corrupt your
repository, but it is confusing. Admittedly, not peeking into a commit
that is packed is a reasonable good heuristics for performance reasons.
Interestingly enough, the object listing machinery do traverse into
parents of packed commits when --unpacked is given. So if you pack a
commit and arrange to keep its parents unpacked, they are subject to the
incremental repacking. In other words, the performance heuristics may not
be buying us very much --- we are traversing the history down to the root
commits regardless.
^ permalink raw reply
* [PATCH] Fixed non-literal format in printf-style calls
From: Daniel Lowe @ 2008-11-10 21:07 UTC (permalink / raw)
To: git; +Cc: Daniel Lowe
In-Reply-To: <3t9bmcAj9kThyafdZ9mPENosknipZInn9Qq9u9oVuN7X7qwiI4GqZg@cipher.nrlssc.navy.mil>
These were found using gcc 4.3.2-1ubuntu11 with the warning:
warning: format not a string literal and no format arguments
Incorporated suggestions from Brandon Casey <casey@nrlssc.navy.mil>.
---
builtin-check-attr.c | 2 +-
builtin-remote.c | 2 +-
bundle.c | 4 ++--
environment.c | 2 +-
fsck.c | 2 +-
grep.c | 6 +++---
hash-object.c | 2 +-
path.c | 4 ++--
refs.c | 2 +-
unpack-trees.c | 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index 4921341..15a04b7 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -97,7 +97,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
else if (stdin_paths && doubledash < argc)
errstr = "Can't specify files with --stdin";
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(check_attr_usage, check_attr_options);
}
diff --git a/builtin-remote.c b/builtin-remote.c
index e396a3a..47deb0a 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -320,7 +320,7 @@ static int add_branch_for_removal(const char *refname,
/* make sure that symrefs are deleted */
if (flags & REF_ISSYMREF)
- return unlink(git_path(refname));
+ return unlink(git_path("%s", refname));
item = string_list_append(refname, branches->branches);
item->util = xmalloc(20);
diff --git a/bundle.c b/bundle.c
index 7d17a1f..daecd8e 100644
--- a/bundle.c
+++ b/bundle.c
@@ -114,7 +114,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
continue;
}
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(e->sha1), e->name);
}
if (revs.pending.nr != p->nr)
@@ -139,7 +139,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
for (i = 0; i < req_nr; i++)
if (!(refs.objects[i].item->flags & SHOWN)) {
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(refs.objects[i].item->sha1),
refs.objects[i].name);
}
diff --git a/environment.c b/environment.c
index bf93a59..bb96ac0 100644
--- a/environment.c
+++ b/environment.c
@@ -118,7 +118,7 @@ const char *get_git_work_tree(void)
work_tree = git_work_tree_cfg;
/* make_absolute_path also normalizes the path */
if (work_tree && !is_absolute_path(work_tree))
- work_tree = xstrdup(make_absolute_path(git_path(work_tree)));
+ work_tree = xstrdup(make_absolute_path(git_path("%s", work_tree)));
} else if (work_tree)
work_tree = xstrdup(make_absolute_path(work_tree));
git_work_tree_initialized = 1;
diff --git a/fsck.c b/fsck.c
index 0cf5f01..97f76c5 100644
--- a/fsck.c
+++ b/fsck.c
@@ -326,7 +326,7 @@ int fsck_error_function(struct object *obj, int type, const char *fmt, ...)
die("this should not happen, your snprintf is broken");
}
- error(sb.buf);
+ error("%s", sb.buf);
strbuf_release(&sb);
return 1;
}
diff --git a/grep.c b/grep.c
index e2c190a..600f69f 100644
--- a/grep.c
+++ b/grep.c
@@ -514,7 +514,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
if (from <= last_shown)
from = last_shown + 1;
if (last_shown && from != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
while (from < lno) {
pcl = &prev[lno-from-1];
show_line(opt, pcl->bol, pcl->eol,
@@ -524,7 +524,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
last_shown = lno-1;
}
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
if (!opt->count)
show_line(opt, bol, eol, name, lno, ':');
last_shown = last_hit = lno;
@@ -535,7 +535,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* we need to show this line.
*/
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
show_line(opt, bol, eol, name, lno, '-');
last_shown = lno;
}
diff --git a/hash-object.c b/hash-object.c
index 20937ff..846e91a 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -110,7 +110,7 @@ int main(int argc, const char **argv)
}
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(hash_object_usage, hash_object_options);
}
diff --git a/path.c b/path.c
index eb24017..a074aea 100644
--- a/path.c
+++ b/path.c
@@ -41,7 +41,7 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
len = vsnprintf(buf, n, fmt, args);
va_end(args);
if (len >= n) {
- snprintf(buf, n, bad_path);
+ strlcpy(buf, bad_path, n);
return buf;
}
return cleanup_path(buf);
@@ -63,7 +63,7 @@ static char *git_vsnpath(char *buf, size_t n, const char *fmt, va_list args)
goto bad;
return cleanup_path(buf);
bad:
- snprintf(buf, n, bad_path);
+ strlcpy(buf, bad_path, n);
return buf;
}
diff --git a/refs.c b/refs.c
index 42bde72..33ced65 100644
--- a/refs.c
+++ b/refs.c
@@ -940,7 +940,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
lock->lk->filename[i] = 0;
path = lock->lk->filename;
} else {
- path = git_path(refname);
+ path = git_path("%s", refname);
}
err = unlink(path);
if (err && errno != ENOENT) {
diff --git a/unpack-trees.c b/unpack-trees.c
index e5749ef..54f301d 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -352,7 +352,7 @@ static int unpack_failed(struct unpack_trees_options *o, const char *message)
discard_index(&o->result);
if (!o->gently) {
if (message)
- return error(message);
+ return error("%s", message);
return -1;
}
return -1;
--
1.6.0.4
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-10 21:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <81b0412b0811101224gcffc958o6dbfcdc45e022874@mail.gmail.com>
Hi,
On Mon, 10 Nov 2008, Alex Riesen wrote:
> 2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > On Sun, 9 Nov 2008, Alex Riesen wrote:
> >>
> >> Oh, I am. But it is just so convenient to have range support for
> >> commands which just show commits. Besides, git-show just errors out,
> >> instead of producing the commits like git-log does.
> >
> > Have fun implementing the support, and then explaining to users why this
> > shows only one commit:
> >
> > git show HEAD^..HEAD HEAD~10
> >
>
> for cs in HEAD^..HEAD HEAD~10; do
> case "$cs"; in
> *..*)
> git format-patch --stdout "$cs"
> ;;
> *)
> git show --pretty=email "$cs"
> ;;
> esac
> done
>
> At least, this is what I have in mind and how I expect it to work.
That is not the way git-show is implemented (it uses setup_revisions() to
check for validity and to parse the arguments), and I cannot think of any
way to make this work without ugly workarounds.
Ciao,
Dscho
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-10 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Linus Torvalds, Miles Bader, git
In-Reply-To: <7vabc75n5q.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 10 Nov 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> Alex could also change the command to show the HEAD and HEAD~10, by
> changing the way series of range parameters are evaluated by the
> revision parsing machinery. You take HEAD^..HEAD and come up with one
> set (that has only one commit, HEAD), you take the next parameter
> HEAD~10 and come up with another set (that also has only one commit,
> HEAD~10, because show does not walk), then you take union.
>
> I personally do not want to see that happen, though. The way multiple
> "ranges" that come from separate command line parameters combine using set
> operator semantics is so useful to do something like...
>
> git log ko/master..master ^maint
>
> which is my way to ask "Which commits on master are the ones that I
> haven't pushed out?
Exactly one of my use cases, since we do not have ko/master,maint..master.
Ciao,
Dscho
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 21:31 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Git Mailing List, Robin Rosenberg,
Johannes Schindelin
In-Reply-To: <20081110205242.GH2932@spearce.org>
Le Monday 10 November 2008 21:52:42 Shawn O. Pearce, vous avez écrit :
> Junio C Hamano <gitster@pobox.com> wrote:
> > Francis Galiegue <fg@one2team.net> writes:
> > > A very nice git feature, without even going as far as merges, is the
> > > cherry pick feature.
> >
> > I thought cherry-picking needs to be done in terms of 3-way merge, not
> > diff piped to patch, for correctness's sake.
>
> Yea, the 3-way merge cherry-pick is better. But in a pinch you
> can (usually) get correct results from a "diff | patch" pipeline.
> Of course that doesn't always work, resulting in patches that don't
> apply cleanly, or worse, that apply at the wrong place silently.
Well, in this case, I'd say it's a case of a bottle being "half full" or "half
empty".
The availability of even a simple diff|patch in jgit, and its being available
in egit, would generally be seen as a "half full" bottle, and would, imho,
GREATLY increase the appeal factor of egit, all the more that you have plenty
of undo/redo ability in Eclipse... And, dare I say it, of git in general as
an SCM to be used in many environments where Eclipse is the de facto IDE.
I know, I may sound irritating, but...
--
fge
^ permalink raw reply
* overly smart rebase - bug or feature?
From: Fedor Sergeev @ 2008-11-10 21:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Roman.Shaposhnick
Folks,
I have recently hit a behavior which might well be a feature,
but it was very surprising (in a bad sense) to me.
I was trying to rebase a branch with changes in some file onto a branch
where this file was recently deleted. I would expect rebase to fail and
suggest me to resolve conflict manually.
However it somehow succeeded managing to find another file to patch instead
of the initial one:
] cat git-rebase-bug.sh
#!/bin/sh
git init
# create three files with the same contents
perl -e ' for ($i=0; $i < 10; $i++) { print "$i\n" } ' >Makefile
cp Makefile Makefile1
cp Makefile Makefile2
git add .
git commit -m"created 3 makefiles"
# delete one file
git rm Makefile
git commit -m"deleted 1 makefile"
# go to another branch, one step back
git checkout -b mod HEAD^
# modify contents of the file deleted in master branch
echo "#10" >>Makefile
git add -u
git commit -m"modified 1 makefile"
# now rebase "mod" on top of "master" not expecting it to succeed
git rebase master mod
]
] mkdir git-bug; cd git-bug
] ../git-rebase-bug.sh
....
First, rewinding head to replay your work on top of it...
Applying: modified 1 makefile
error: Makefile: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
]
Now if I look at the rebase result I see that it chose to patch "Makefile2"
instead of my lovely "Makefile" (why not Makefile1, btw ;) ):
] git log --stat -1 --pretty=oneline
ce0101fc7884bce3eb9724b75d654e7c40abf0fd modified 1 makefile
Makefile2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
]
I has always agreed with the claim that simple but reliable merge
(rebase, whatever) is much better than smartass one smarter than yourself.
And, to be honest, both merge and cherry-pick do not try to play smart:
] git reset --hard mod@{1}
] git checkout master
] git merge mod
CCONFLICT (delete/modify): Makefile deleted in HEAD and modified in mod. Version mod of Makefile left in tree.
Automatic merge failed; fix conflicts and then commit the result.
] git reset --hard
] git cherry-pick mod
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c f782a81' to retain authorship and message.
]
So, why rebase is smarter?
Yeah, and if it matters I tried it on 1.6.0.2 and 1.5.3.8 on Solaris and Linux.
best regards,
Fedor.
PS I had problems reaching this list, thus ccing Junio explicitly.
I'm not on the list, btw..
^ permalink raw reply
* [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-10 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Current git versions ignore everything after # (called <head> in the
following) when pushing. Older versions (before cf818348f1ab57),
interpret #<head> as part of the URL, which make git bail out.
Ignoring the <head> part for push (fetch respects them) is unlogical.
As branches origin from Cogito, it is the best to correct this by
using the behaviour of cg-push:
push HEAD to remote refs/heads/<head>
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
Documentation/urls-remotes.txt | 19 +++++++++++----
remote.c | 11 ++++++++
t/t5516-fetch-push.sh | 50 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 504ae8a..d9e284c 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -68,13 +68,22 @@ This file should have the following format:
------------
`<url>` is required; `#<head>` is optional.
-When you do not provide a refspec on the command line,
-git will use the following refspec, where `<head>` defaults to `master`,
-and `<repository>` is the name of this file
-you provided in the command line.
+
+Depending on the operation, git will use one of the following
+refsprecs, if you don't provide one on the command line.
+`<branch>` is the name of this file in `$GIT_DIR/branches` and
+`<head>` defaults to `master`.
+
+git fetch uses:
+
+------------
+ refs/heads/<head>:refs/heads/<branch>
+------------
+
+git push uses:
------------
- refs/heads/<head>:<repository>
+ HEAD:refs/heads/<head>
------------
diff --git a/remote.c b/remote.c
index e530a21..660b2ce 100644
--- a/remote.c
+++ b/remote.c
@@ -297,6 +297,17 @@ static void read_branches_file(struct remote *remote)
}
add_url_alias(remote, p);
add_fetch_refspec(remote, strbuf_detach(&branch, 0));
+ /*
+ * Cogito compatible push: push current HEAD to remote #branch
+ * (master if missing)
+ */
+ strbuf_init(&branch, 0);
+ strbuf_addstr(&branch, "HEAD");
+ if (frag)
+ strbuf_addf(&branch, ":refs/heads/%s", frag);
+ else
+ strbuf_addstr(&branch, ":refs/heads/master");
+ add_push_refspec(remote, strbuf_detach(&branch, 0));
remote->fetch_tags = 1; /* always auto-follow */
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index a6532cb..4426df9 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -523,4 +523,54 @@ test_expect_success 'allow push to HEAD of non-bare repository (config)' '
! grep "warning.*this may cause confusion" stderr
'
+test_expect_success 'fetch with branches' '
+ mk_empty &&
+ git branch second $the_first_commit &&
+ git checkout second &&
+ echo ".." > testrepo/.git/branches/branch1 &&
+ (cd testrepo &&
+ git fetch branch1 &&
+ r=$(git show-ref -s --verify refs/heads/branch1) &&
+ test "z$r" = "z$the_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'fetch with branches containing #' '
+ mk_empty &&
+ echo "..#second" > testrepo/.git/branches/branch2 &&
+ (cd testrepo &&
+ git fetch branch2 &&
+ r=$(git show-ref -s --verify refs/heads/branch2) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'push with branches' '
+ mk_empty &&
+ git checkout second &&
+ echo "testrepo" > .git/branches/branch1 &&
+ git push branch1 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/master) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ )
+'
+
+test_expect_success 'push with branches containing #' '
+ mk_empty &&
+ echo "testrepo#branch3" > .git/branches/branch2 &&
+ git push branch2 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/branch3) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johan Herland @ 2008-11-10 21:51 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Jeff King, Johannes Schindelin, Thomas Harning
In-Reply-To: <20081110203437.GW24201@genesis.frugalware.org>
On Monday 10 November 2008, Miklos Vajna wrote:
> On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland
<johan@herland.net> wrote:
> > Does it make sense to teach "git rebase" the -x option from "git
> > cherry-pick"? As with "git cherry-pick -x" it only makes sense to use
> > it if your rebasing from a public branch.
>
> But rebasing a public branch is always something we try to prevent. So
> basically -x would be useful only in case the user does what we asked
> not to do. ;-)
Sorry, I wasn't clear enough: I am talking about a copy-rebase, that is, the
original public branch is unchanged, but you copy patches from it by making
a local temporary branch that starts out in the same place and then
rebasing it onto the other public branch where your want the patches to end
up (followed by fast-forwarding the target branch and removing the temp
branch). This is basically identical to cherry-picking a range of commits,
but since "git cherry-pick" does not support cherry-picking a range of
commits, this is the only alternative, AFAICS.
However, it would probably be a better solution to make "git cherry-pick"
work on a commit range... (cf. the ongoing "multiple-commit cherry-pick"
thread)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-10 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20081110181023.GA22753@coredump.intra.peff.net>
On Mon, Nov 10, 2008 at 7:10 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 10, 2008 at 04:20:51PM +0100, Santi Béjar wrote:
>
>> Hi *,
>>
>> $subject since:
>>
>> 4f672ad (wt-status: load diff ui config, 2008-10-26)
>>
>> I tried to make a test case, but failed. I think because it is a bit
>> tricky the fake_editor/stdin/stdout stuff, so at the end I bisected it
>> by hand
>
> Sorry, I don't quite understand what the problem is. From reading your
> subject line, I expected that "git commit -v" would show the diff in
> your editor, but then accidentally also include it in the final commit
> message. But I can't seem to reproduce that.
>
> Can you describe the problem in more detail?
It is exactly as you described. I'll try in other systems.
Santi
^ permalink raw reply
* [PATCH] 3-way merge with file move fails when diff.renames = copies
From: David D. Kilzer @ 2008-11-10 22:26 UTC (permalink / raw)
To: git; +Cc: David D. Kilzer, Johannes Schindelin, gitster
With diff.renames = copies, a 3-way merge (e.g. "git rebase") would
fail with the following error:
fatal: mode change for <file>, which is not in current HEAD
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
The bug is a logic error added in ece7b749, which attempts to find
an sha1 for a patch with no index line in build_fake_ancestor().
Instead of failing unless an sha1 is found for both the old file and
the new file, a failure should only be reported if neither the old
file nor the new file is found.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
---
builtin-apply.c | 2 +-
t/t3400-rebase.sh | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 4c4d1e1..cfeb6cc 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2573,7 +2573,7 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
else if (get_sha1(patch->old_sha1_prefix, sha1))
/* git diff has no index line for mode/type changes */
if (!patch->lines_added && !patch->lines_deleted) {
- if (get_current_sha1(patch->new_name, sha1) ||
+ if (get_current_sha1(patch->new_name, sha1) &&
get_current_sha1(patch->old_name, sha1))
die("mode change for %s, which is not "
"in current HEAD", name);
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b7a670e..a156850 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -84,4 +84,21 @@ test_expect_success 'rebase a single mode change' '
GIT_TRACE=1 git rebase master
'
+test_expect_success 'rebase a single file move with diff.renames = copies' '
+ git config diff.renames copies &&
+ git checkout master &&
+ echo 1 > Y &&
+ git add Y &&
+ test_tick &&
+ git commit -m "prepare file move" &&
+ git checkout -b filemove HEAD^ &&
+ echo 1 > Y &&
+ git add Y &&
+ mkdir D &&
+ git mv A D/A &&
+ test_tick &&
+ git commit -m filemove &&
+ GIT_TRACE=1 git rebase master
+'
+
test_done
--
1.6.0
^ permalink raw reply related
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-10 23:08 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <20081107054419.GA27146@diana.vm.bytemark.co.uk>
On Fri, Nov 7, 2008 at 12:44 AM, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
>
>> I hit a case when refreshing a buried patch that needed a merge
>> conflict sorted out. I'm unable to recover out of the state.
>
> Hmm, so what you're saying is basically that you did something with
> "stg refresh -p" that caused a merge conflict, and that messed things
> up so that you needed to run "stg repair". Is that right?
Missed the reply.
Yes, that is what happed.
I think the problem was this:
File - xxxxxxx
Patch A adds a line
File - xxxxxxxa
Patch B in the middle adds a line
File - xxxxxxxab
I edit it and add a line
File - xxxxxxxabc
Line c needs to be patch A
stg refresh -p A
..messed up tree
>
> Have you been able to reproduce it? (I would like to add the failing
> case to the test suite.)
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-10 23:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910811101508h3cb30752o77b61926aeefed5b@mail.gmail.com>
On Mon, Nov 10, 2008 at 6:08 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Fri, Nov 7, 2008 at 12:44 AM, Karl Hasselström <kha@treskal.com> wrote:
>> On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
>>
>>> I hit a case when refreshing a buried patch that needed a merge
>>> conflict sorted out. I'm unable to recover out of the state.
>>
>> Hmm, so what you're saying is basically that you did something with
>> "stg refresh -p" that caused a merge conflict, and that messed things
>> up so that you needed to run "stg repair". Is that right?
>
> Missed the reply.
>
> Yes, that is what happed.
>
> I think the problem was this:
>
> File - xxxxxxx
> Patch A adds a line
> File - xxxxxxxa
> Patch B in the middle adds a line
> File - xxxxxxxab
> I edit it and add a line
> File - xxxxxxxabc
> Line c needs to be patch A
> stg refresh -p A
> ..messed up tree
>
>
>
>>
>> Have you been able to reproduce it? (I would like to add the failing
>> case to the test suite.)
Yes, it happens every time the 'stg refresh -p' triggers a merge conflict.
stg repair seem to fix it and then I touch things up manually.
>>
>> --
>> Karl Hasselström, kha@treskal.com
>> www.treskal.com/kalle
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: overly smart rebase - bug or feature?
From: Junio C Hamano @ 2008-11-10 23:14 UTC (permalink / raw)
To: Fedor Sergeev; +Cc: Roman.Shaposhnick, git
In-Reply-To: <20081110212333.GU6799@sun.com>
Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:
> I have recently hit a behavior which might well be a feature,
> but it was very surprising (in a bad sense) to me.
It is a feature misfiring.
Rebase is essentially a repeated cherry-pick, and a cherry-pick of commit
A on top of commit B is done by a simplified 3-way merge between A and B
using the parent of A as the common ancestor.
A A'
/ /
A^... pseudo history ...---B
When your history has renamed Makefile to Makefile2 (thereby losing
Makefile) while transition from A^ to A modified Makefile, the difference
between A^ to A that is applied to B to produce A' contains only the
change about Makefile (and does not talk about the unchangedness of
Makefile1 nor Makefile2 --- in fact, when A' is created, the machinery
does not even know if A^ and A had Makefile1 or Makefile2).
When applying the change to Makefile, it notices that B does not have
Makefile, but there is a path that is _identical_ to the preimage your
change applies to (namely, Makefile2). To support people who rename
Makefile to Makefile2 in the history that led to B, rebase (actually the
underlying "am -3" it calls is where this rename detection smart lies)
applies the changes to the "renamed" path.
You might be able to work this around by forcing rebase not to use the
simplified 3-way merge, by saying "rebase -m".
^ permalink raw reply
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Junio C Hamano @ 2008-11-10 23:25 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1226353631-3716-1-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> Current git versions ignore everything after # (called <head> in the
> following) when pushing. Older versions (before cf818348f1ab57),
> interpret #<head> as part of the URL, which make git bail out.
>
> Ignoring the <head> part for push (fetch respects them) is unlogical.
> As branches origin from Cogito, it is the best to correct this by
> using the behaviour of cg-push:
>
> push HEAD to remote refs/heads/<head>
>
> Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
This message was addressed to me, but is it meant for inclusion?
I do not recall seeing an agreement on what the desired behaviour should
be from (ex-)Cogito users, if this change of behaviour hurts real world
usage of existing git users, andr if so how we ease this change in to the
release.
While I'd personally agree matching with whatever cg-push used to do might
make the most sense in the end, I am not sure changing of behaviour
abruptly like this is a good idea.
I am also not so sure url#branch is illogical; I'd suggest dropping that
line from the commit log message in any case.
> +
> +Depending on the operation, git will use one of the following
> +refsprecs, if you don't provide one on the command line.
> +`<branch>` is the name of this file in `$GIT_DIR/branches` and
> +`<head>` defaults to `master`.
> +
> +git fetch uses:
> +
> +------------
> + refs/heads/<head>:refs/heads/<branch>
> +------------
> +
> +git push uses:
>
> ------------
> - refs/heads/<head>:<repository>
> + HEAD:refs/heads/<head>
> ------------
Why isn't this "refs/heads/<head>:refs/heads/<head>", by the way?
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Junio C Hamano @ 2008-11-10 23:27 UTC (permalink / raw)
To: Santi Béjar; +Cc: Jeff King, Git Mailing List
In-Reply-To: <adf1fd3d0811101434j658b2e8aj83d8cbe2293f5021@mail.gmail.com>
"Santi Béjar" <santi@agolina.net> writes:
> On Mon, Nov 10, 2008 at 7:10 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Nov 10, 2008 at 04:20:51PM +0100, Santi Béjar wrote:
>>
>>> Hi *,
>>>
>>> $subject since:
>>>
>>> 4f672ad (wt-status: load diff ui config, 2008-10-26)
>>>
>>> I tried to make a test case, but failed. I think because it is a bit
>>> tricky the fake_editor/stdin/stdout stuff, so at the end I bisected it
>>> by hand
>>
>> Sorry, I don't quite understand what the problem is. From reading your
>> subject line, I expected that "git commit -v" would show the diff in
>> your editor, but then accidentally also include it in the final commit
>> message. But I can't seem to reproduce that.
>>
>> Can you describe the problem in more detail?
>
> It is exactly as you described. I'll try in other systems.
Guess in the dark... by any chance are you enabling color unconditionally?
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Johannes Schindelin @ 2008-11-10 23:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Francis Galiegue, Git Mailing List, Shawn O. Pearce,
Robin Rosenberg
In-Reply-To: <7v63mv5mro.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 10 Nov 2008, Junio C Hamano wrote:
> Francis Galiegue <fg@one2team.net> writes:
>
> > A very nice git feature, without even going as far as merges, is the
> > cherry pick feature.
>
> I thought cherry-picking needs to be done in terms of 3-way merge, not
> diff piped to patch, for correctness's sake.
I haven't checked how RCS merge does it, but I know how xdiff/xmerge.c
does it ;-)
Basically, it takes the two diffs relative to the base file and works on
the overlapping hunks (i.e. on hunks where the ranges in the base file
overlap).
So we need a diff algorithm very much if we were to imitate that code in
JGit, which I very much plan to do.
Ciao,
Dscho
^ 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