* [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-13 12:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <1226580075-29289-3-git-send-email-charles@hashpling.org>
This option stops git mergetool from aborting at the first failed merge.
This allows some additional use patterns. Merge conflicts can now be
previewed one at time and merges can also be skipped so that they can be
performed in a later pass.
There is also a mergetool.keepGoing configuration variable covering the
same behaviour.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Documentation/config.txt | 4 +++
Documentation/git-mergetool.txt | 12 +++++++++-
git-mergetool.sh | 46 ++++++++++++++++++++++++++++++--------
3 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c5b211a..0b0bc99 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -976,6 +976,10 @@ mergetool.keepBackup::
is set to `false` then this file is not preserved. Defaults to
`true` (i.e. keep the backup files).
+mergetool.keepGoing::
+ Continue to attempt resolution of remaining conflicted files even
+ after a merge has failed or been aborted.
+
mergetool.prompt::
Prompt before each invocation of the merge resolution program.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 176483a..bd2a5ab 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,8 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
+'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt]
+ [-k|--keep-going|--no-keep-going] [<file>]...
DESCRIPTION
-----------
@@ -69,6 +70,15 @@ success of the resolution after the custom tool has exited.
This is the default behaviour; the option is provided to
override any configuration settings.
+-k or --keep-going::
+ Continue to attempt resolution of remaining conflicted files
+ even after a merge has failed or been aborted.
+
+--no-keep-going::
+ Abort the conflict resolution attempt if any single conflict
+ resolution fails or is aborted. This is the default behaviour;
+ the option is provided to override any configuration settings.
+
Author
------
Written by Theodore Y Ts'o <tytso@mit.edu>
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 507028f..d60f493 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,8 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [-y|--no-prompt|--prompt]
+[-k|--keep-going|--no-keep-going] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -70,16 +71,16 @@ resolve_symlink_merge () {
git checkout-index -f --stage=2 -- "$MERGED"
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[rR]*)
git checkout-index -f --stage=3 -- "$MERGED"
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[aA]*)
- exit 1
+ return 1
;;
esac
done
@@ -97,15 +98,15 @@ resolve_deleted_merge () {
[mMcC]*)
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[dD]*)
git rm -- "$MERGED" > /dev/null
cleanup_temp_files
- return
+ return 0
;;
[aA]*)
- exit 1
+ return 1
;;
esac
done
@@ -137,7 +138,7 @@ merge_file () {
else
echo "$MERGED: file does not need merging"
fi
- exit 1
+ return 1
fi
ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
@@ -269,7 +270,8 @@ merge_file () {
if test "$status" -ne 0; then
echo "merge of $MERGED failed" 1>&2
mv -- "$BACKUP" "$MERGED"
- exit 1
+ cleanup_temp_files
+ return 1
fi
if test "$merge_keep_backup" = "true"; then
@@ -280,9 +282,11 @@ merge_file () {
git add -- "$MERGED"
cleanup_temp_files
+ return 0
}
prompt=$(git config --bool mergetool.prompt || echo true)
+keep_going=$(git config --bool mergetool.keepGoing || echo false)
while test $# != 0
do
@@ -305,6 +309,12 @@ do
--prompt)
prompt=true
;;
+ -k|--keep-going)
+ keep_going=true
+ ;;
+ --no-keep-going)
+ keep_going=false
+ ;;
--)
break
;;
@@ -409,6 +419,7 @@ else
fi
fi
+rollup_status=0
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
@@ -424,12 +435,27 @@ if test $# -eq 0 ; then
do
printf "\n"
merge_file "$i" < /dev/tty > /dev/tty
+ if test $? -ne 0; then
+ if test "$keep_going" = true; then
+ rollup_status=1
+ else
+ exit 1
+ fi
+ fi
done
else
while test $# -gt 0; do
printf "\n"
merge_file "$1"
+ if test $? -ne 0; then
+ if test "$keep_going" = true; then
+ rollup_status=1
+ else
+ exit 1
+ fi
+ fi
shift
done
fi
-exit 0
+
+exit $rollup_status
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* [PATCH 2/3] Add -y/--no-prompt option to mergetool
From: Charles Bailey @ 2008-11-13 12:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <1226580075-29289-2-git-send-email-charles@hashpling.org>
This option lets git mergetool invoke the conflict resolution program
without waiting for a user prompt each time.
Also added a mergetool.prompt (default true) configuration variable
controlling the same behaviour
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Documentation/config.txt | 3 +++
Documentation/git-mergetool.txt | 11 ++++++++++-
git-mergetool.sh | 16 +++++++++++++---
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 965ed74..c5b211a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -976,6 +976,9 @@ mergetool.keepBackup::
is set to `false` then this file is not preserved. Defaults to
`true` (i.e. keep the backup files).
+mergetool.prompt::
+ Prompt before each invocation of the merge resolution program.
+
pack.window::
The size of the window used by linkgit:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e0b2703..176483a 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
DESCRIPTION
-----------
@@ -60,6 +60,15 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, 'git-mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.
+-y or --no-prompt::
+ Don't prompt before each invocation of the merge resolution
+ program.
+
+--prompt::
+ Prompt before each invocation of the merge resolution program.
+ This is the default behaviour; the option is provided to
+ override any configuration settings.
+
Author
------
Written by Theodore Y Ts'o <tytso@mit.edu>
diff --git a/git-mergetool.sh b/git-mergetool.sh
index e2da5fc..507028f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [file to merge] ...'
+USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -176,8 +176,10 @@ merge_file () {
echo "Normal merge conflict for '$MERGED':"
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ if "$prompt" = true; then
+ printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
+ read ans
+ fi
case "$merge_tool" in
kdiff3)
@@ -280,6 +282,8 @@ merge_file () {
cleanup_temp_files
}
+prompt=$(git config --bool mergetool.prompt || echo true)
+
while test $# != 0
do
case "$1" in
@@ -295,6 +299,12 @@ do
shift ;;
esac
;;
+ -y|--no-prompt)
+ prompt=false
+ ;;
+ --prompt)
+ prompt=true
+ ;;
--)
break
;;
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* Re: [BUG] fatal error during merge
From: Samuel Tardieu @ 2008-11-13 13:23 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <53328.bFoQE3daRhY=.1226568134.squirrel@webmail.hotelhot.dk>
>>>>> "Anders" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
Anders> I have tested the script with Git 1.6.0.2, but the real
Anders> scenario that made this appear seems to also fail with master
Anders> and next from git.git.
I confirm that your test case also fails with the current "next".
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Kyle Moffett @ 2008-11-13 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Sam Vilain
In-Reply-To: <7vhc6ci24o.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 13, 2008 at 1:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>> And then the "push to current branch" problem is neatly solved: you have
>> no current branch.
>>
>> So:
>>
>> $ git checkout new/branch/to/test^0
>> $ make, configure, etc
>
> Exactly.
>
> I keep a handful pseudo worktrees around (created with git-new-workdir on
> top of a single repository) for quick patch test and build purposes. I do
> not push into them but pushing into a non-bare repository and checking out
> the same branch twice in such a setup share exactly the same issue, and I
> keep their HEADs all detached for exactly the same reason.
I guess the issue comes down to a UI complication. It would very easy
for me to tell somebody how to check out and test their branch in my
testbed if I'm not around, except for that little bit of arcane
syntax. Moreover, the consequences if they forget are really
frustrating and hard to figure out. It's also very easy with a GUI to
do the simple *rightclick branch, click "Checkout"*, but would be much
harder to do the detached HEAD checkout correctly.
If it didn't involve reconfiguring a lot of other people's
repositories, I might consider having them push to "refs/remotes/*".
In theory that's actually much closer to what I'm doing anyways. That
would force any checkouts to be bare, but it would require lots of
git-foo on the pushing side. Perhaps some way to "git push" which
asks the remote repository where it wants the stuff?
Alternatively, it might be possible to add ref attributes or a config
option to force detached HEAD checkouts.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: SZEDER Gábor @ 2008-11-13 14:03 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Linus Torvalds, Anders Melchiorsen, git
In-Reply-To: <2008-11-13-14-23-19+trackit+sam@rfc1149.net>
Hi,
On Thu, Nov 13, 2008 at 02:23:19PM +0100, Samuel Tardieu wrote:
> >>>>> "Anders" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
> Anders> I have tested the script with Git 1.6.0.2, but the real
> Anders> scenario that made this appear seems to also fail with master
> Anders> and next from git.git.
>
> I confirm that your test case also fails with the current "next".
Yeah, and it can be bisected to commit 621ff675 (rev-parse: fix
meaning of rev~ vs rev~0, 2008-03-14), which is from Linus, so put him
on Cc.
Best,
Gábor
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13 14:25 UTC (permalink / raw)
To: SZEDER Gábor, git; +Cc: Samuel Tardieu, Linus Torvalds
In-Reply-To: <20081113140323.GA10267@neumann>
SZEDER Gábor wrote:
>
> On Thu, Nov 13, 2008 at 02:23:19PM +0100, Samuel Tardieu wrote:
>> >>>>> "Anders" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>>
>> Anders> I have tested the script with Git 1.6.0.2, but the real
>> Anders> scenario that made this appear seems to also fail with master
>> Anders> and next from git.git.
>>
>> I confirm that your test case also fails with the current "next".
>
> Yeah, and it can be bisected to commit 621ff675 (rev-parse: fix
> meaning of rev~ vs rev~0, 2008-03-14), which is from Linus, so put him
> on Cc.
I guess that is due to using HEAD~ in the test script? If you are
bisecting, here is a version that does not use the HEAD~ notation:
mkdir am-merge-fail
cd am-merge-fail
git init
mkdir before
touch before/one after
git add before after
git commit -minitial
git branch parallel
rm -f after
git mv before after
git commit -mmove
git checkout parallel
touch other
git add other
git commit -mparallel
git merge master
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: Samuel Tardieu @ 2008-11-13 14:26 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Linus Torvalds, Anders Melchiorsen, git
In-Reply-To: <20081113140323.GA10267@neumann>
* SZEDER Gábor <szeder@ira.uka.de> [2008-11-13 15:03:23 +0100]
| On Thu, Nov 13, 2008 at 02:23:19PM +0100, Samuel Tardieu wrote:
| > >>>>> "Anders" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
| >
| > Anders> I have tested the script with Git 1.6.0.2, but the real
| > Anders> scenario that made this appear seems to also fail with master
| > Anders> and next from git.git.
| >
| > I confirm that your test case also fails with the current "next".
|
| Yeah, and it can be bisected to commit 621ff675 (rev-parse: fix
| meaning of rev~ vs rev~0, 2008-03-14), which is from Linus, so put him
| on Cc.
I think your pinpointed a change of behaviour in "HEAD~", which is
probably not the problem at hand. To find the real bug, you should
update the test script so that it uses "HEAD~1" instead of "HEAD~".
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: SZEDER Gábor @ 2008-11-13 14:53 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: SZEDER Gábor, Linus Torvalds, Anders Melchiorsen, git
In-Reply-To: <2008-11-13-15-26-33+trackit+sam@rfc1149.net>
Hi,
On Thu, Nov 13, 2008 at 03:26:33PM +0100, Samuel Tardieu wrote:
> * SZEDER Gábor <szeder@ira.uka.de> [2008-11-13 15:03:23 +0100]
> | Yeah, and it can be bisected to commit 621ff675 (rev-parse: fix
> | meaning of rev~ vs rev~0, 2008-03-14), which is from Linus, so put him
> | on Cc.
>
> I think your pinpointed a change of behaviour in "HEAD~", which is
> probably not the problem at hand. To find the real bug, you should
> update the test script so that it uses "HEAD~1" instead of "HEAD~".
It doesn't matter. The test script errors out at the merge, and not
at the checkout. Furthermore, it doesn't matter, whether HEAD~,
HEAD~, or HEAD^ is checked out, the results are the same.
But yes, it's possible that not the bisected commit is the culprit,
but something in or behind merge relies on the old undocumented and
illogical behaviour.
Gábor
^ permalink raw reply
* How to do equivalent of git-status using jgit?
From: Farrukh Najmi @ 2008-11-13 15:10 UTC (permalink / raw)
To: git
I am making slow but steady progress thanks to all the help from the
list. Thank you.
I need some guidance on how use jgit to determine what files have
uncommitted changes in the local workspace and what is their status with
respect to the GitIndex.
My goal is to implement a method with the following signature:
void commit(String commitMessage) {
...
}
I am looking at the doCommit method at:
<http://github.com/myabc/nbgit/tree/master/src/org/nbgit/util/GitCommand.java#L306>
This method takes a list of files. What I need is to somehow determine
the list of files that need committing.
Thanks for your help.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* post-update hook
From: Jeremy Ramer @ 2008-11-13 15:53 UTC (permalink / raw)
To: git
I have a set up where I have a local git repo (local1) that I make
changes to and two public repos (remote1, remote2) that hold the
current state of the repo for other applications to access. So my
plan is to make the change is local1, then
git commit
git push remote1 master
git push remote2 master
However, the remotes currently have master checked out so though the
repo gets updated the working directory does not. I tried editting
the post-update hook as follows
#!/bin/sh
echo Update changes...
git checkout master .
but it does not seem to make any difference. Am I missing something
in the way post-update works? It would be really nice to get this
working so I don't have to log into each remote and do a pull. local1
is running git version 1.6.0.2. remotes are running git version 1.5.6.
Thanks!
Jeremy
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Lluis Sanchez Gual @ 2008-11-13 16:10 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Christian Hergert, monodevelop-list, Shawn Pearce,
Git Mailing List
In-Reply-To: <491C090E.4070605@op5.se>
El dj 13 de 11 de 2008 a les 12:01 +0100, en/na Andreas Ericsson va
escriure:
> Christian Hergert wrote:
> > By unmanaged, he means the [DllImport] which you would need to do the call
> > to the extern in the shared library.
> >
> > Everyone that has chimed in has considered doing the git code before,
> > believe us when we say we've thought about wrapping C. In this case, it
> > will be far more flexible in C#. Especially since tools like silverlight do
> > not allow DllImport's.
> >
>
> Well, browser plugins may have a fun time with git support, but it's so far
> from my priority list I couldn't even poke it with a really long pole. The
> fastest way forward is probably to hack on libgit2 and use C# micro-apps
> to verify continually that the binding layer works properly, so that's what
> I'll be doing. I should also state that while C# seems fun and all, my top
> priority is to make the git library usable as quickly as possible so that
> it can attract more attention from developers. That's why I think it's so
> vitally important to get some few usable steps working fast (such as diffing
> against the index, staging stuff for commit and creating a commit).
>
> Once we have that much, basic IDE integration should be fairly easy, and
> then people will want to do more so interest (hopefully from developers)
> is likely to increase.
>
I like the plan!
Lluis.
^ permalink raw reply
* bugreport: git does not like subseconds
From: Jan Engelhardt @ 2008-11-13 16:26 UTC (permalink / raw)
To: git
Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
and somehow does time travel instead. Perhaps this is a Glibc
limitation? Running openSUSE 11's glibc-2.8(which is actually
a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
$ git init
Initialized empty Git repository in /dev/shm/f/.git/
$ echo tomato >banana.c
$ git add banana.c
$ GIT_AUTHOR_DATE="2008-11-11 19:36:33.983771268 +0100" git ci -m 'foo'
Created initial commit e65a6b0: foo
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 banana.c
$ git log
commit e65a6b06c2ff3ef458cb16e7ee6f17ef39757538
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Mon Mar 5 06:47:48 2001 +0100
foo
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Paolo Bonzini @ 2008-11-13 16:41 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200811121515.48277.chriscool@tuxfamily.org>
> Of course it also depends on how often people use "git bisect", but it seems
> that there are people out there bisecting very frequently and that these
> people care very much about bisectability of the tree.
What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick
-n" of COMMIT after every bisection unless COMMIT is in the ancestry of
the current revision? So if you have to bisect between A and B, and you
know that a bug present between A and B was fixed by C, you could do
git bisect good A
git bisect bad B
git bisect cherry-pick C
This would subsume Junio's proposal: users could also set up a few
special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
that you could use for purposes other than ensuring known bugs are fixed.
Finally, you could have a [bisect] configuration section with entries
like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
>> Things like paranoid update hook
>> needs to become very careful about refs/replace/ for security reasons,
>> but I think this would make the grafts much easier to use.
>
> I agree that it would make grafts much easier to use (and would be very
> security sensitive).
Not so much. People with public servers could create refs/replace in
the server and give it 400 permissions, and/or git would refuse to
create the refs/replace directory, forcing users to create it manually
unless it is already in the server.
Paolo
^ permalink raw reply
* Re: bugreport: git does not like subseconds
From: Linus Torvalds @ 2008-11-13 16:45 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0811131722360.13330@fbirervta.pbzchgretzou.qr>
On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>
>
> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
> and somehow does time travel instead. Perhaps this is a Glibc
> limitation? Running openSUSE 11's glibc-2.8(which is actually
> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
("date/time: do not get confused by fractional seconds").
But maybe that hasn't made it into any release yet? It's in master, but
maybe it never made it into stable? Junio?
Linus
^ permalink raw reply
* git-daemon: single-line logging
From: Jan Engelhardt @ 2008-11-13 16:51 UTC (permalink / raw)
To: git; +Cc: jengelh
Hi,
I wrote this patch for my git-daemon to make it much easier to parse
/var/log/git-daemon.log -- namely reducing the output from three lines
per connected client to just one.
commit 4dc99ff38c7e09aabf253bd9f65e8b4958654f7e
against v1.6.0.4
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Aug 24 12:12:29 2008 -0400
git-daemon: single-line logs
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 18 +++++++-----------
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/daemon.c b/daemon.c
index 8dcde73..8ecfe7b 100644
--- a/daemon.c
+++ b/daemon.c
@@ -319,14 +319,15 @@ static int git_daemon_config(const char *var, const char *value, void *cb)
return 0;
}
-static int run_service(struct interp *itable, struct daemon_service *service)
+static int run_service(struct interp *itable, struct daemon_service *service,
+ const char *origin)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'",
- service->name,
- itable[INTERP_SLOT_DIR].value);
+ loginfo("%s->%s %s \"%s\"\n",
+ origin, itable[INTERP_SLOT_HOST].value,
+ service->name, itable[INTERP_SLOT_DIR].value);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -534,10 +535,10 @@ static void fill_in_extra_table_entries(struct interp *itable)
static int execute(struct sockaddr *addr)
{
static char line[1000];
+ char addrbuf[256] = "";
int pktlen, len, i;
if (addr) {
- char addrbuf[256] = "";
int port = -1;
if (addr->sa_family == AF_INET) {
@@ -556,7 +557,6 @@ static int execute(struct sockaddr *addr)
port = ntohs(sin6_addr->sin6_port);
#endif
}
- loginfo("Connection from %s:%d", addrbuf, port);
}
alarm(init_timeout ? init_timeout : timeout);
@@ -564,10 +564,6 @@ static int execute(struct sockaddr *addr)
alarm(0);
len = strlen(line);
- if (pktlen != len)
- loginfo("Extended attributes (%d bytes) exist <%.*s>",
- (int) pktlen - len,
- (int) pktlen - len, line + len + 1);
if (len && line[len-1] == '\n') {
line[--len] = 0;
pktlen--;
@@ -596,7 +592,7 @@ static int execute(struct sockaddr *addr)
*/
interp_set_entry(interp_table,
INTERP_SLOT_DIR, line + namelen + 5);
- return run_service(interp_table, s);
+ return run_service(interp_table, s, addrbuf);
}
}
^ permalink raw reply related
* Re: bugreport: git does not like subseconds
From: Jan Engelhardt @ 2008-11-13 16:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811130842550.3468@nehalem.linux-foundation.org>
On Thursday 2008-11-13 17:45, Linus Torvalds wrote:
>On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>>
>> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
>> and somehow does time travel instead. Perhaps this is a Glibc
>> limitation? Running openSUSE 11's glibc-2.8(which is actually
>> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
>
>This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
>("date/time: do not get confused by fractional seconds").
>
>But maybe that hasn't made it into any release yet? It's in master, but
>maybe it never made it into stable? Junio?
Seems so:
$ git describe 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
v1.6.0-3-g9f2b6d2
$ git merge-base 9f2b6d2936a7c4bb3155de8efec7b10869ca935e v1.6.0.3
result: dba9194a49452b5f093b96872e19c91b50e526aa
$ git describe dba9194a49452b5f093b96872e19c91b50e526aa
v1.6.0-1-gdba9194
Which means it's not in; -forest also verifies it:
[v1.6.0.x goes here]
^
│
├ │ │ mailinfo: re-fix MIME multipart boundary parsing
│ │ ┌─│─[fix]──date/time: do not get confused by fractional seconds
│ │ ├ │ Start 1.6.1 cycle
├─≡───┘ │
├ │ │ Start 1.6.0.X maintenance series
├─│─────│─[v1.6.0]──GIT 1.6.0
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13 17:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20081113145325.GD29274@neumann>
SZEDER Gábor wrote:
> It doesn't matter. The test script errors out at the merge, and not
> at the checkout. Furthermore, it doesn't matter, whether HEAD~,
> HEAD~, or HEAD^ is checked out, the results are the same.
Just to be sure, I tried reverting the commit that you bisected -- and my
test case still fails.
Anders.
^ permalink raw reply
* Re: post-update hook
From: Junio C Hamano @ 2008-11-13 17:08 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: git
In-Reply-To: <b9fd99020811130753o13c5aa0cj79126a502d449cde@mail.gmail.com>
"Jeremy Ramer" <jdramer@gmail.com> writes:
> ... I tried editting
> the post-update hook as follows
>
> #!/bin/sh
> echo Update changes...
> git checkout master .
>
> but it does not seem to make any difference.
By above do you mean you do not even see "Update changes...", or do you
mean you do see that message but "checkout" does not seem to do anything?
I notice that you said you "tried _editing_"; did you also enable it?
If you enabled it, you would see "Update changes..." but notice that "git
checkout master" reports modifications. Try adding "-f" between "checkout"
and "master".
> ... Am I missing something
> in the way post-update works?
That, or in the way "checkout" works.
By the way, this is one reason why pushing directly into the checked out
branch of a non-bare repository is not optimal. A recommended practice is
to make the automation pretend as if you did a pull from the remote,
> ... It would be really nice to get this
> working so I don't have to log into each remote and do a pull.
without actually having to log into each remote and run "pull" there.
* Realize that if you did go to the remote and run "pull", then the
change from the local machine is copied (via the underlying "fetch"
that is run by "pull") in "remotes/origin/master", not to the branch
"master". And then the result is merged.
IOW,
remote$ git pull
when fully spelled out, is:
remote$ git fetch local1 master:remotes/origin/master
remote$ git merge remotes/origin/master
That is, "master" branch tip from local1 goes to remote branch
"origin/master" at remote1, and it is merged to whatever is checked
out.
* Arrange that if you push from local1 to remote1, the above
automatically happens, in post-update hook. So
(1) Do not push into 'master'; IOW, do not:
local1$ git push remote1 master:master ;# BAD
Instead, push into the remotes/origin/master, to mimic _as if you
fetched in the opposite direction_, like so:
local1$ git push remote1 master:refs/remotes/origin/master
Notice that this corresponds to what happens in the "git fetch"
phase if you pulled in the reverse. So all the hook needs to do is
to merge.
(2) Arrange post-update on the remote end to run the merge, when a push
came to "origin/master", something like:
#!/bin/sh
case " $* " in
*' refs/remotes/origin/master '*)
cd .. ;# you would be in .git -- go to the root of tree
git merge refs/remotes/origin/master
;;
esac
I didn't test this, though...
The advantage of doing it this way is that you can configure it so that it
does not matter in which direction you actually work. When you _do_ have
to go to the remote side to get the changes from local (perhaps on some
emergency that keeps you at remote), you can do a "git pull local" and you
can expect that the exact same thing as what your post-update script
ordinarily does happens.
^ permalink raw reply
* Re: bugreport: git does not like subseconds
From: Junio C Hamano @ 2008-11-13 17:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan Engelhardt, git
In-Reply-To: <alpine.LFD.2.00.0811130842550.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>>
>>
>> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
>> and somehow does time travel instead. Perhaps this is a Glibc
>> limitation? Running openSUSE 11's glibc-2.8(which is actually
>> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
>
> This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
> ("date/time: do not get confused by fractional seconds").
>
> But maybe that hasn't made it into any release yet? It's in master, but
> maybe it never made it into stable? Junio?
No it didn't.
Actually I didn't even think of that as a bug, in the sense that git never
accepted fractional seconds and feeding such to git was a user error from
day one; iow, 9f2b6d2 (date/time: do not get confused by fractional
seconds, 2008-08-16) was an idiotproofing ;-)
But I'd agree perhaps we should cherry pick that one.
^ permalink raw reply
* [PATCH] Documentation: New GUI configuration and command-line options.
From: Alexander Gavrilov @ 2008-11-13 17:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Paul Mackerras
Add information on new git-gui and gitk command-line options,
configuration variables, and the encoding attribute.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Documentation/config.txt | 24 ++++++++++++++++++++++++
Documentation/git-gui.txt | 19 +++++++++++++++++++
Documentation/gitattributes.txt | 17 +++++++++++++++++
Documentation/gitk.txt | 5 +++++
4 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 965ed74..2223dc4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -796,6 +796,14 @@ gui.diffcontext::
Specifies how many context lines should be used in calls to diff
made by the linkgit:git-gui[1]. The default is "5".
+gui.encoding::
+ Specifies the default encoding to use for displaying of
+ file contents in linkgit:git-gui[1] and linkgit:gitk[1].
+ It can be overridden by setting the 'encoding' attribute
+ for relevant files (see linkgit:gitattributes[5]).
+ If this option is not set, the tools default to the
+ locale encoding.
+
gui.matchtrackingbranch::
Determines if new branches created with linkgit:git-gui[1] should
default to tracking remote branches with matching names or
@@ -818,6 +826,22 @@ gui.spellingdictionary::
the linkgit:git-gui[1]. When set to "none" spell checking is turned
off.
+gui.fastcopyblame::
+ If true, 'git gui blame' uses '-C' instead of '-C -C' for original
+ location detection. It makes blame significantly faster on huge
+ repositories at the expense of less thorough copy detection.
+
+gui.copyblamethreshold::
+ Specifies the theshold to use in 'git gui blame' original location
+ detection, measured in alphanumeric characters. See the
+ linkgit:git-blame[1] manual for more information on copy detection.
+
+gui.blamehistoryctx::
+ Specifies the radius of history context in days to show in
+ linkgit:gitk[1] for the selected commit, when the `Show History
+ Context` menu item is invoked from 'git gui blame'. If this
+ variable is set to zero, the whole history is shown.
+
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 0e650f4..d0bc98b 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -65,9 +65,28 @@ git gui blame v0.99.8 Makefile::
example the file is read from the object database and not
the working directory.
+git gui blame --line=100 Makefile::
+
+ Loads annotations as described above and automatically
+ scrolls the view to center on line '100'.
+
git gui citool::
Make one commit and return to the shell when it is complete.
+ This command returns a non-zero exit code if the window was
+ closed in any way other than by making a commit.
+
+git gui citool --amend::
+
+ Automatically enter the 'Amend Last Commit' mode of
+ the interface.
+
+git gui citool --nocommit::
+
+ Behave as normal citool, but instead of making a commit
+ simply terminate with a zero exit code. It still checks
+ that the index does not contain any unmerged entries, so
+ you can use it as a GUI version of linkgit:git-mergetool[1]
git citool::
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index eb64841..e02899f 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -495,6 +495,23 @@ in the file. E.g. the string `$Format:%H$` will be replaced by the
commit hash.
+Viewing files in GUI tools
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`encoding`
+^^^^^^^^^^
+
+The value of this attribute specifies the character encoding that should
+be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to
+display the contents of the relevant file. Note that due to performance
+considerations linkgit:gitk[1] does not use this attribute unless you
+manually enable per-file encodings in its options.
+
+If this attribute is not set or has an invalid value, the value of the
+`gui.encoding` configuration variable is used instead
+(See linkgit:git-config[1]).
+
+
USING ATTRIBUTE MACROS
----------------------
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index ae29a00..317f631 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -56,6 +56,11 @@ frequently used options.
Use this instead of explicitly specifying <revs> if the set of
commits to show may vary between refreshes.
+--select-commit=<ref>::
+
+ Automatically select the specified commit after loading the graph.
+ Default behavior is equivalent to specifying '--select-commit=HEAD'.
+
<revs>::
Limit the revisions to show. This can be either a single revision
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* How to do equivalent of "git-reset --hard" and "git revert HEAD" using jgit?
From: Farrukh Najmi @ 2008-11-13 17:43 UTC (permalink / raw)
To: git
I need some guidance on how use jgit to implement the following methods:
/**
* Rolls back all uncommitted changes so Index and worspace are
rolled to committed state in HEAD version.
* Functionally equivalent to "git reset --hard HEAD"
*
*/
public void rollback() {
}
/**
* Undoes the last commit.
* Functionally equivalent to "git revert HEAD"
*
* @param versionNameToRevertTo Version of Commit to revert to
*/
public void revert(String versionNameToRevertTo) {
}
It seems that I will have to walk the Tree and check status of each file
to decide what to do with it. The TreeWalk api is not obvious from the
javadoc.
TIA for any guidance you can provide.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-13 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v63mshsb7.fsf@gitster.siamese.dyndns.org>
Le jeudi 13 novembre 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Le mercredi 12 novembre 2008, Junio C Hamano a écrit :
> > ...
> >
> >> When you want to hunt for a bug, it is certainly possible that your
> >> tests fail for a bug that is unrelated to what you are hunting for for
> >> a range of commits. Borrowing from your picture:
> >>
> >> ...--O--A--X1--X2--...--Xn--B--...
> >>
> >> non of the commit marked as Xi may not be testable.
> >>
> >> But at that point, will you really spend time to rebuild history
> >> between A and B by fixing an unrelated bug that hinders your bisect,
> >> so that you can have a parallel history that is bisectable? I doubt
> >> anybody would.
> >
> > I think kernel developers and perhaps others do that somehow. I mean,
> > there is the following text in the git-bisect(1) documentation:
> >
> > "
> > You may often find that during bisect you want to have near-constant
> > tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
> > "revision that does not have this commit needs this patch applied to
> > work around other problem this bisection is not interested in") applied
> > to the revision being tested.
> >
> > To cope with such a situation, after the inner git-bisect finds the
> > next revision to test, with the "run" script, you can apply that tweak
> > before compiling,...
> > "
> >
> > So we suggest that people patch at bisect time in case of problems. But
> > I think creating a parallel branch should be better in the long run,
> > because you can easily keep the work you did to make things easier to
> > bisect and you can easily share it with other people working with you.
>
> I strongly disagree.
>
> Maybe you hit X2 which does have a breakage, and you would need to patch
> up that one before being able to test for your bug, but after you say
> good or bad on that one, the next pick will be far away from that Xi
> segment. You will test many more revisions before you come back to X3 or
> X5. Why should we force the users to fix all the commits in the segment
> "just in case" somebody's bisect falls into the range before that
> actually happens?
The users would not be _forced_ at all to use "git bisect replace", they can
ignore it if they want. And even if other coworkers use it, they are not
forced at all to use it themself. If they get none of
the "bisect-replace-*" branches, the behavior of git bisect will not change
at all.
> In other words, unless the breakage you are hunting for exists between
> point A and B that you cannot bisect for that other breakage, you won't
> need to patch-up _every single revision_ in the range for the breakage.
> Doing so beforehand is wasteful.
I think that it depends on many factors. More precisely, it depends on how
easy it is to fully test (because to make sure that the bug your are
bisecting is between A and B you need to test A and B, so you waste some
testing) vs how easy it is to patch up every single revision between A and
B.
And I think it can be really easy to patch up every revision between A and
B, you might need only something like:
$ git checkout -b patch-up B
$ git rebase -i A^
and then squash the last commit into the first one, in the list "git
rebase -i" gives you. It may even be easy to automate this with code like
this (completely untested, and it assumes git rebase -i accept a script
from stdin which may not work right now):
create_replace_branch() {
_a="$1"
_b="$2"
git checkout -b bisect-replace-$_b "$_b" || exit
git rev-list ^"$_a"^ "$_b" | {
while read sha1
do
case $sha1 in
$_a) echo "pick $_a"; echo "squash $_b" ;;
$_b) ;;
*) echo "pick $sha1 ;;
esac
done
} | git rebase -i "$_a"^
}
> And if you know the range of A..B and the fix, the procedure to follow
> the suggestion you quoted above from the doc can even be automated
> relatively easily. Your "run" script would need to do two merge-base to
> see if the version to be tested falls inside the range, and if so apply
> the known fix before testing (and clean it up afterwards).
>
> Come to think of it, you do not even need to have a custom run script.
> How about an approach illustrated by this patch?
This is interesting, but the fix up patch might not apply cleanly on all the
commits in the range, and there is no simple way to share these patches
(and changes to them) in a team. Perhaps more importantly, there is also no
simple way to look at the result from applying the patch or to manipulate
it with other git commands.
I mean it was decided to store changes in Git as blob, trees and commits,
not patches, so why would we store these changes as patches?
Regards,
Christian.
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: SZEDER Gábor @ 2008-11-13 18:09 UTC (permalink / raw)
To: Anders Melchiorsen
Cc: Alex Riesen, Samuel Tardieu, Linus Torvalds, Anders Melchiorsen,
git
In-Reply-To: <57814.N1gUGH5fRhE=.1226596012.squirrel@webmail.hotelhot.dk>
On Thu, Nov 13, 2008 at 06:06:52PM +0100, Anders Melchiorsen wrote:
> SZEDER Gábor wrote:
> > It doesn't matter. The test script errors out at the merge, and not
> > at the checkout. Furthermore, it doesn't matter, whether HEAD~,
> > HEAD~, or HEAD^ is checked out, the results are the same.
>
> Just to be sure, I tried reverting the commit that you bisected -- and my
> test case still fails.
Well, oddly enough, your second test case behaves somewhat differently
than the first one, at least as far as bisect is concerned. Bisect
nails down the second test case to 0d5e6c97 (Ignore merged status of
the file-level merge, 2007-04-26; put Alex on Cc). Reverting this
commit on master makes both of your test cases pass.
Gábor
^ permalink raw reply
* Re: hosting git on a nfs
From: J. Bruce Fields @ 2008-11-13 18:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Brown, Thomas Koch, git, dabe
In-Reply-To: <alpine.LFD.2.00.0811120959050.3468@nehalem.linux-foundation.org>
On Wed, Nov 12, 2008 at 10:14:44AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 12 Nov 2008, David Brown wrote:
> >
> > We had occasionally run into locking problems with 1.5.4.x with
> > renames between different directories. This should be fixed in
> > 1.6.0.3, but we have since migrated to a server model so I don't have
> > any way of testing this.
>
> I suspect it also depends very much on the particular client/server
> combination. Renaming across directories is one of those NFS things that
> some servers don't mind at all.
On the linux server you want to make sure you're exporting with
no_subtree_check (see "man exports").
> > The configuration we did find completely unworkable was using git with
> > the work tree on NFS.
>
> Doing an 'lstat()' on every single file in the tree would tend to do that
> to you, yes. Even with a fast network and a good NFS server, we're talking
> millisecond-range latencies, and if your tree has tens of thousands of
> files, you're going to have each "git diff" take several seconds.
>
> NFS metadata caching can help, but not all clients do it, and even clients
> that _do_ do it tend to have rather low timeouts or rather limited cache
> sizes, so doing "git diff" twice may speed up the second one only if it's
> done really back-to-back - if even then.
>
> And once you get used to "git diff" being instantaneous, I don't think
> anybody is ever agan willing to go back to it taking "a few seconds" (and
> depending on speed of network/server and size of project, the "few" can be
> quite many ;)
Yep.
> So putting the work-tree on NFS certainly _works_, but yes, from a
> performance angle it is going to be really irritatingly slower. I don't
> even think the newer versions of NFS will help with directory and
> attribute caching - the delegations are per-file afaik, and there is no
> good support for extending the caching to directories.
File delegations do cover a file's attributes, so in theory they could
help. But they're only given out on open. The upcoming 4.1 spec has a
few improvements here, and it might be worth looking at whether they're
sufficient to make this work.
--b.
> That said, I don't think git is any _worse_ than anybody else in the
> "worktree on NFS" model. A "git diff" will still be superior ot a CVS diff
> in every way. It's just that when people compare to their home machines
> where they have the work tree on local disk and aggressively cached, when
> they then use a NFS work-tree, they'll likely be very very disappointed.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: hosting git on a nfs
From: James Pickens @ 2008-11-13 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0811120959050.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
> Doing an 'lstat()' on every single file in the tree would tend to do that
> to you, yes. Even with a fast network and a good NFS server, we're talking
> millisecond-range latencies, and if your tree has tens of thousands of
> files, you're going to have each "git diff" take several seconds.
Is there any way to improve 'git status' performance on nfs? I know nothing
about how that code works, but if it's strictly serial, i.e. it waits for the
result of each lstat() before doing the next lstat(), then perhaps it could be
sped up by overlapping the lstat() calls via multi threading.
Reason I ask is that at my work place, using only local disks would be
difficult. We run lots of long running tests in a server farm, and working on
nfs allows the compute servers to access our data transparently.
^ 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