* [PATCH v2 0/4] git-svn: More docs for branch handling in
From: Sebastian Leske @ 2012-12-01 1:08 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
Updated version of my documentation patch for git-svn. Thanks to Michael
J Gruber and Eric Wong for helpful comments.
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
Recommend use of structure options for git svn.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Documentation/git-svn.txt | 84 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 78 insertions(+), 6 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 1/4] git-svn: Document branches with at-sign(@).
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
git svn will sometimes create branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn will create them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 8b0d3ad..824bf82 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -881,6 +881,44 @@ different name spaces. For example:
branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*
+If 'git svn' is configured to fetch branches (and --follow-branches
+is in effect), it will sometimes create multiple branches for one SVN
+branch, where the addtional branches have names of the form
+'branchname@nnn' (with nnn an SVN revision number). These additional
+branches are created if 'git svn' cannot find a parent commit for the
+first commit in an SVN branch, to connect the branch to the history of
+the other branches. Normally, the first commit in an SVN branch consists
+of a copy operation. 'git svn' will read this commit to get the SVN
+revision the branch was created (copied) from. It will then try to find the
+git commit that corresponds to this SVN revision, and use that as the
+parent of the branch. However, it is possible that there is no suitable
+git commit to serve as parent. This will happen, among other reasons,
+if the SVN branch is a copy of a revision that was not fetched by 'git
+svn' (e.g. because it is an old revision that was skipped with
+'--revision'), or if in SVN a directory was copied that is not tracked
+by 'git svn' (such as a branch that is not tracked at all, or a
+subdirectory of a tracked branch). In these cases, 'git svn' will still
+create a git branch, but instead of using an existing git commit as the
+parent of the branch, it will read the SVN history of the directory the
+branch was copied from and create appropriate git commits (this is
+indicated by the message "Initializing parent: <branchname>").
+Additionally, it will create a special branch named
+'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
+number the branch was copied from. This branch will point to the newly
+created parent commit of the branch. If in SVN the branch was deleted
+and later recreated from a different version, there will be multiple
+such branches with an '@'.
+Note that this may mean that multiple git commits are created for a
+single SVN revision. An example: In an SVN repository with a standard
+trunk/tags/branches layout, a directory trunk/sub is created in r.100.
+In r.200, trunk/sub is branched by copying it to branches/. 'git svn
+clone -s' will then create a branch 'sub'. It will also create new git
+commits for r.100 through r.199 and use these as the history of branch
+'sub'. Thus there will be two git commits for each revision from r.100
+to r.199 (one containing trunk/, one containing trunk/sub/). Finally,
+it will create a branch 'sub@200' pointing to the new parent commit of
+branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
+
BUGS
----
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/5] "diff --stat" counting fixes
From: Antoine Pelisse @ 2012-12-01 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
Hi Junio,
That does make a lot of sense and I would have indeed missed a couple
of things here.
I've been thinking about that "Unmerged" line quite a lot, and I can't
get myself any good reason to keep it.
Would you mind taking a couple of minutes to make it clear ?
I feel like (but I can obviously be wrong):
1. The info is redundant. When performing a merge, all diffs (without
--staged flag) are unmerged
2. While status shows the line once, while diff shows the diff for the file
once, while diff --shortstat counts the file once, diff --stat shows two
lines for the file.
3. diff --numstat shows two lines for the same file. As a script
writer (I guess that's what it's meant for), I would definitely expect
uniqueness in third column/filenames.
Cheers,
Antoine
On Tue, Nov 27, 2012 at 10:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It turns out that there are at least two bugs in the diffstat
> counting code. This series comes on top of the earlier 74faaa1 (Fix
> "git diff --stat" for interesting - but empty - file changes,
> 2012-10-17) to fix them.
>
> Junio C Hamano (5):
> test: add failing tests for "diff --stat" to t4049
> diff --stat: status of unmodified pair in diff-q is not zero
> diff --stat: use "file" temporary variable to refer to data->files[i]
> diff --stat: move the "total count" logic to the last loop
> diff --stat: do not count "unmerged" entries
>
> diff.c | 49 +++++++++++++++++++++++++---------------------
> t/t4049-diff-stat-count.sh | 46 ++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 72 insertions(+), 23 deletions(-)
>
> --
> 1.8.0.1.331.g808d2af
>
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Antoine Pelisse @ 2012-12-01 10:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vobikqelo.fsf@alter.siamese.dyndns.org>
> Yeah, I think I agree that you would need to make sure that the
> other side does not use the revision marked with :2, once you retire
> the object you originally marked with :2 by pruning. Shouldn't the
> second export show :1 and :3 but not :2? It feels like a bug in the
> exporter to me that the mark number is reused in such a case.
It depends what you call a bug.
If the last item from the list is pruned, and no new objects
are exported, you will lose both reference and count to mark :2.
In this situation, incrementing last_idnum was pointless.
Assuming that we can't do anything about that, marks should be
considered mutable (and I don't think there is any way it
shouldn't). Then incrementing last_idnum is always useless.
Now, if marks can change, I don't understand why we use them at all.
(or don't provide the possibility to not use them at least).
In the "hg <-> git" case, it seems like an unecessary step:
hg revs <-> git marks <-> git sha1
Potentially forces the remote-helper to re-read the "marks <-> sha1"
everytime.
Also in the remote-helper, the "list" command requires sha1 for each
heads, while "import/export" can't work with sha1 but only marks, which
seems inconsistent.
My last point is about "git-remote-hg" and still mutable revs.
It seems like Felipe is using revs() rather than node() or hex() to
refer to mercurial changeset while those revs are also mutable, and
there exists immutable references: hex.
To sum up, the whole idea is, why would we use unsafe mutable marks
when we can use safer immutable references ?
Cheers,
Antoine
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Junio C Hamano @ 2012-12-01 9:24 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6i2f-4jXFUpYV6+fYnpG-tSRRA3cRg_v-v=UrgfwfFz_g@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
> <martinvonz@gmail.com> wrote:
>> Slightly off topic, but another difference (or somehow another aspect
>> of the same difference?) that has tripped me up a few times is that
>> "git checkout $rev ." only affects added and modified files...
"checkout $commit pathspec" has always been about checking out the
contents stored in the paths that match the pathspec from the named
commit to the index and also o the working tree. "checkout
pathspec" is similar, but the stuff comes out of the index.
When pathspec is "dir/", it does not match the directory whose name
is "dir". The pathspec matches the paths that store blobs under
that directory.
In other words, "checkout dir/" (or "checkout HEAD~4 dir/) has never
been about "please remove everything in dir/, and then check out
everything in dir/ from the index (or from HEAD~4)". The "please
remove everything in dir/" part is not the job of "checkout"; of
course, you can do it as a separate step (e.g. "rm -fr dir/").
^ permalink raw reply
* Stitching histories of several repositories
From: Ramkumar Ramachandra @ 2012-12-01 9:11 UTC (permalink / raw)
To: Git List
Hi,
I've written a tool to stitch the first-parent histories of several
git repositories. To illustrate, consider that we have a toplevel git
repository inside which the other repositories reside.
/.git
/a/.git
/b/.git
The tool pulls in the objects from /a/.git and /b/.git into /.git by
using alternates. Then, it gets the list of commits by rev-list'ing
and emits a fast-import stream rewriting the paths of the files in a/
from / to a/ and the paths of files in b/ form / to b/ (using M
040000), taking care to have one unified first-parent line. It turns
out that this is quite non-trivial when the individual git
repositories contain lots of merges. To illustrate, this is an
example of how histories from two repositories with one merge commit
each would be stitched:
* c1f81f1 (refs/figlets/first/origin/master)
|\
| * 6eaf22f (refs/figlets/first-2/origin/master)
* 15cd841
* 1f2f408 (refs/figlets/second/origin/master)
|\
| * 4bd7fe3 (refs/figlets/second-2/origin/master)
* bfa9f3c
* 5e1d337 (refs/replay/stitch2, fig/stitch2)
|\
| * 23437d5 (refs/replay/1f2f40-2)
|/
* 4f2d70b
|\
| * e017fa5 (refs/replay/c1f81f-2)
* c0251c7
* 4036fea
I'd like to know whether the tool would be useful to a wider audience,
before I polish it and consider submitting it for inclusion in
contrib/. I think the tool is especially useful for running bisect
and tracking bugs that occur in large projects that consist of many
git repositories. Will a unified log showing commits in different
submodules be useful?
Ram
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Adam Spiers @ 2012-12-01 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
[snipped]
> * as/check-ignore (2012-11-08) 14 commits
> - t0007: fix tests on Windows
> - Documentation/check-ignore: we show the deciding match, not the first
> - Add git-check-ignore sub-command
> - dir.c: provide free_directory() for reclaiming dir_struct memory
> - pathspec.c: move reusable code from builtin/add.c
> - dir.c: refactor treat_gitlinks()
> - dir.c: keep track of where patterns came from
> - dir.c: refactor is_path_excluded()
> - dir.c: refactor is_excluded()
> - dir.c: refactor is_excluded_from_list()
> - dir.c: rename excluded() to is_excluded()
> - dir.c: rename excluded_from_list() to is_excluded_from_list()
> - dir.c: rename path_excluded() to is_path_excluded()
> - dir.c: rename cryptic 'which' variable to more consistent name
>
> Duy helped to reroll this, but it seems that there weren't any
> activity since then during my absense.
I have been delayed several times, but I finally resumed work on
another re-roll. I don't think there is any major reworking required;
just a number of small tweaks.
> * as/test-tweaks (2012-09-20) 7 commits
> - tests: paint unexpectedly fixed known breakages in bold red
> - tests: test the test framework more thoroughly
> - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
> - tests: refactor mechanics of testing in a sub test-lib
> - tests: paint skipped tests in bold blue
> - tests: test number comes first in 'not ok $count - $message'
> - tests: paint known breakages in bold yellow
>
> Various minor tweaks to the test framework to paint its output
> lines in colors that match what they mean better.
>
> Has the "is this really blue?" issue Peff raised resolved???
I have a re-roll of this ready - just need to rebase to latest master,
do a final sanity check, and then send.
Sorry again for the delays.
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Phil Hord @ 2012-11-30 23:52 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121130175309.GA718@odin.tremily.us>
On Fri, Nov 30, 2012 at 12:53 PM, W. Trevor King <wking@tremily.us> wrote:
> On Wed, Nov 28, 2012 at 12:19:04AM +0100, Jens Lehmann wrote:
>> Am 26.11.2012 22:00, schrieb W. Trevor King:
>> > From: "W. Trevor King" <wking@tremily.us>
>> >
>> > This allows users to override the .gitmodules value with a
>> > per-repository value.
>>
>> Your intentions makes lots of sense, but your patch does more than
>> that. Copying the branch setting into .git/config sets the initial
>> branch setting into stone. That makes it impossible to have a branch
>> "foo" in the superproject using a branch "bar" in a submodule and
>> another superproject branch "frotz" using branch "nitfol" for the
>> same submodule. You should use the branch setting from .git/config
>> if present and fall back to the branch setting from .gitmodules if
>> not, which would enable the user to have her own setting if she
>> doesn't like what upstream provides but would still enable others
>> to follow different submodule branches in different superproject
>> branches.
>
> I've mulling this over, and when I started coding support for
> submodule.<name>.remote, I had an idea.
>
> On Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:
>> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:
>> > I've always felt that the "origin" defaults are broken and are simply
>> > being ignored because most users do not trip over them. But ISTR that
>> > submodule commands use the remote indicated by the superproject's
>> > current remote-tracking configuration, with a fallback to 'origin' if
>> > there is none. Sort of a "best effort" algorithm, I think. Am I
>> > remembering that wrong?
>>
>> The current code uses a bare "git-fetch". I'm not sure what that
>> defaults to if you're on a detached head. If it bothers you, I'm fine
>> adding the submodule.<name>.remote option in v6.
>
> In my v5 patch, I check for submodule.<name>.remote first in the usual
> `git config` files. If I don't find what I'm looking for I fall back
> on .gitmodules (basically Jens' suggestion). However, my initial
> copying-to-.git/config approach was mostly done to mimic existing
> configuration handling in git-submodule.sh. Since I agree with Jens
> on configuration precendence, and I now had two options to read
> (.branch and .remote), I thought I'd pull the logic out into its own
> function (code included at the end). While I was shifting the
> existing submodule config handling over to my new function, I noticed
> that with this logic, `submodule init` doesn't really do anything
> important anymore.
If I never 'submodule init' a submodule, it does not get visited by
'git submodule foreach', among others. I think some people use this
behavior explicitly.
On the other hand, I've also notice that a submodule which I have
removed does not get de-inited later one. It causes my 'git submodule
foreach' to emit errors. :-(
Phil
> Likewise for `submodule sync`, which seems to be
> quite similar to `init`.
>
> What to do about this? `init` has been around for a while, so we
> can't just remove it (maybe in 2.0?). Leaving it in place is not
> really a problem though, it just means that the user is locking in the
> current .gitmodules configuration (as Jens pointed out with respect to
> .branch).
>
> I may be way off base here, as I'm fairly new to submodules in general
> and these two commands in particular, but I thought I'd float the
> idea.
>
> Cheers,
> Trevor
>
> ---
> #
> # Print a submodule configuration setting
> #
> # $1 = submodule name
> # $2 = option name
> # $3 = default value
> #
> # Checks in the usual git-config places first (for overrides),
> # otherwise it falls back on .gitmodules. This allows you to
> # distribute project-wide defaults in .gitmodules, while still
> # customizing individual repositories if necessary. If the option is
> # not in .gitmodules either, print a default value.
> #
> get_submodule_config()
> {
> name="$1"
> option="$2"
> default="$3"
> value=$(git config submodule."$name"."$option")
> if test -z "$value"
> then
> value=$(git config -f .gitmodules submodule."$name"."$option")
> fi
> printf '%s' "${value:-$default}"
> }
>
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ permalink raw reply
* [PATCH 5/5] launch_editor: propagate signals from editor to git
From: Jeff King @ 2012-11-30 22:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
We block SIGINT and SIGQUIT while the editor runs so that
git is not killed accidentally by a stray "^C" meant for the
editor or its subprocesses. This works because most editors
ignore SIGINT.
However, some editor wrappers, like emacsclient, expect to
die due to ^C. We detect the signal death in the editor and
properly exit, but not before writing a useless error
message to stderr. Instead, let's notice when the editor was
killed by a terminal signal and just raise the signal on
ourselves. This skips the message and looks to our parent
like we received SIGINT ourselves.
The end effect is that if the user's editor ignores SIGINT,
we will, too. And if it does not, then we will behave as if
we did not ignore it. That should make all users happy.
Note that in the off chance that another part of git has
ignored SIGINT while calling launch_editor, we will still
properly detect and propagate the failed return code from
the editor (i.e., the worst case is that we generate the
useless error, not fail to notice the editor's death).
Signed-off-by: Jeff King <peff@peff.net>
---
editor.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/editor.c b/editor.c
index c892a81..065a7ab 100644
--- a/editor.c
+++ b/editor.c
@@ -39,7 +39,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
struct child_process p;
- int ret;
+ int ret, sig;
memset(&p, 0, sizeof(p));
p.argv = args;
@@ -51,8 +51,11 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
sigchain_push(SIGINT, SIG_IGN);
sigchain_push(SIGQUIT, SIG_IGN);
ret = finish_command(&p);
+ sig = ret + 128;
sigchain_pop(SIGINT);
sigchain_pop(SIGQUIT);
+ if (sig == SIGINT || sig == SIGQUIT)
+ raise(sig);
if (ret)
return error("There was a problem with the editor '%s'.",
editor);
--
1.8.0.1.620.g558b0aa
^ permalink raw reply related
* [PATCH 4/5] run-command: do not warn about child death from terminal
From: Jeff King @ 2012-11-30 22:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
SIGINT and SIGQUIT are not generally interesting signals to
the user, since they are typically caused by them hitting "^C"
or otherwise telling their terminal to send the signal.
Signed-off-by: Jeff King <peff@peff.net>
---
run-command.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/run-command.c b/run-command.c
index 3aae270..757f263 100644
--- a/run-command.c
+++ b/run-command.c
@@ -242,7 +242,8 @@ static int wait_or_whine(pid_t pid, const char *argv0)
error("waitpid is confused (%s)", argv0);
} else if (WIFSIGNALED(status)) {
code = WTERMSIG(status);
- error("%s died of signal %d", argv0, code);
+ if (code != SIGINT && code != SIGQUIT)
+ error("%s died of signal %d", argv0, code);
/*
* This return value is chosen so that code & 0xff
* mimics the exit code that a POSIX shell would report for
--
1.8.0.1.620.g558b0aa
^ permalink raw reply related
* [PATCH 3/5] launch_editor: ignore terminal signals while editor has control
From: Jeff King @ 2012-11-30 22:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
From: Paul Fox <pgf@foxharp.boston.ma.us>
The user's editor likely catches SIGINT (ctrl-C). but if
the user spawns a command from the editor and uses ctrl-C to
kill that command, the SIGINT will likely also kill git
itself (depending on the editor, this can leave the terminal
in an unusable state).
Let's ignore it while the editor is running, and do the same
for SIGQUIT, which many editors also ignore. This matches
the behavior if we were to use system(3) instead of
run-command.
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Signed-off-by: Jeff King <peff@peff.net>
---
editor.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/editor.c b/editor.c
index 842f782..c892a81 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#include "sigchain.h"
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
@@ -38,6 +39,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
struct child_process p;
+ int ret;
memset(&p, 0, sizeof(p));
p.argv = args;
@@ -46,7 +48,12 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (start_command(&p) < 0)
return error("unable to start editor '%s'", editor);
- if (finish_command(&p))
+ sigchain_push(SIGINT, SIG_IGN);
+ sigchain_push(SIGQUIT, SIG_IGN);
+ ret = finish_command(&p);
+ sigchain_pop(SIGINT);
+ sigchain_pop(SIGQUIT);
+ if (ret)
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.8.0.1.620.g558b0aa
^ permalink raw reply related
* [PATCH 2/5] launch_editor: refactor to use start/finish_command
From: Jeff King @ 2012-11-30 22:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
The launch_editor function uses the convenient run_command_*
interface. Let's use the more flexible start_command and
finish_command functions, which will let us manipulate the
parent state while we're waiting for the child to finish.
Signed-off-by: Jeff King <peff@peff.net>
---
editor.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/editor.c b/editor.c
index d834003..842f782 100644
--- a/editor.c
+++ b/editor.c
@@ -37,8 +37,16 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
+ struct child_process p;
- if (run_command_v_opt_cd_env(args, RUN_USING_SHELL, NULL, env))
+ memset(&p, 0, sizeof(p));
+ p.argv = args;
+ p.env = env;
+ p.use_shell = 1;
+ if (start_command(&p) < 0)
+ return error("unable to start editor '%s'", editor);
+
+ if (finish_command(&p))
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.8.0.1.620.g558b0aa
^ permalink raw reply related
* [PATCH 1/5] run-command: drop silent_exec_failure arg from wait_or_whine
From: Jeff King @ 2012-11-30 22:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
We do not actually use this parameter; instead we complain
from the child itself (for fork/exec) or from start_command
(if we are using spawn on Windows).
Signed-off-by: Jeff King <peff@peff.net>
---
run-command.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/run-command.c
index 3b982e4..3aae270 100644
--- a/run-command.c
+++ b/run-command.c
@@ -226,7 +226,7 @@ static inline void set_cloexec(int fd)
fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
}
-static int wait_or_whine(pid_t pid, const char *argv0, int silent_exec_failure)
+static int wait_or_whine(pid_t pid, const char *argv0)
{
int status, code = -1;
pid_t waiting;
@@ -432,8 +432,7 @@ fail_pipe:
* At this point we know that fork() succeeded, but execvp()
* failed. Errors have been reported to our stderr.
*/
- wait_or_whine(cmd->pid, cmd->argv[0],
- cmd->silent_exec_failure);
+ wait_or_whine(cmd->pid, cmd->argv[0]);
failed_errno = errno;
cmd->pid = -1;
}
@@ -538,7 +537,7 @@ int finish_command(struct child_process *cmd)
int finish_command(struct child_process *cmd)
{
- return wait_or_whine(cmd->pid, cmd->argv[0], cmd->silent_exec_failure);
+ return wait_or_whine(cmd->pid, cmd->argv[0]);
}
int run_command(struct child_process *cmd)
--
1.8.0.1.620.g558b0aa
^ permalink raw reply related
* [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
From: Jeff King @ 2012-11-30 22:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paul Fox, Krzysztof Mazur
This is a re-roll of the pf/editor-ignore-sigint series.
There are two changes from the original:
1. We ignore both SIGINT and SIGQUIT for "least surprise" compared to
system(3).
2. We now use "code + 128" to look for signal death (instead of
WTERMSIG), as per run-command's documentation on how it munges the
code.
People mentioned some buggy editors which go into an infinite EIO loop
when their parent dies due to SIGQUIT. That should be a non-issue now,
as we will be ignoring SIGQUIT. And even if you could replicate it
(e.g., with another signal) those programs should be (and reportedly
have been) fixed. It is not git's job to babysit its child processes.
The patches are:
[1/5]: run-command: drop silent_exec_failure arg from wait_or_whine
[2/5]: launch_editor: refactor to use start/finish_command
[3/5]: launch_editor: ignore terminal signals while editor has control
[4/5]: run-command: do not warn about child death from terminal
[5/5]: launch_editor: propagate signals from editor to git
Since this can be thought of as "act more like system(3)", I wondered
whether the signal-ignore logic should be moved into run-command, or
even used by default for blocking calls to run_command (which are
basically our version of system(3)). But it is detrimental in the common
case that the child is not taking control of the terminal, and is just
an implementation detail (e.g., we call "git update-ref" behind the
scenes, but the user does not know or care). If they hit ^C during such
a run and we are ignoring SIGINT, then either:
1. we will notice the child died by signal and report an
error in the subprocess rather than just dying; the end result is
similar, but the error is unnecessarily confusing
2. we do not bother to check the child's return code (because we do
not care whether the child succeeded or not, like a "gc --auto");
we end up totally ignoring the user's request to abort the
operation
So I do not think we care about this behavior except for launching the
editor. And the signal-propagation behavior of 5/5 is really so weirdly
editor-specific (because it is about behaving well whether the child
blocks signals or not).
-Peff
^ permalink raw reply
* [PATCH] gitk: add a checkbox to control the visibility of tags
From: Łukasz Stelmach @ 2012-11-30 21:08 UTC (permalink / raw)
To: git, gitster; +Cc: Łukasz Stelmach
Enable hiding of tags displayed in the tree as yellow labels.
If a repository is used together with a system like Gerrit
there may be quite a lot of tags used to control building
and there may be hardly any place left for commit subjects.
Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
---
gitk-git/gitk | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..274b46b 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1754,7 +1754,7 @@ proc readrefs {} {
global tagids idtags headids idheads tagobjid
global otherrefids idotherrefs mainhead mainheadid
global selecthead selectheadid
- global hideremotes
+ global hideremotes hidetags
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
@@ -1776,6 +1776,7 @@ proc readrefs {} {
set headids($name) $id
lappend idheads($id) $name
} elseif {[string match "tags/*" $name]} {
+ if {$hidetags} continue
# this lets refs/tags/foo^{} overwrite refs/tags/foo,
# which is what we want since the former is the commit ID
set name [string range $name 5 end]
@@ -2702,7 +2703,7 @@ proc savestuff {w} {
global cmitmode wrapcomment datetimeformat limitdiffs
global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
global autoselect autosellen extdifftool perfile_attrs markbgcolor use_ttk
- global hideremotes want_ttk
+ global hideremotes hidetags want_ttk
if {$stuffsaved} return
if {![winfo viewable .]} return
@@ -2725,6 +2726,7 @@ proc savestuff {w} {
puts $f [list set autosellen $autosellen]
puts $f [list set showneartags $showneartags]
puts $f [list set hideremotes $hideremotes]
+ puts $f [list set hidetags $hidetags]
puts $f [list set showlocalchanges $showlocalchanges]
puts $f [list set datetimeformat $datetimeformat]
puts $f [list set limitdiffs $limitdiffs]
@@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
proc prefspage_general {notebook} {
global NS maxwidth maxgraphpct showneartags showlocalchanges
global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
- global hideremotes want_ttk have_ttk
+ global hideremotes hidetags want_ttk have_ttk
set page [create_prefs_page $notebook.general]
@@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
${NS}::checkbutton $page.hideremotes -text [mc "Hide remote refs"] \
-variable hideremotes
grid x $page.hideremotes -sticky w
+ ${NS}::checkbutton $page.hidetags -text [mc "Hide tag labels"] \
+ -variable hidetags
+ grid x $page.hidetags -sticky w
${NS}::label $page.ddisp -text [mc "Diff display options"]
grid $page.ddisp - -sticky w -pady 10
@@ -10988,7 +10993,7 @@ proc doprefs {} {
global oldprefs prefstop showneartags showlocalchanges
global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
- global hideremotes want_ttk have_ttk
+ global hideremotes hidetags want_ttk have_ttk
set top .gitkprefs
set prefstop $top
@@ -10997,7 +11002,7 @@ proc doprefs {} {
return
}
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
- limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
+ limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
set oldprefs($v) [set $v]
}
ttk_toplevel $top
@@ -11117,7 +11122,7 @@ proc prefscan {} {
global oldprefs prefstop
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
- limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
+ limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
global $v
set $v $oldprefs($v)
}
@@ -11131,7 +11136,7 @@ proc prefsok {} {
global oldprefs prefstop showneartags showlocalchanges
global fontpref mainfont textfont uifont
global limitdiffs treediffs perfile_attrs
- global hideremotes
+ global hideremotes hidetags
catch {destroy $prefstop}
unset prefstop
@@ -11177,7 +11182,8 @@ proc prefsok {} {
$limitdiffs != $oldprefs(limitdiffs)} {
reselectline
}
- if {$hideremotes != $oldprefs(hideremotes)} {
+ if {$hideremotes != $oldprefs(hideremotes) ||
+ $hidetags != $oldprefs(hidetags)} {
rereadrefs
}
}
@@ -11601,6 +11607,7 @@ set cmitmode "patch"
set wrapcomment "none"
set showneartags 1
set hideremotes 0
+set hidetags 0
set maxrefs 20
set maxlinelen 200
set showlocalchanges 1
--
1.7.8.6
^ permalink raw reply related
* Bug report: probiem with across-branch git-diff
From: Tomas Neme @ 2012-11-30 21:13 UTC (permalink / raw)
To: git
(env)lacrymology@Roller:boilerplate$ git rev-parse
test_project:boilerplate/apps/custom_zinnia/models/blog.py
9e93aa98ad2aeb8094dd3206b02e7bd835ce6899
lacrymology@Roller:boilerplate$ git diff
boilerplate/apps/custom_zinnia/abstract_models.py
test_project:boilerplate/apps/custom_zinnia/models/blog.py
fatal: Path 'boilerplate/apps/custom_zinnia/models/blog.py' exists,
but not 'boilerplate/apps/custom_zinnia/models/blog.py'.
Did you mean 'test_project:boilerplate/apps/custom_zinnia/models/blog.py'
aka 'test_project:./boilerplate/apps/custom_zinnia/models/blog.py'?
blog.py doesn't exist in the current branch. Current branch descends
from test_project, and abstract_models.py it's actually the same file
`git mv`'ed
--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde
|_|0|_|
|_|_|0|
|0|0|0|
(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
^ permalink raw reply
* Re: [PATCH 5/5] launch_editor: propagate SIGINT from editor to git
From: Jeff King @ 2012-11-30 20:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <50A00116.8060604@kdbg.org>
On Sun, Nov 11, 2012 at 08:48:38PM +0100, Johannes Sixt wrote:
> Am 11.11.2012 17:57, schrieb Jeff King:
> > @@ -51,6 +51,8 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
> > sigchain_push(SIGINT, SIG_IGN);
> > ret = finish_command(&p);
> > sigchain_pop(SIGINT);
> > + if (WIFSIGNALED(ret) && WTERMSIG(ret) == SIGINT)
> > + raise(SIGINT);
>
> The return value of finish_command() is already a digested version of
> waitpid's status value. According to
> Documentation/technical/api-run-command.txt:
>
> . If the program terminated due to a signal, then the return value is
> the signal number - 128, ...
>
> the correct condition would be
>
> if (ret == SIGINT - 128)
Yeah, that is the same thing as WTERMSIG (which uses "ret & 0x7f") for
the range of -127..-1. I do not mind changing it to match run-command's
stated output, but I am curious whether there are systems where WTERMSIG
is not defined in the same way, and the code would break.
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: warn about ".git" in trees
From: Jeff King @ 2012-11-30 19:55 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, git
In-Reply-To: <50B90E11.8090501@web.de>
On Fri, Nov 30, 2012 at 08:50:41PM +0100, Torsten Bögershausen wrote:
> >Having a ".git" entry inside a tree can cause confusing
> >results on checkout. At the top-level, you could not
> >checkout such a tree, as it would complain about overwriting
> >the real ".git" directory. In a subdirectory, you might
> >check it out, but performing operations in the subdirectory
> >would confusingly consider the in-tree ".git" directory as
> >the repository.
> [snip]
> >+ int has_dotgit = 0;
>
> Name like "." or ".." are handled as directories by the OS.
Right. In theory git could run on a system that does not treat them
specially, but in practice they are going to be problematic on most
systems.
> ".git" could be a file or a directory, at least in theory, and from
> the OS point of view, but we want to have this as a reserved name.
Exactly.
> Looking at bad directory names, which gives trouble when checking out:
>
> Should we check for "/" or "../blabla" as well?
We do already (the error is "contains full pathnames"). We also cover
empty pathnames and some other cases.
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: warn about ".git" in trees
From: Torsten Bögershausen @ 2012-11-30 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121128213529.GA16518@sigill.intra.peff.net>
> Having a ".git" entry inside a tree can cause confusing
> results on checkout. At the top-level, you could not
> checkout such a tree, as it would complain about overwriting
> the real ".git" directory. In a subdirectory, you might
> check it out, but performing operations in the subdirectory
> would confusingly consider the in-tree ".git" directory as
> the repository.
[snip]
> + int has_dotgit = 0;
Name like "." or ".." are handled as directories by the OS.
".git" could be a file or a directory, at least in theory,
and from the OS point of view,
but we want to have this as a reserved name.
Looking at bad directory names, which gives trouble when checking out:
Should we check for "/" or "../blabla" as well?
^ permalink raw reply
* Re: [PATCH/RFC 0/5] win32: support echo for terminal-prompt
From: Jeff King @ 2012-11-30 18:30 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <CABPQNSZ7YRgvS1=SR=Nx0wcn+NXCVwqjVShk-ug3=yX62RH-oQ@mail.gmail.com>
On Fri, Nov 30, 2012 at 11:16:59AM +0100, Erik Faye-Lund wrote:
> Ping?
Thanks for the reminder; your initial series came while I was traveling.
I think it looks good. The compat/terminal code ends up a little uglier,
but I think you overall did a good job of balancing code reuse across
platforms with readability.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH/RFC 5/5] mingw: get rid of getpass implementation
From: Jeff King @ 2012-11-30 18:27 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <1352815447-8824-6-git-send-email-kusmabite@gmail.com>
On Tue, Nov 13, 2012 at 03:04:07PM +0100, Erik Faye-Lund wrote:
> There's no remaining call-sites, and as pointed out in the
> previous commit message, it's not quite ideal. So let's just
> lose it.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
> compat/mingw.c | 15 ---------------
> compat/mingw.h | 2 --
> 2 files changed, 17 deletions(-)
Yay!
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH/RFC 4/5] mingw: reuse tty-version of git_terminal_prompt
From: Jeff King @ 2012-11-30 18:27 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <1352815447-8824-5-git-send-email-kusmabite@gmail.com>
On Tue, Nov 13, 2012 at 03:04:06PM +0100, Erik Faye-Lund wrote:
> The getpass-implementation we use on Windows isn't at all ideal;
> it works in raw-mode (as opposed to cooked mode), and as a result
> does not deal correcly with deletion, arrow-keys etc.
>
> Instead, use cooked mode to read a line at the time, allowing the
> C run-time to process the input properly.
>
> Since we set files to be opened in binary-mode by default on
> Windows, introduce a FORCE_TEXT macro that expands to the "t"
> modifier that forces the terminal to be opened in text-mode so we
> do not have to deal with CRLF issues.
I think this is OK. I had originally envisioned just having a separate
"#ifdef WIN32" and not really sharing code at all with /dev/tty because
I was worried that the conditionals would end up making it hard to read.
This is a little more complex than I would have liked, but I do not see
how the code sharing could be simplified any more than what you have
done, and it is nice to avoid repeating ourselves.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH/RFC 3/5] compat/terminal: separate input and output handles
From: Jeff King @ 2012-11-30 18:22 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <1352815447-8824-4-git-send-email-kusmabite@gmail.com>
On Tue, Nov 13, 2012 at 03:04:05PM +0100, Erik Faye-Lund wrote:
> On Windows, the terminal cannot be opened in read-write mode, so
> we need distinct pairs for reading and writing. Since this works
> fine on other platforms as well, always open them in pairs.
Looks OK. We're now opening /dev/tty three separate times in the no-echo
case, but it's not like this is in a performance critical loop.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH/RFC 2/5] compat/terminal: factor out echo-disabling
From: Jeff King @ 2012-11-30 18:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1211301858570.31987@s15462909.onlinehome-server.info>
On Fri, Nov 30, 2012 at 06:59:30PM +0100, Johannes Schindelin wrote:
> > diff --git a/compat/terminal.c b/compat/terminal.c
> > index bbb038d..3217838 100644
> > --- a/compat/terminal.c
> > +++ b/compat/terminal.c
> > @@ -14,6 +14,7 @@ static void restore_term(void)
> > return;
> >
> > tcsetattr(term_fd, TCSAFLUSH, &old_term);
> > + close(term_fd);
> > term_fd = -1;
> > }
>
> That looks like an independent resource leak fix... correct?
I don't think so. In the current code, term_fd does not take ownership
of the fd. It is fundamentally part of the FILE* in git_terminal_prompt,
and is closed when we fclose() that. But in Erik's refactor, we actually
open a _second_ descriptor to /dev/tty, which needs to be closed.
I don't think there is any reason that should not work (the terminal
characteristics should be per-tty, not per-descriptor), though it does
feel a little hacky to have to open /dev/tty twice.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-11-30 18:17 UTC (permalink / raw)
To: Jens Lehmann, Phil Hord
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121130175309.GA718@odin.tremily.us>
On Fri, Nov 30, 2012 at 12:53:09PM -0500, W. Trevor King wrote:
> Likewise for `submodule sync`, which seems to be
> quite similar to `init`.
Ah, I'd remove the part of `sync` that touches the superproject's
.git/config, but keep the part that stores the superproject-reorded
URL in the submodule's config:
url=$(get_submodule_config "$name" url)
up_path=$(get_up_path "$sm_path")
url=$(resolve_relative_url "$url" "$up_path") &&
if test -n "$url"
then
if test -e "$sm_path"/.git
then
(
clear_local_git_env
cd "$sm_path"
remote=$(get_default_remote)
git config remote."$remote".url "$url"
)
fi
fi
I should probably also tweak sync to do similar things with
submodule.<name>.branch and .remote as part of my `--update remote`
series.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ 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