* Re: [PATCH 6/8] sh-tools: add a run_merge_tool function
From: Markus Heidelberg @ 2009-03-30 6:55 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1238389428-69328-7-git-send-email-davvid@gmail.com>
David Aguilar, 30.03.2009:
> + if mergetool_mode; then
> + base=Baes
Base
> + local=Local
> + remote=Remote
> + else
^ permalink raw reply
* Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: Junio C Hamano @ 2009-03-30 6:56 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1238391319-4953-1-git-send-email-rocketraman@fastmail.fm>
rocketraman@fastmail.fm writes:
> + - The 'maint' branch is updated to the new release.
> +
> + $ git branch -f maint master
It appears that you are trying to make this document into a canned set of
insns for people who want a ready-to-cut-and-paste-without-thinking
recipe, and I am perfectly fine with such a document, but as I mentioned
already, "how to maintain git" is not a good place to do so. You seem to
have taken it as a joke, but I am serious.
In any case, I highly doubt we would want to have this "branch -f" here.
Not in "how to maintain git", but especially in a document you would give
to people who do not like to think for themselves but would want to follow
cut-and-paste recipe.
_I_ can do the above, but that is _only_ because I maintain 'master' with
certain discipline---it almost always is a superset of maint (it sometimes
isn't---when I am too tired to do so late at night and the leftover fix on
the 'maint' unmerged to 'master' is really trivial and unimportant in the
grand scheme of things), and especially after a big release it always is.
But for people who want to use a ready-to-cut-and-paste-without-thinking
recipe, it is much better to use:
$ git checkout maint
$ git merge master
just in case they have leftover fixes that later need to get merged to
master. Otherwise they will be discarding the fixes with "branch -f".
An obvious alternative is to firmly describe in the release workflow to
make sure that 'maint' is fully merged to 'master' before a release is
made, but people tend to cherry-pick the parts they want to use without
thinking things through when presented a cut-and-paste recipe, and in
practice I do not think such an alternative would work well.
More important bits of release checklist, a bit outdated, is found in
Checklist.txt file on the 'todo' branch.
I would need to talk a bit more about how to maintain What's in/cooking,
how the automated maintenance of html/man branches work, and how to set up
RPM building infrastructure for use with Meta/DoKernelOrg, in order to
make the Documentation/howto/maintain-git.txt truly to be usable by
somebody capable to take over when I cease to function as the maintainer
here.
^ permalink raw reply
* Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: Junio C Hamano @ 2009-03-30 6:57 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1238391319-4953-2-git-send-email-rocketraman@fastmail.fm>
rocketraman@fastmail.fm writes:
> From: Raman Gupta <raman@rocketraman.com>
>
> Based on a mailing list discussion, add a description of the workflow,
> and associated commands, for creating a feature release.
The same comment applies to the other one, but this commit log message is
really lacking. If you do not bother to summarize the discussion, place a
pointer to the list archive, and more importantly, please describe *why*
this change is desiable.
I am not sure rewinding and rebuilding of 'next', or even having 'next',
is applicable for other projects as a BCP. Other parts (except for the
"branch -f" bit I've already told you about in the other message) looked
good.
Thanks.
^ permalink raw reply
* Re:
From: Markus Heidelberg @ 2009-03-30 7:02 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1238389428-69328-1-git-send-email-davvid@gmail.com>
David Aguilar, 30.03.2009:
> This is based on top of Junio's "pu" branch and is a
> continuation of the recent difftool series.
For everyone who wants to apply the patch series: Patch 5/8 depends on
this:
[PATCH v2] difftool: add support for a difftool.prompt config variable
sent about 8 minutes before this series.
Markus
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Anton Gyllenberg @ 2009-03-30 7:26 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090329060858.GB15773@dcvr.yhbt.net>
Makes perfect sense now that you explain it and I see the patch. I
actually tried debugging it a bit but got lost in the perl SVN code.
Thank you Eric for figuring this out and for all your work on git-svn
in general!
> I guess few folks in the UNIX world are crazy enough to make pathnames
> prefixed with dashes :)
I guess they wouldn't call the project Twisted without reason :-).
Anton
^ permalink raw reply
* Re: [PATCH 6/8] sh-tools: add a run_merge_tool function
From: Markus Heidelberg @ 2009-03-30 7:32 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1238389428-69328-7-git-send-email-davvid@gmail.com>
David Aguilar, 30.03.2009:
> +# Runs a side-by-side merge tool
> +run_merge_tool()
> +{
> + merge_tool="$1"
> +
> + # base_present is always false when !mergetool_mode
> + case "$merge_tool" in
> + kdiff3)
> [...]
Kompare is missing here. Note, that this is only diff tool, not for
merges.
Markus
^ permalink raw reply
* Re: [PATCH 6/8] sh-tools: add a run_merge_tool function
From: David Aguilar @ 2009-03-30 7:46 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200903300932.29870.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> David Aguilar, 30.03.2009:
> > +# Runs a side-by-side merge tool
> > +run_merge_tool()
> > +{
> > + merge_tool="$1"
> > +
> > + # base_present is always false when !mergetool_mode
> > + case "$merge_tool" in
> > + kdiff3)
> > [...]
>
> Kompare is missing here. Note, that this is only diff tool, not for
> merges.
>
> Markus
>
Thanks, will fixup asap.
I botched the --cover letter too ;)
note to self: no more refactoring while sleepy on plane.
--
David
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Johannes Schindelin @ 2009-03-30 7:48 UTC (permalink / raw)
To: Michael Johnson; +Cc: Miklos Vajna, git
In-Reply-To: <op.urk20nanso3nzr@sulidor.mdjohnson.us>
Hi,
On Sun, 29 Mar 2009, Michael Johnson wrote:
> On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna <vmiklos@frugalware.org>
> wrote:
>
> >On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson
> ><redbeard@mdjohnson.us> wrote:
> > >The 1.6.2.1 version just segfaults, but 1.5.6.5 says:
> > >
> > >/usr/bin/git-merge: line 438: 32335 Segmentation fault
> > >git-merge-$strategy $common -- "$head_arg" "$@"
> > >Merge with strategy recursive failed.
> > >
> > >In all cases, .git/index.lock is left behind.
> >
> >That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
> >directly without a fork. Could you try it in gdb and provide a
> >backtrace, please?
>
> Well, I've got a backtrace, but I don't have debugging symbols, apparently.
> There is not a Debian package I can find that has them. I checked
> debug.debian.net, as well as the standard sid repository. So I will have to
> rebuild the package with debugging turned on. I will not be able to do that
> tonight, unfortunately. I will probably have a chance tomorrow evening.
>
> Just in case it might be useful, though, here's the backtrace, without
> symbols.
>
> Starting program: /usr/bin/git merge origin/dojo-1.3
> (no debugging symbols found)
> ... repeated multiple times ...
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> ... repeated multiple times
> [New Thread 0xb7a73b30 (LWP 21505)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7a73b30 (LWP 21505)]
> 0x080e5a6f in ?? ()
> (gdb) backtrace
> #0 0x080e5a6f in ?? ()
> #1 0x0893e000 in ?? ()
> #2 0x000f0000 in ?? ()
> #3 0xbf949098 in ?? ()
> #4 0x080e63ad in ?? ()
> #5 0x08977fcf in ?? ()
> #6 0x000f0000 in ?? ()
> #7 0xfff0ffff in ?? ()
> #8 0x08945dd8 in ?? ()
> #9 0x00000000 in ?? ()
This segfault sounds vaguely like something I tried to fix.
Unfortunately, I cannot spend time on it right now, except send you the
patch that could help the issue:
-- snipsnap --
>From 084909acbb576be4c4815e047ee4247b95c70cda Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mon, 10 Nov 2008 23:25:31 +0100
Subject: [PATCH] merge-recursive: fail gracefully with directory/submodule conflicts
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 15 ++++++++-------
diff --git a/merge-recursive.c b/merge-recursive.c
index 3e1bc3e..8ada5a9 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -519,14 +519,14 @@ static void update_file_flags(struct merge_options *o,
void *buf;
unsigned long size;
- if (S_ISGITLINK(mode))
- die("cannot read object %s '%s': It is a submodule!",
- sha1_to_hex(sha), path);
-
- buf = read_sha1_file(sha, &type, &size);
+ if (S_ISGITLINK(mode)) {
+ buf = xstrdup(sha1_to_hex(sha));
+ size = strlen(buf);
+ } else
+ buf = read_sha1_file(sha, &type, &size);
if (!buf)
die("cannot read object %s '%s'", sha1_to_hex(sha), path);
- if (type != OBJ_BLOB)
+ if (!S_ISGITLINK(mode) && type != OBJ_BLOB)
die("blob expected for %s '%s'", sha1_to_hex(sha), path);
if (S_ISREG(mode)) {
struct strbuf strbuf = STRBUF_INIT;
@@ -542,7 +542,8 @@ static void update_file_flags(struct merge_options *o,
free(buf);
goto update_index;
}
- if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
+ if (S_ISGITLINK(mode) || S_ISREG(mode) ||
+ (!has_symlinks && S_ISLNK(mode))) {
int fd;
if (mode & 0100)
mode = 0777;
^ permalink raw reply related
* Re: [PATCH 07/10] rev-list: call new "filter_skip" function
From: Johannes Schindelin @ 2009-03-30 7:54 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, John Tapsell
In-Reply-To: <200903300526.12978.chriscool@tuxfamily.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1955 bytes --]
Hi,
On Mon, 30 Mar 2009, Christian Couder wrote:
> Le jeudi 26 mars 2009, Junio C Hamano a écrit :
> > Christian Couder <chriscool@tuxfamily.org> writes:
> > > This patch implements a new "filter_skip" function in C in
> > > "bisect.c" that will later replace the existing implementation in
> > > shell in "git-bisect.sh".
> > >
> > > An array is used to store the skipped commits. But the array is
> > > not yet fed anything.
> > >
> > > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > > ---
> > > bisect.c | 65
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ bisect.h
> > > | 6 ++++-
> > > builtin-rev-list.c | 30 ++++++++++++++++++++----
> > > 3 files changed, 95 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/bisect.c b/bisect.c
> > > index 27def7d..39189f2 100644
> > > --- a/bisect.c
> > > +++ b/bisect.c
> > > @@ -4,6 +4,11 @@
> > > #include "revision.h"
> > > #include "bisect.h"
> > >
> > > +
> > > +static unsigned char (*skipped_sha1)[20];
> > > +static int skipped_sha1_nr;
> > > +static int skipped_sha1_alloc;
> > > +
> > > /* bits #0-15 in revision.h */
> > >
> > > #define COUNTED (1u<<16)
> > > @@ -386,3 +391,63 @@ struct commit_list *find_bisection(struct
> > > commit_list *list, return best;
> > > }
> > >
> > > +static int skipcmp(const void *a, const void *b)
> > > +{
> > > + return hashcmp(a, b);
> > > +}
> >
> > I've learned to suspect without reading a qsort() callback that does not
> > derefence its arguments. Is this doing the right thing?
>
> I think so.
I suspect something much worse: you are trying to build a list of sha1s of
commits that need to be skipped, later to look up every commit via
binary search.
But it has been proven a lot of times that using a hash set is superior to
that approach, and even better: we already have the framework in place in
the form of struct decorate.
Ciao,
Dscho "who is too busy to review patches ATM"
^ permalink raw reply
* Re: [PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"
From: Junio C Hamano @ 2009-03-30 7:59 UTC (permalink / raw)
To: Christian Couder; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <20090329114457.c6fca0fe.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The implementation of "read_bisect_paths" worked with only one
> path in each line of "$GIT_DIR/BISECT_NAMES", but the paths are all
> stored on one line by "git-bisect.sh".
>
> So we have to process all the paths that may be on each line.
This is "oops, the previous one is broken", for a series that was not yet
'next' worthy, so I squashed the fix and rebuilt the topic, together with
your other patches.
The series now looks like this:
$ git log --oneline --boundary master..cc/bisect-filter
b54809a bisect--helper: string output variables together with "&&"
fd5a6a8 rev-list: pass "int flags" as last argument of "show_bisect_vars"
e2c52e1 t6030: test bisecting with paths
56fac26 bisect: use "bisect--helper" and remove "filter_skipped" function
650bafa bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES"
a79b083 bisect--helper: implement "git bisect--helper"
29adb27 quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
ccc12f5 quote: implement "sq_dequote_many" to unwrap many args in one string
a292c81 rev-list: call new "filter_skip" function
58f0b66 rev-list: pass "revs" to "show_bisect_vars"
41440cf rev-list: make "show_bisect_vars" non static
a650efd rev-list: move code to show bisect vars into its own function
2bc0667 rev-list: move bisect related code into its own file
7cc17b8 rev-list: make "bisect_list" variable local to "cmd_rev_list"
52ffe77 refs: add "for_each_bisect_ref" function
-89fbda2 Merge branch 'maint'
I've tweaked a few patches before applying, but they all looked basically
sane. Unless I hear from other people in a few days , I'd say we merge it
to 'next' and start cooking it.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/4] Rename push.default to push.style
From: Finn Arne Gangstad @ 2009-03-30 8:01 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1238281804-30290-5-git-send-email-santi@agolina.net>
On Sun, Mar 29, 2009 at 12:10:04AM +0100, Santi Béjar wrote:
> push.default was too generic, and also didn't specify if it was about
> remote, refspec, branches, behaviour...
> [...]
> "You can specify what action you want to take in this case, and",
> - "avoid seeing this message again, by configuring 'push.default' to:",
> + "avoid seeing this message again, by configuring 'push.style' to:",
> " 'nothing' : Do not push anything",
> " 'matching' : Push all matching branches (default)",
> " 'tracking' : Push the current branch to whatever it is tracking",
> [...]
I don't think "push.style" is an improvement. "style" sounds like it
affects all pushes. This configuration variable says what push should
do when no refspec is given and none are configured, so the word
"default" should be in there at least. Maybe "defaultref" would have
been better?
Some people may have started setting push.default already, so changing
the name may cause additional grief.
- Finn Arne
^ permalink raw reply
* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Johannes Schindelin @ 2009-03-30 8:03 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: msysgit, git, Shawn O. Pearce
In-Reply-To: <200903300851.43164.markus.heidelberg@web.de>
Hi,
On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> Johannes Schindelin, 30.03.2009:
>
> > On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> >
> > > Starting git-gui via Windows Explorer shell extension caused
> > > problems when not started from the project directory, but from a
> > > directory within the project: starting the Explorer from the git-gui
> > > menu "Explore Working Copy" didn't work then.
> > >
> > > Starting git-gui via Explorer shell extension from the .git
> > > directory didn't work at all.
> > >
> > > To make these things possible, "cd .." until we see .git/
> >
> > How does this interact with GIT_WORK_TREE?
>
> Not sure. What's the use case for a globally set GIT_WORK_TREE, how is
> it used?
You can call git gui with a non-global GIT_WORK_TREE by something like
this, even on Windows (which your patch does not special case, anyway):
$ GIT_WORK_TREE=/bla/blub git gui
> > And with bare repositories?
>
> Git-gui doesn't seem to work with bare repositories, I get
> "Cannot use funny .git directory: ."
> when started on the command line.
Oh? I thought there was some discussion recently that was explicitely
about git gui with bare repositories. But I have to time-share my brain
these days, so my memory might well show some bit flips.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 6/8 v2] sh-tools: add a run_merge_tool function
From: David Aguilar @ 2009-03-30 8:11 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
This function launches merge tools and will be used to refactor
git-(diff|merge)tool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This fixes the problems spotted by Markus.
Documentation/git-sh-tools.txt | 3 +
git-sh-tools.sh | 160 +++++++++++++++++++++++++++++++++++++--
2 files changed, 154 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-sh-tools.txt b/Documentation/git-sh-tools.txt
index 055a10c..68d1b37 100644
--- a/Documentation/git-sh-tools.txt
+++ b/Documentation/git-sh-tools.txt
@@ -36,6 +36,9 @@ init_merge_tool_path::
sets up `$merge_tool_path` according to '(diff|merge)tool.<tool>.path'
configurations.
+run_merge_tool::
+ runs the specified merge tool.
+
Author
------
Written by David Aguilar <davvid@gmail.com>
diff --git a/git-sh-tools.sh b/git-sh-tools.sh
index 234bac7..e8593fc 100644
--- a/git-sh-tools.sh
+++ b/git-sh-tools.sh
@@ -2,7 +2,12 @@
# Built-in merge tools are always valid.
valid_tool() {
case "$1" in
- kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kompare)
+ if mergetool_mode; then
+ return 1
+ fi
+ ;; # happy
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
;; # happy
*)
if ! valid_custom_tool "$1"; then
@@ -12,29 +17,34 @@ valid_tool() {
esac
}
+# Test whether we're in merge mode
+mergetool_mode()
+{
+ test "$TOOL_MODE" = "merge"
+}
+
# Verifies that (difftool|mergetool).<tool>.cmd exists
# Requires $TOOL_MODE to be set.
valid_custom_tool() {
- if test "$TOOL_MODE" = "diff"; then
- merge_tool_cmd="$(git config difftool.$1.cmd)"
- test -z "$merge_tool_cmd" &&
+ if mergetool_mode; then
merge_tool_cmd="$(git config mergetool.$1.cmd)"
test -n "$merge_tool_cmd"
- elif test "$TOOL_MODE" = "merge"; then
+ else
+ merge_tool_cmd="$(git config difftool.$1.cmd)"
+ test -z "$merge_tool_cmd" &&
merge_tool_cmd="$(git config mergetool.$1.cmd)"
test -n "$merge_tool_cmd"
fi
}
-
# Set up $merge_tool_path for (diff|merge)tool.<tool>.path configurations
init_merge_tool_path() {
- if test "$TOOL_MODE" = "diff"; then
+ if mergetool_mode; then
+ merge_tool_path=$(git config mergetool."$1".path)
+ else
merge_tool_path=$(git config difftool."$1".path)
test -z "$merge_tool_path" &&
merge_tool_path=$(git config mergetool."$1".path)
- elif test "$TOOL_MODE" = "merge"; then
- merge_tool_path=$(git config mergetool."$1".path)
fi
if test -z "$merge_tool_path" ; then
@@ -48,3 +58,135 @@ init_merge_tool_path() {
esac
fi
}
+
+# Runs a side-by-side merge tool
+run_merge_tool()
+{
+ merge_tool="$1"
+
+ # base_present is always false when !mergetool_mode
+ case "$merge_tool" in
+ kdiff3)
+ if mergetool_mode; then
+ base=Base
+ local=Local
+ remote=Remote
+ else
+ base=A
+ local=A
+ remote=B
+ fi
+ if base_present; then
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED ($base)" \
+ --L2 "$MERGED ($local)" \
+ --L3 "$MERGED ($remote)" \
+ -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1)
+ else
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED ($local)" \
+ --L2 "$MERGED ($remote)" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1)
+ fi
+ status=$?
+ ;;
+
+ kompare)
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ status=$?
+ ;;
+
+ tkdiff)
+ if base_present; then
+ "$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
+ else
+ "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
+ fi
+ status=$?
+ ;;
+ meld)
+ mergetool_mode && touch "$BACKUP"
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
+ mergetool_mode && check_unchanged
+ ;;
+ vimdiff)
+ mergetool_mode && touch "$BACKUP"
+ "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
+ mergetool_mode && check_unchanged
+ ;;
+ gvimdiff)
+ mergetool_mode && touch "$BACKUP"
+ "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
+ mergetool_mode && check_unchanged
+ ;;
+ xxdiff)
+ if mergetool_mode; then
+ touch "$BACKUP"
+ xtra_args='--show-merged-pane'
+ else
+ xtra_args=
+ fi
+ if base_present; then
+ "$merge_tool_path" -X $xtra_args \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
+ else
+ "$merge_tool_path" -X $xtra_args \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" "$LOCAL" "$REMOTE"
+ fi
+ mergetool_mode && check_unchanged
+ ;;
+ opendiff)
+ mergetool_mode && touch "$BACKUP"
+ if base_present; then
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -ancestor "$BASE" -merge "$MERGED" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ fi
+ mergetool_mode && check_unchanged
+ ;;
+ ecmerge)
+ mergetool_mode && touch "$BACKUP"
+ if base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
+ --default --mode=merge3 --to="$MERGED"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ --default --mode=merge2 --to="$MERGED"
+ fi
+ mergetool_mode && check_unchanged
+ ;;
+ emerge)
+ if base_present ; then
+ "$merge_tool_path" -f emerge-files-with-ancestor-command \
+ "$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
+ else
+ "$merge_tool_path" -f emerge-files-command \
+ "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+ fi
+ status=$?
+ ;;
+ *)
+ if test -n "$merge_tool_cmd"; then
+ if test "$merge_tool_trust_exit_code" = "false"; then
+ mergetool_mode && touch "$BACKUP"
+ ( eval $merge_tool_cmd )
+ mergetool_mode && check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ fi
+ ;;
+ esac
+ return $status
+}
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: [PATCH 4/4] Rename push.default to push.style
From: Johannes Schindelin @ 2009-03-30 8:23 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Santi Béjar, git
In-Reply-To: <20090330080115.GA19142@pvv.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1186 bytes --]
Hi,
On Mon, 30 Mar 2009, Finn Arne Gangstad wrote:
> On Sun, Mar 29, 2009 at 12:10:04AM +0100, Santi Béjar wrote:
> > push.default was too generic, and also didn't specify if it was about
> > remote, refspec, branches, behaviour...
> > [...]
> > "You can specify what action you want to take in this case, and",
> > - "avoid seeing this message again, by configuring 'push.default' to:",
> > + "avoid seeing this message again, by configuring 'push.style' to:",
> > " 'nothing' : Do not push anything",
> > " 'matching' : Push all matching branches (default)",
> > " 'tracking' : Push the current branch to whatever it is tracking",
> > [...]
>
> I don't think "push.style" is an improvement. "style" sounds like it
> affects all pushes. This configuration variable says what push should do
> when no refspec is given and none are configured, so the word "default"
> should be in there at least. Maybe "defaultref" would have been better?
I'd prefer "push.defaultMode", but...
> Some people may have started setting push.default already, so changing
> the name may cause additional grief.
... indeed, it is too late now. The milk has boiled already.
Ciao,
Dscho
^ permalink raw reply
* [Q] merging from one (kernel) stable to another?
From: Brian Foster @ 2009-03-30 8:24 UTC (permalink / raw)
To: git mailing list
Whilst this question involves linux(-mips) kernel tree,
it's a git(-related?) question, not a kernel question ....
We are currently in the process of upgrading our embedded
system from kernel 2.6.21(-ish) to at least 2.6.26.8; and
later, at some time in the future on to 2.6.3x or something.
Going from 2.6.21 to .22 to .23 and so on to .26, then to
.26.1 and so on to .26.8 is “easy” in the sense there are
very few conflicts with our existing baseline (e.g., just
2 or 3 in 2 or 3 files).
.21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
\ \ \ \ \
.21-stable .22-stable .23-stable \ .27-stable
.26.8
\
.26-stable
But (using 2.6.21-stable and 2.6.22-stable as proxies),
tests indicate that going from .26.8 to .27 or anything
later will have numerous conflicts (100s? in more than
30 files). Thinking about it, this isn't too surprising
since the -stable branches cherry-pick important/benign
fixes from later revisions.
What's frustrating is that in essentially all “conflict”
cases, the resolution is simple: Use the later version.
Very few conflicts are caused by our local changes. But
the merge tool I used (‘tkdiff’ via ‘git mergetool’) for
my tests doesn't seem to make that resolution an easy
thing to do — I (seem to) have to manually check each
and every conflict, which very quickly becomes tedious
(read: error-prone).
Is there a (relatively) easy way to manage this situation?
Trying some internet searches didn't find much of anything,
albeit just what to search for isn't too clear.
Thanks for any suggestions (including “RFT<a named>M”).
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCH 1/8] mergetool: use tabs consistently
From: Junio C Hamano @ 2009-03-30 8:44 UTC (permalink / raw)
To: David Aguilar; +Cc: git, Charles Bailey
In-Reply-To: <1238389428-69328-2-git-send-email-davvid@gmail.com>
Thanks.
Even though this [1/8] is obviously regression free, and I think the
overall direction in which the series is going is good, I'll wait until I
hear Acks from Charles Bailey for the parts that involve mergetool. I do
not use either mergetool nor difftool myself, and going over every single
line of this series to spot potential regression is beyond my bandwidth
right now.
I do not think bits only common between mergetool and difftool should be
called with a very generic name "sh-tools". We didn't call the result of
a similar refactoring for launching web browser from help and instaweb
context with such a generic name (it is called git-web--browse).
^ permalink raw reply
* Re:
From: Junio C Hamano @ 2009-03-30 8:46 UTC (permalink / raw)
To: markus.heidelberg; +Cc: David Aguilar, git
In-Reply-To: <200903300902.28821.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> David Aguilar, 30.03.2009:
>> This is based on top of Junio's "pu" branch and is a
>> continuation of the recent difftool series.
>
> For everyone who wants to apply the patch series: Patch 5/8 depends on
> this:
> [PATCH v2] difftool: add support for a difftool.prompt config variable
> sent about 8 minutes before this series.
Thanks for keeping an eye on this series, as a recent contributor to
mergetool. I do not use mergetool myself, but this refactoring seems to
be a good idea in general, and help in reviewing the series is very much
appreciated.
^ permalink raw reply
* [POC PATCH] difftool: add support for the --interactive flag
From: David Aguilar @ 2009-03-30 8:48 UTC (permalink / raw)
To: gitster; +Cc: git, Ping Yin, David Aguilar
'git diff --interactive' already provides a prompt so
we should inhibit the difftool-helper prompt by default.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Based on top of [PATCH v2] difftool.prompt
and Ping's 'git diff --interactive' patch.
This is just an example of what we'd need to change
in git-difftool if git-diff grew --interactive.
git-difftool.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 985dfe0..0e1efe6 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -53,6 +53,11 @@ sub generate_command
$skip_next = 0;
next;
}
+ if ($arg eq '--interactive') {
+ $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ delete $ENV{GIT_DIFFTOOL_PROMPT};
+ # pass-through
+ }
if ($arg eq '-t' || $arg eq '--tool') {
usage() if $#ARGV <= $idx;
$ENV{GIT_DIFF_TOOL} = $ARGV[$idx + 1];
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: [PATCH 4/4] Rename push.default to push.style
From: Santi Béjar @ 2009-03-30 9:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Finn Arne Gangstad, git
In-Reply-To: <alpine.DEB.1.00.0903301021540.7534@intel-tinevez-2-302>
2009/3/30 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 30 Mar 2009, Finn Arne Gangstad wrote:
>
>> On Sun, Mar 29, 2009 at 12:10:04AM +0100, Santi Béjar wrote:
>> > push.default was too generic, and also didn't specify if it was about
>> > remote, refspec, branches, behaviour...
>> > [...]
>> > "You can specify what action you want to take in this case, and",
>> > - "avoid seeing this message again, by configuring 'push.default' to:",
>> > + "avoid seeing this message again, by configuring 'push.style' to:",
>> > " 'nothing' : Do not push anything",
>> > " 'matching' : Push all matching branches (default)",
>> > " 'tracking' : Push the current branch to whatever it is tracking",
>> > [...]
>>
>> I don't think "push.style" is an improvement. "style" sounds like it
>> affects all pushes.
Not for me. I says the style of the push. But maybe push.mode could be better.
>> This configuration variable says what push should do
>> when no refspec is given and none are configured, so the word "default"
>> should be in there at least. Maybe "defaultref" would have been better?
I don't see the point of the word default, a lot of configuration is
to set the default value. Git has branch.name.remote, not
branch.name.defaultremote, or user.email, not user.defaultemail,...
>
> I'd prefer "push.defaultMode", but...
>
>> Some people may have started setting push.default already, so changing
>> the name may cause additional grief.
>
> ... indeed, it is too late now. The milk has boiled already.
I have it configured, but I think we can fix these type of things
while they are in 'next'.
Santi
^ permalink raw reply
* Re: [POC PATCH] diff options: Introduce --interactive
From: David Aguilar @ 2009-03-30 9:04 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1238391670-4421-1-git-send-email-pkufranky@gmail.com>
On 0, Ping Yin <pkufranky@gmail.com> wrote:
> The new option --interactive introduces an interactive diff mode. Now we
> can choose to see the diff for a selected file.
I just tried it out. Very cool.
It's exactly the functionality users have asked me about.
I just sent a for-the-future patch that teaches difftool
to tell difftool-helper that it shouldn't prompt when
you're using --interactive.
I noticed git-diff doesn't have a -i flag yet,
perhaps it could be the shorthand for --interactive?
(I'd have to change that for-the-future patch I just sent
too since it also only checks for the long form...)
I like it.
>
> This is a preparation to introduce the --tool option to launch the
> external diff tool for a selected file.
With both of our latest patches:
git difftool --interactive <revargs>
does exactly what one would expect it to.
How are you envisioning --tool? It'd be great if we didn't
need the perl wrapper, though something does need to set
GIT_EXTERNAL_DIFF/GIT_PAGER/etc... (that is, unless you have a
better way =))
> >> When the user types a number, git-difftool-helper is launched to show
> >> the diff for the corresponding file.
> >
> > Cool.
> > I had two patches that I sent to the list for
> > git-difftool.perl. If you're going to patch it then you might
> > want to base it on top of those.
> >
> When i try to code on git-difftool.perl, i find it is more appropriate to add
> the --interactive and then --tool options to git-diff itself. So here is a
> proof of concept patch based on next. What we should do next is to try to
> design a good UI.
I'll see if I can come up with any suggestions.
I liked it on the first test drive.
--
David
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-03-30 9:06 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
>
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
>
You can set the time manually for each commit. I suppose it's not quite the
same as doing it by taking the timestamp of a single file. Personally, I've
never quite understood the point of it, since I always have to do at least
*some* testing (even if it's only a compile-test) after I'm done editing so
I know what I'm committing isn't totally broken.
Can you describe a use-case where this would be handy?
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
>
This has been discussed to death, and it's much, much harier than just
handling binary files. Browse the list archives for the (many, lengthy and
sometimes heated) discussions on this topic. A quick recap of the outcome
of *ALL* such discussions is as follows, though:
1 It would potentially make git horribly slow at switching branches.
2 It's rarely interesting to version a single file, but always interesting
to version the entire project (what do I care if README was v1,1 in CVS
when what I *really* want to know is which version of the program I should
file my bug-report against).
3 It's far better to set the version number in the release-process. Usually
this can be done automatically by one invocation of "git describe", just
as git.git does it.
We've adopted "3" full out at $dayjob. Our build-machinery gets the version
number from the git tag (releases can only be built from signed tags), and
it updates macros and whatnot used for informing the user which version he
or she is running. This makes a lot more sense both from a bug-reporting
and from a release process view than having generated version-numbers in
files. On a side-note; When I told my co-workers I'd like us to switch to
git, two of them asked about autoversioning features. I said there weren't
any and asked them to name a single time when we've actually used them for
anything *at all*. In a team of eight, having been programming for three
years with 12 releases and about 800 bugreports + feature-requests, noone
could mention a single time when the autogenerated version numbers had
actually been used for anything.
Otoh, having the entire repository locally makes it painless to view the
commit-log for an entire project (or parts of it) and see who changed what
when and why, which is information that's actually *useful*.
> 3) "git undo": If possible undo the effects of the last command.
>
Immensely complex to create, and the command would almost certainly cause
more confusion than order before it can handle every single operation that
a user would want to undo. Instead, the most common operations that require
some form of user-interaction have an "--abort" switch which does roughly
what a "git undo" command would.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 4/4] Rename push.default to push.style
From: Santi Béjar @ 2009-03-30 9:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Finn Arne Gangstad, git
In-Reply-To: <adf1fd3d0903300200v65393b1bif0050392aa44652e@mail.gmail.com>
2009/3/30 Santi Béjar <santi@agolina.net>:
> 2009/3/30 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> On Mon, 30 Mar 2009, Finn Arne Gangstad wrote:
>>> Some people may have started setting push.default already, so changing
>>> the name may cause additional grief.
>>
>> ... indeed, it is too late now. The milk has boiled already.
>
> I have it configured, but I think we can fix these type of things
> while they are in 'next'.
>
Now that I've recheck it, it seems to be in 'master', it's less clear,
but I still think we can fix these type of things while they are not
in a relased version.
The people with that setting is following the development version, and
can easily notice/change it.
Santi
^ permalink raw reply
* [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Erik Faye-Lund @ 2009-03-30 9:08 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
t/t9301-fast-export.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index b860626..763dde5 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -262,4 +262,21 @@ test_expect_success 'cope with tagger-less tags' '
'
+test_expect_success 'set-up a few more tags for tag export tests' '
+
+ git checkout -f master &&
+ HEAD_TREE=`git show -s --pretty=raw HEAD | grep tree | sed "s/tree //"` &&
+ git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
+ git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
+ git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
+ git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
+
+'
+
+# NEEDSWORK: not just check return status, but validate the output
+test_expect_failure 'tree_tag' 'git fast-export tree_tag'
+test_expect_failure 'tree_tag-obj' 'git fast-export tree_tag-obj'
+test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
+test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
+
test_done
--
1.6.2.1
^ permalink raw reply related
* [PATCH 2/4] builtin-fast-export.c: turn error into warning
From: Erik Faye-Lund @ 2009-03-30 9:08 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1238404137-6693-1-git-send-email-kusmabite@gmail.com>
fast-import doesn't have a syntax to support tree-objects (and some other
object-types), so fast-export shouldn't handle them. However, aborting the
operation is a bit drastic. This patch turns the error into a warning instead.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 34a419c..027c4aa 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -379,8 +379,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
}
break;
default:
- die ("Unexpected object of type %s",
- typename(e->item->type));
+ warning("%s: Unexpected object of type %s, skipping.",
+ e->name,
+ typename(e->item->type));
+ continue;
}
if (commit->util)
/* more than one name for the same object */
--
1.6.2.1
^ permalink raw reply related
* [PATCH 3/4] builtin-fast-export.c: fix crash on tagged trees
From: Erik Faye-Lund @ 2009-03-30 9:08 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1238404137-6693-2-git-send-email-kusmabite@gmail.com>
If a tag object points to a tree (or another unhandled type), the commit-
pointer is left uninitialized and later dereferenced. This patch adds a default
case to the switch that issues a warning and skips the object.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 4 ++++
t/t9301-fast-export.sh | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 027c4aa..2070288 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -376,6 +376,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
case OBJ_BLOB:
handle_object(tag->object.sha1);
continue;
+ default:
+ warning("Tag points to object of unexpected type %s, skipping.",
+ typename(tag->object.type));
+ continue;
}
break;
default:
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 763dde5..b587feb 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -274,8 +274,8 @@ test_expect_success 'set-up a few more tags for tag export tests' '
'
# NEEDSWORK: not just check return status, but validate the output
-test_expect_failure 'tree_tag' 'git fast-export tree_tag'
-test_expect_failure 'tree_tag-obj' 'git fast-export tree_tag-obj'
+test_expect_success 'tree_tag' 'git fast-export tree_tag'
+test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
--
1.6.2.1
^ 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