* [PATCH] Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
From: Christian Couder @ 2007-11-18 15:34 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Previously we tested if the "$GIT_DIR/refs/bisect" directory
existed, to check if we were bisecting.
Now with packed refs, it is simpler to check if the file
"$GIT_DIR/BISECT_NAMES" exists, as it is already created when
starting bisection and removed when reseting bisection.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 4748c6a..01593eb 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -37,7 +37,7 @@ sq() {
}
bisect_autostart() {
- test -d "$GIT_DIR/refs/bisect" || {
+ test -f "$GIT_DIR/BISECT_NAMES" || {
echo >&2 'You need to start by "git bisect start"'
if test -t 0
then
@@ -83,7 +83,6 @@ bisect_start() {
# Get rid of any old bisect state
#
bisect_clean_state
- mkdir "$GIT_DIR/refs/bisect"
#
# Check for one bad and then some good revisions.
@@ -192,7 +191,7 @@ bisect_next_check() {
;;
*)
THEN=''
- test -d "$GIT_DIR/refs/bisect" || {
+ test -f "$GIT_DIR/BISECT_NAMES" || {
echo >&2 'You need to start by "git bisect start".'
THEN='then '
}
@@ -349,8 +348,6 @@ bisect_reset() {
}
bisect_clean_state() {
- rm -fr "$GIT_DIR/refs/bisect"
-
# There may be some refs packed during bisection.
git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\* refs/heads/bisect |
while read ref hash
--
1.5.3.5.1815.g9445b-dirty
^ permalink raw reply related
* [PATCH 1/2] push: Add '--matching' option and print warning if it should be used
From: Steffen Prohaska @ 2007-11-18 16:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Steffen Prohaska
In-Reply-To: <Pine.LNX.4.64.0711121501500.4362@racer.site>
This on the road to
1) "git push --matching" pushes matching branches.
2) "git push --current" pushes only current branch.
3) "git push" reports error if the config does not contain a Push line.
(after it reported a warning for a while).
Maybe in two years (that's twice an eternity in git time scales):
4) make "git push --current" the default.
This commit adds '--matching', which is a no-op at this point.
If appropriate, a warning is printed to tell the user that the
default will change in the future.
Thanks to Dscho for suggesting this.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-push.txt | 8 +++++++-
builtin-push.c | 13 +++++++++++--
t/t5516-fetch-push.sh | 13 +++++++++++++
3 files changed, 31 insertions(+), 3 deletions(-)
So here is '--matching'. And PATCH 2/2 will bring '--current'.
They apply on top of sp/refspec-match.
Steffen
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4a68aab..d2417f3 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
DESCRIPTION
@@ -63,6 +63,12 @@ the remote repository.
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+\--matching::
+ Instead of naming each ref to push, specifies that matching
+ refs under `$GIT_DIR/refs/heads/` be pushed. Matching means
+ the branch exists locally and at the remote under the same name.
+ Currently, this is the default. But this will change in the future.
+
\--dry-run::
Do everything except actually send the updates.
diff --git a/builtin-push.c b/builtin-push.c
index 54fba0e..7e9dcf1 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
int all = 0;
+ int matching = 0;
int dry_run = 0;
int force = 0;
int tags = 0;
@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT__VERBOSE(&verbose),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
+ OPT_BOOLEAN( 0 , "matching", &matching, "push matching refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -135,8 +137,15 @@ int cmd_push(int argc, const char **argv, const char *prefix)
repo = argv[0];
set_refspecs(argv + 1, argc - 1);
}
- if ((flags & TRANSPORT_PUSH_ALL) && refspec)
+ if ((all != 0) + (matching != 0) > 1) {
+ fprintf(stderr, "--all and --matching are mutual exclusive.\n");
usage_with_options(push_usage, options);
+ }
+ if ((all || matching) && refspec)
+ usage_with_options(push_usage, options);
+ if (!all && !matching && !refspec)
+ fprintf(stderr, "Warning: assuming '--matching'."
+ " This default will change in the future.\n");
return do_push(repo, flags);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index fd5f284..21aa7c3 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,6 +100,19 @@ test_expect_success 'fetch with wildcard' '
)
'
+test_expect_code 129 'push command line options (1)' '
+ git push --all --matching testrepo
+'
+
+test_expect_code 129 'push command line options (2)' '
+ git push --matching testrepo master
+'
+
+test_expect_success 'push command line options (3)' '
+ git push testrepo 2>stderr.txt &&
+ grep -q "Warning: assuming.*--matching" stderr.txt
+'
+
test_expect_success 'push without wildcard' '
mk_empty &&
--
1.5.3.5.743.g87c5c
^ permalink raw reply related
* [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Steffen Prohaska @ 2007-11-18 16:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Steffen Prohaska
In-Reply-To: <11954023881802-git-send-email-prohaska@zib.de>
Often you want to push only the current branch to the default
remote. This was awkward to do in the past. You needed to
remember the default remote and type "git push $remote HEAD".
This commit teaches push to do this if you use '--current'.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-push.txt | 6 +++++-
builtin-push.c | 16 +++++++++++-----
t/t5516-fetch-push.sh | 29 +++++++++++++++++++++++++++++
3 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d2417f3..2dfaf50 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
DESCRIPTION
@@ -69,6 +69,10 @@ the remote repository.
the branch exists locally and at the remote under the same name.
Currently, this is the default. But this will change in the future.
+\--current::
+ Instead of naming each ref to push, specifies that only the
+ current branch be pushed.
+
\--dry-run::
Do everything except actually send the updates.
diff --git a/builtin-push.c b/builtin-push.c
index 7e9dcf1..e5646d4 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git-push [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -101,6 +101,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
int flags = 0;
int all = 0;
int matching = 0;
+ int current = 0;
int dry_run = 0;
int force = 0;
int tags = 0;
@@ -111,6 +112,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
OPT_BOOLEAN( 0 , "matching", &matching, "push matching refs"),
+ OPT_BOOLEAN( 0 , "current", ¤t, "push current branch"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -137,15 +139,19 @@ int cmd_push(int argc, const char **argv, const char *prefix)
repo = argv[0];
set_refspecs(argv + 1, argc - 1);
}
- if ((all != 0) + (matching != 0) > 1) {
- fprintf(stderr, "--all and --matching are mutual exclusive.\n");
+ if ((all != 0) + (matching != 0) + (current != 0) > 1) {
+ fprintf(stderr, "--all, --matching, and --current are mutual exclusive.\n");
usage_with_options(push_usage, options);
}
- if ((all || matching) && refspec)
+ if ((all || matching || current) && refspec)
usage_with_options(push_usage, options);
- if (!all && !matching && !refspec)
+ if (!all && !matching && !current && !refspec)
fprintf(stderr, "Warning: assuming '--matching'."
" This default will change in the future.\n");
+ if (current) {
+ const char* head[1] = { "HEAD" };
+ set_refspecs(head, 1);
+ }
return do_push(repo, flags);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 21aa7c3..20e0796 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -113,6 +113,18 @@ test_expect_success 'push command line options (3)' '
grep -q "Warning: assuming.*--matching" stderr.txt
'
+test_expect_code 129 'push command line options (4)' '
+ git push --all --current testrepo
+'
+
+test_expect_code 129 'push command line options (5)' '
+ git push --matching --current testrepo
+'
+
+test_expect_code 129 'push command line options (6)' '
+ git push --current testrepo master
+'
+
test_expect_success 'push without wildcard' '
mk_empty &&
@@ -284,6 +296,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '
check_push_result $the_commit heads/local
'
+test_expect_success 'push with --current' '
+
+ mk_test heads/master &&
+ git checkout master &&
+ git push --current testrepo &&
+ check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'push with --current nonexisting at remote' '
+
+ mk_test heads/master &&
+ git checkout local &&
+ git push --current testrepo &&
+ check_push_result $the_commit heads/local
+'
+
test_expect_success 'push with dry-run' '
mk_test heads/master &&
--
1.5.3.5.743.g87c5c
^ permalink raw reply related
* [PATCH] builtin-commit: Fix git-commit honoring status.color
From: Ping Yin @ 2007-11-18 17:10 UTC (permalink / raw)
To: git; +Cc: Ping Yin
status.color shouldn't be honored when committing since the run-status
output is fed to the editor.
---
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 8db74ed..4396e7d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -45,6 +45,7 @@ static int quiet, verbose, untracked_files, no_verify;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
struct strbuf message;
+extern int wt_status_use_color;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
@@ -325,6 +326,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
+ wt_status_use_color = 0;
commitable = run_status(fp, index_file, prefix);
fclose(fp);
--
1.5.3.5.1876.g7ba19-dirty
^ permalink raw reply related
* [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-18 17:36 UTC (permalink / raw)
To: git; +Cc: Ping Yin
When 'FILE *fp' is assigned to child_process.out and then start_command or
run_command is run, the standard output of the child process is expected to
be outputed to fp. However, sometimes fp is not expected to be closed since
further IO may be still performmed on fp.
---
run-command.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/run-command.c
index 476d00c..4e5f58d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
if (need_in)
close(fdin[0]);
- else if (cmd->in)
- close(cmd->in);
if (need_out)
close(fdout[1]);
- else if (cmd->out > 1)
- close(cmd->out);
if (need_err)
close(fderr[1]);
--
1.5.3.5.1876.g7ba19-dirty
^ permalink raw reply related
* Re: [RFH] Solaris portability
From: Junio C Hamano @ 2007-11-18 17:46 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git, Shawn O Pearce, Jason Riedy, Dennis Stosberg
In-Reply-To: <Pine.LNX.4.64.0711181302360.3945@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
> On Fri, 16 Nov 2007, Junio C Hamano wrote:
>> This makes me wonder if treating it just like strcasestr() might be
>> simpler. Could folks with access to Solaris boxes of different
>> vintages please see if the attached patch makes sense?
>
> I think the patch makes sense as neither Solaris 8, 9 nor 10 supports
> mkdtemp().
>
>> Can we also unify UNSETENV, SETENV, C99_FORMAT and STRTOUMAX, by the
>> way?
>
> No.
>
> I've just checked on our Solaris Sparc systems, and found that the
> C-library provides unsetenv(), setenv() and strtoumax() beginning with
> Solaris 10; also the 'man sprintf' page mentions the 'z' and 't'
> specifiers for printf (which is what is behind C99_FORMAT) only
> beginning with Solaris 10.
>
> So workarounds are needed for all 4 cases for Solaris 8 and 9 but not 10.
Thank you very much for detailed information.
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Junio C Hamano @ 2007-11-18 18:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> What's causing this? I'm using stgit on the master branch.
> I'm fixing it each time on the remote server by deleting the ref to master.
>
> jonsmirl@terra:~/ds$ git push digispeaker
> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> ! [rejected] master -> master (non-fast forward)
> error: failed to push to
> 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> jonsmirl@terra:~/ds$
A "non-fast forward" means that you had this history earlier:
o---o---A
/
---o
pushed "A" to the remote's 'master', then built this history:
o---o---A
/
---o---o---o---o---A'
by rewinding and rebuilding, and the tip of the branch now
points at A', which you tried to push to the remote.
Which often causes troubles for people who are fetching from the
branch you are pushing into, and forbidden by default as a
safety measure.
As long as the people who fetch from the branch knows that you
will regularly rewinding the tip of the branch, there is no
confusion, and you can "force" a non-fast forward update. There
are two independent safety mechanisms:
- the sending end safety can be overriden by "git push --force"
and/or by using a refspec prefixed with a '+');
- the receiving end safety can be overriden by the config
variable receive.denynonfastworwards of the repository you
are pushing into.
The latter defaults to "unsafe", but if the safety is activated
in the repository, forcing from the sending side will not
deactivate it. IOW, both ends need to agree to allow the unsafe
behaviour.
> On the server I have:
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = true
> logallrefupdates = true
>
> bare was set false, I just flipped it to true. The server repo was
> originally created via a clone from kernel.org and then renamed to be
> a bare repo. Why do we need a 'bare' attribute?
There are a few things that change behaviour depending on the
bareness of the repository. One example is that "git fetch"
that updates to the current branch (i.e. what HEAD points at) by
having it as the RHS of a refspec is accepted only for bare
repositories (for non-bare repositories such a fetch would make
the HEAD and the work tree go out-of-sync).
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Alex Riesen @ 2007-11-18 18:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com>
Jon Smirl, Sun, Nov 18, 2007 16:12:10 +0100:
> What's causing this? I'm using stgit on the master branch.
> I'm fixing it each time on the remote server by deleting the ref to master.
>
> jonsmirl@terra:~/ds$ git push digispeaker
> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> ! [rejected] master -> master (non-fast forward)
> error: failed to push to
the branch you are pushing does not fast-forward to the one on
digispeaker. IOW, the master on digispeaker has changed since you made
changes on your local master.
^ permalink raw reply
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Junio C Hamano @ 2007-11-18 18:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711181225.52288.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Then the strategy of garbage collection can be arranged in the following way:
>
> - Repack by starting at the "most complete" repo and work towards the "most
> borrowing" ones. During this phase "attic" packs are created. Borrowing repos
> get a chance to salvage objects before the alternates prune them away.
>
> - Prune by starting at the "most borrowing" repo and work towards the "most
> complete" ones. During this phase the "attic" packs are cleaned up.
>
> What do you think? Is this a way for a solution?
I would imagine that would work as long as it can be controlled
when all the involved repositories are repacked and pruned, such
as on repo.or.cz case (but on the other hand it is not really
controlled well there and that is the reason you wrote the
message X-<).
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Jon Smirl @ 2007-11-18 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7ikfwhkj.fsf@gitster.siamese.dyndns.org>
On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > What's causing this? I'm using stgit on the master branch.
> > I'm fixing it each time on the remote server by deleting the ref to master.
> >
> > jonsmirl@terra:~/ds$ git push digispeaker
> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> > ! [rejected] master -> master (non-fast forward)
> > error: failed to push to
> > 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> > jonsmirl@terra:~/ds$
>
> A "non-fast forward" means that you had this history earlier:
>
> o---o---A
> /
> ---o
>
> pushed "A" to the remote's 'master', then built this history:
>
> o---o---A
> /
> ---o---o---o---o---A'
>
> by rewinding and rebuilding, and the tip of the branch now
> points at A', which you tried to push to the remote.
stgit must be doing this when I rebase. It pops all of it's patches,
moves to head of linus/master and then rebases them.
I'm the only person with write access to the repo.
> Which often causes troubles for people who are fetching from the
> branch you are pushing into, and forbidden by default as a
> safety measure.
What is the right way to share repositories using stgit? I have a set
of patches which I am working on for kernel inclusion. I have them
applied as a stgit stack on top of linus/master. I need to share this
patch stack with other developers. These developers may want to change
one of my patches. Right now they are emailing me deltas and I apply
them to the appropriate stgit patch. I have seventeen patches in my
stack currently.
I am starting to see why several people have made comments about
integrating stgit into git. When other developers clone my repo the
stgit setup doesn't come with it. It would be great it we could use
git to push the stgit patches around and work on them.
> As long as the people who fetch from the branch knows that you
> will regularly rewinding the tip of the branch, there is no
> confusion, and you can "force" a non-fast forward update. There
> are two independent safety mechanisms:
>
> - the sending end safety can be overriden by "git push --force"
> and/or by using a refspec prefixed with a '+');
>
> - the receiving end safety can be overriden by the config
> variable receive.denynonfastworwards of the repository you
> are pushing into.
>
> The latter defaults to "unsafe", but if the safety is activated
> in the repository, forcing from the sending side will not
> deactivate it. IOW, both ends need to agree to allow the unsafe
> behaviour.
>
> > On the server I have:
> > [core]
> > repositoryformatversion = 0
> > filemode = true
> > bare = true
> > logallrefupdates = true
> >
> > bare was set false, I just flipped it to true. The server repo was
> > originally created via a clone from kernel.org and then renamed to be
> > a bare repo. Why do we need a 'bare' attribute?
>
> There are a few things that change behaviour depending on the
> bareness of the repository. One example is that "git fetch"
> that updates to the current branch (i.e. what HEAD points at) by
> having it as the RHS of a refspec is accepted only for bare
> repositories (for non-bare repositories such a fetch would make
> the HEAD and the work tree go out-of-sync).
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix partial-commit support
From: Junio C Hamano @ 2007-11-18 18:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6inx1m8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 3e7d281..e487bc0 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
There was another...
> +static int list_paths(struct path_list *list, const char *with_tree,
> + const char *prefix, const char **pattern)
> +{
> + struct dir_struct dir;
> + int i;
> + char *m;
> +
> + for (i = 0; pattern[i]; i++)
> + ;
> + m = xcalloc(1, i);
> +
> + memset(&dir, 0, sizeof(dir));
> + if (with_tree)
> + overlay_tree_on_cache(with_tree, prefix);
> +
> + for (i = 0; i < active_nr; i++) {
> + struct cache_entry *ce = active_cache[i];
> + if (ce->ce_flags & htons(CE_UPDATE))
> + continue;
> + if (!pathspec_match(pattern, m, ce->name, 0))
> + continue;
> + if (excluded(&dir, ce->name))
> + continue;
> + path_list_insert(ce->name, list);
> + }
This "excluded", and the whole "struct dir" business is
unneeded, as we are walking on the index and finding the set of
paths the user cares about.
^ permalink raw reply
* Re: preserving mtime
From: David Brown @ 2007-11-18 18:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike Hommey, Wayne Davison, Andreas Ericsson, git
In-Reply-To: <46a038f90711180134j411bb9c9uf2476f564f9abb6@mail.gmail.com>
On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:
>I do hope anyone doing those things is _very_ aware that the mtime
>metadata has a specific meaning -- when did this specific file in this
>filesystem last change -- and is used by many tools in that sense. You
>are trying to use it for something else. Lots of things will break.
>
>Like incremental backups, for example.
'mtime' does _not_ have the specific meaning of 'when did this specific
file last change'. That is the 'ctime' field. 'mtime' is also updated
when a file is modified, but can be changed by the user. Many utilities
restore mtime to older values, including tar.
Any competent backup program would use 'ctime' for incremental backups,
unless they don't mind missing a vast majority of files on many machines.
The main thing I've seen mess up backup software is if the mtime is set
into the future.
However, it will make 'make' very confusing, since it uses the mtime to
determine if files are out of date. If moving to an older version of a
file causes the file to become older, make won't recompile. This is
arguably a defect in make, but that is how it works.
Preserving mtime definitely should not be a default.
David
^ permalink raw reply
* Re: only accessing some git repos: Am I configuring daemon wrong?
From: Junio C Hamano @ 2007-11-18 18:48 UTC (permalink / raw)
To: Henrik Vendelbo; +Cc: git
In-Reply-To: <9732aadb0711180518n26c2681aqe7f0a823012c6fe3@mail.gmail.com>
"Henrik Vendelbo" <hvendelbo.dev@googlemail.com> writes:
> I run the daemon against a base directory with all my repos.
>
> /repositories
> + /blingon
> + /config
> + /thepia
> + /config
>
> The config directories are git repositories, and the repos are made
> available with the following command:
>
> henrik-computer:~ x$ git daemon --export-all --verbose --base-path=/repositories
> [337] Connection from 192.168.9.130:56583
> [337] Extended attributes (20 bytes) exist <host=192.168.9.165>
> [337] Request upload-pack for '/blingon/all'
> [337] Disconnected
>
> For some reason when I try to pull over the git protocol to a
> different machine using clone, I get a failure telling me that there
> is 'no matching remote head'
>
> I tried specifying the actual repo directories, but that made no difference.
>
> Any ideas?
Lack of any whitelist on the command line and --export-all?
Do you see "not in whitelist" in your error log?
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Junio C Hamano @ 2007-11-18 18:52 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195407366-1610-1-git-send-email-pkufranky@gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> When 'FILE *fp' is assigned to child_process.out and then start_command or
> run_command is run, the standard output of the child process is expected to
> be outputed to fp. However, sometimes fp is not expected to be closed since
> further IO may be still performmed on fp.
Could you clarify "However, sometimes" with a concrete codepath
that has this problem in the proposed commit log message, and
Sign-off your patch please?
^ permalink raw reply
* Re: [PATCH] builtin-commit: Fix git-commit honoring status.color
From: Junio C Hamano @ 2007-11-18 19:55 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195405834-1469-1-git-send-email-pkufranky@gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> status.color shouldn't be honored when committing since the run-status
> output is fed to the editor.
> ---
> builtin-commit.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 8db74ed..4396e7d 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -45,6 +45,7 @@ static int quiet, verbose, untracked_files, no_verify;
> static int no_edit, initial_commit, in_merge;
> const char *only_include_assumed;
> struct strbuf message;
> +extern int wt_status_use_color;
>
> static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> {
> @@ -325,6 +326,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
> if (only_include_assumed)
> fprintf(fp, "# %s\n", only_include_assumed);
>
> + wt_status_use_color = 0;
> commitable = run_status(fp, index_file, prefix);
>
> fclose(fp);
Although I admit I do not care much about the "status color", I
suspect this patch is not quite right.
When prepare_log_message() returns "no committable changes" and
we are not in merge, the calling cmd_commit() does another
run_status() to show the status of the index and the work tree
to the stdout, and at that point, we _do_ want to honor the
configuration setting you are discarding with this assignment.
---
builtin-commit.c | 5 ++++-
wt-status.h | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 4e2f4aa..058cd32 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -300,7 +300,7 @@ static const char sign_off_header[] = "Signed-off-by: ";
static int prepare_log_message(const char *index_file, const char *prefix)
{
struct stat statbuf;
- int commitable;
+ int commitable, saved_color_setting;
struct strbuf sb;
char *buffer;
FILE *fp;
@@ -383,7 +383,10 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
+ saved_color_setting = wt_status_use_color;
+ wt_status_use_color = 0;
commitable = run_status(fp, index_file, prefix);
+ wt_status_use_color = saved_color_setting;
fclose(fp);
diff --git a/wt-status.h b/wt-status.h
index f58ebcb..225fb4d 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -27,6 +27,7 @@ struct wt_status {
};
int git_status_config(const char *var, const char *value);
+int wt_status_use_color;
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
^ permalink raw reply related
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Johannes Sixt @ 2007-11-18 20:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3av3wg7h.fsf@gitster.siamese.dyndns.org>
On Sunday 18 November 2007 19:39, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > Then the strategy of garbage collection can be arranged in the following
> > way:
> >
> > - Repack by starting at the "most complete" repo and work towards the
> > "most borrowing" ones. During this phase "attic" packs are created.
> > Borrowing repos get a chance to salvage objects before the alternates
> > prune them away.
> >
> > - Prune by starting at the "most borrowing" repo and work towards the
> > "most complete" ones. During this phase the "attic" packs are cleaned up.
> >
> > What do you think? Is this a way for a solution?
>
> I would imagine that would work as long as it can be controlled
> when all the involved repositories are repacked and pruned, such
> as on repo.or.cz case (but on the other hand it is not really
> controlled well there and that is the reason you wrote the
> message X-<).
Well, I think in many situations pack and prune can be controlled. To be
precise, if alternates are used pack and prune *must* be controlled.
Currently, the control is very simple: "don't prune" (and I don't recall ATM
what you must not do when you repack).
Anyway, judging from the responses so far it seems that people can live
with "don't prune" (or not using alternates) ;-) Repositories getting broken
this way isn't exactly my itch, either, so... I spelled out a possible
solution if someone wants to pick up the topic.
-- Hannes
^ permalink raw reply
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Junio C Hamano @ 2007-11-18 20:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711182101.53936.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sunday 18 November 2007 19:39, Junio C Hamano wrote:
> ...
>> I would imagine that would work as long as it can be controlled
>> when all the involved repositories are repacked and pruned, such
>> as on repo.or.cz case (but on the other hand it is not really
>> controlled well there and that is the reason you wrote the
>> message X-<).
>
> Well, I think in many situations pack and prune can be controlled. To be
> precise, if alternates are used pack and prune *must* be controlled.
> Currently, the control is very simple: "don't prune" (and I don't recall ATM
> what you must not do when you repack).
>
> Anyway, judging from the responses so far it seems that people can live
> with "don't prune" (or not using alternates) ;-)
Because my point was not "don't prune is good enough", I think
you are judging from too small number of responses (in fact,
zero).
My point was that even the existing setup that is well known to
the public (i.e. repo.or.cz) does not seem to be controlled, and
adding a nicer mechanism (e.g. I do not think there currently is
a canned way to prepare a pack that contains only unreachable
objects --- you need to script it anew) for a better control may
not help the situation much, unless it is actually used.
^ permalink raw reply
* [PATCH] builtin-commit: run commit-msg hook with correct message file
From: Junio C Hamano @ 2007-11-18 20:30 UTC (permalink / raw)
To: git; +Cc: krh, Johannes.Schindelin
In-Reply-To: <7vejenuy4i.fsf@gitster.siamese.dyndns.org>
It should run with $GIT_DIR/COMMIT_EDITMSG, not just COMMIT_EDITMSG.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Other things I noticed that are still broken:
- "git commit -v" does not give you the diff in the message
template for your final review;
- message_is_empty() is bogus. It does run stripspace() but
does not strip out the diff "git commit -v" would produce
before doing its comparison;
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 058cd32..439fcc2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -753,7 +753,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
rollback_index_files();
die("could not read commit message\n");
}
- if (run_hook(index_file, "commit-msg", commit_editmsg)) {
+ if (run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
rollback_index_files();
exit(1);
}
--
1.5.3.5.1815.g9445b
^ permalink raw reply related
* Re: preserving mtime
From: Martin Langhoff @ 2007-11-18 20:36 UTC (permalink / raw)
To: Martin Langhoff, Mike Hommey, Wayne Davison, Andreas Ericsson,
git
In-Reply-To: <20071118184724.GA494@old.davidb.org>
On Nov 19, 2007 7:47 AM, David Brown <git@davidb.org> wrote:
> On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:
>
> >I do hope anyone doing those things is _very_ aware that the mtime
> >metadata has a specific meaning -- when did this specific file in this
> >filesystem last change -- and is used by many tools in that sense. You
> >are trying to use it for something else. Lots of things will break.
> >
> >Like incremental backups, for example.
>
> 'mtime' does _not_ have the specific meaning of 'when did this specific
> file last change'. That is the 'ctime' field. 'mtime' is also updated
> when a file is modified, but can be changed by the user. Many utilities
> restore mtime to older values, including tar.
Hmmm. After a bit of googling I've found conflicting descriptions of
the mtime/ctime semantics (I thought - for 10 years now - that ctime
was "creation time", it is "changed time"). Some people think that
anything that updates mtime also updates ctime, and others say the
opposite.
Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and
http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the
content, and ctime about metadata (owner, permissions, moved inode,
etc). Changes in content "touch" mtime + ctime.
With that in mind, I think it makes sense for things like make and
amanda to read mtime as referring to a real change of that concrete
file. The abstract notion of the file having changed in the big DSCM
in the sky is useful, but putting that data in mtime messes things up.
> However, it will make 'make' very confusing, since it uses the mtime to
> determine if files are out of date. If moving to an older version of a
> file causes the file to become older, make won't recompile. This is
> arguably a defect in make, but that is how it works.
It's not a bug in make. mtime has a definite meaning, and make is
using that meaning. Same with amanda.
cheers,
m
^ permalink raw reply
* Re: preserving mtime
From: David Brown @ 2007-11-18 21:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike Hommey, Wayne Davison, Andreas Ericsson, git
In-Reply-To: <46a038f90711181236o1acd00d4id9c5aeffd3065b80@mail.gmail.com>
On Mon, Nov 19, 2007 at 09:36:52AM +1300, Martin Langhoff wrote:
>Hmmm. After a bit of googling I've found conflicting descriptions of
>the mtime/ctime semantics (I thought - for 10 years now - that ctime
>was "creation time", it is "changed time"). Some people think that
>anything that updates mtime also updates ctime, and others say the
>opposite.
One of them is wrong. All modifications to the file change the ctime.
Some modifications change the mtime. There is also a call to change the
mtime (which will touch the ctime). It's been this way for a long time.
I think most of the confusion comes from the 'c' in ctime.
It doesn't help that the Posix spec is so hard to read on this. Basically,
you have to look up every command that might modify a file to figure out
which time changes it is supposed to modify.
>Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and
>http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the
>content, and ctime about metadata (owner, permissions, moved inode,
>etc). Changes in content "touch" mtime + ctime.
>
>With that in mind, I think it makes sense for things like make and
>amanda to read mtime as referring to a real change of that concrete
>file. The abstract notion of the file having changed in the big DSCM
>in the sky is useful, but putting that data in mtime messes things up.
Backup software should _never_ look at the mtime (other than to save it).
Both GNU tar and dump use the ctime field exclusively for incremental
purposes.
Think about this:
wget .../linux-2.4.tar.gz
tar -xzf linux-2.4.tar.gz
I've just expanded lots of files on my machine. Tar is going to set the
mtime to the date they were at when the tarball was made, which was
probably several years ago. It is crucial, though, that any backup
software I run still back these files up, since they are newly added.
There are backup programs that use mtime, but they are just broken, plain
and simple.
>> However, it will make 'make' very confusing, since it uses the mtime to
>> determine if files are out of date. If moving to an older version of a
>> file causes the file to become older, make won't recompile. This is
>> arguably a defect in make, but that is how it works.
>
>It's not a bug in make. mtime has a definite meaning, and make is
>using that meaning. Same with amanda.
It is very much a bug (well, a feature) in make. But the whole date
comparison model of make is completely wrong. It should rebuild a file if
it has changed, not if it is newer. Most make replacements do something
more intelligent (often similar to the index cache git uses).
I haven't used Amanda for a while, but it at least used to do the right
thing (using ctime). They might have had to break things to support FAT,
but I would guess it still works on a real filesystem.
David
^ permalink raw reply
* StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Jakub Narebski @ 2007-11-18 23:05 UTC (permalink / raw)
To: Catalin Marinas, git
I use Stacked GIT 0.13 with git 1.5.3.5 (and Python 2.4.3).
StGIT does recognize old StGIT branches (and converts them),
but "stg branch -l" list only one branch. I guess that is
cause by the fact that all the rest of branches are packed.
So the question is: how to unpack branches, and how to prevent
branches from being packed by "git-gc"?
Another StGIT question: how to check if given branch is controlled
by StGIT (needed for my bash prompt)?
--
Jakub Narebski
Poland
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.6
From: Junio C Hamano @ 2007-11-18 23:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vpryugb7i.fsf@gitster.siamese.dyndns.org>
The latest maintenance release GIT 1.5.3.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.6.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.6.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.6-1.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.5.3.6 Release Notes
==========================
Fixes since v1.5.3.5
--------------------
* git-cvsexportcommit handles root commits better.
* git-svn dcommit used to clobber when sending a series of
patches.
* git-svn dcommit failed after attempting to rebase when
started with a dirty index; now it stops upfront.
* git-grep sometimes refused to work when your index was
unmerged.
* "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
* git-hash-object did not honor configuration variables, such as
core.compression.
* git-index-pack choked on a huge pack on 32-bit machines, even when
large file offsets are supported.
* atom feeds from git-web said "10" for the month of November.
* a memory leak in commit walker was plugged.
* When git-send-email inserted the original author's From:
address in body, it did not mark the message with
Content-type: as needed.
* git-revert and git-cherry-pick incorrectly refused to start
when the work tree was dirty.
* git-clean did not honor core.excludesfile configuration.
* git-add mishandled ".gitignore" files when applying them to
subdirectories.
* While importing a too branchy history, git-fastimport did not
honor delta depth limit properly.
* Support for zlib implementations that lack ZLIB_VERNUM and definition
of deflateBound() has been added.
* Quite a lot of documentation clarifications.
----------------------------------------------------------------
Changes since v1.5.3.5 are as follows:
Alex Riesen (1):
stop t1400 hiding errors in tests
Ask Bjørn Hansen (1):
When exec() fails include the failing command in the error message
Benoit Sigoure (2):
git-send-email: Change the prompt for the subject of the initial message.
git-svn: prevent dcommitting if the index is dirty.
Brad King (1):
cvsexportcommit: fix for commits that do not have parents
Christian Couder (1):
for-each-ref: fix off by one read.
David D Kilzer (2):
RelNotes-1.5.3.5: fix typo
RelNotes-1.5.3.5: fix another typo
David Symonds (1):
Improve accuracy of check for presence of deflateBound.
Eric Wong (2):
git-svn: fix dcommit clobbering when committing a series of diffs
git-svn: t9114: verify merge commit message in test
Gerrit Pape (4):
git-diff.txt: add section "output format" describing the diff formats
git-cvsimport: really convert underscores in branch names to dots with -u
git-daemon: fix remote port number in log entry
git-mailsplit: with maildirs not only process cur/, but also new/
Jakub Narebski (1):
gitweb: Update config file example for snapshot feature in gitweb/INSTALL
Jeff King (2):
git-branch: remove mention of non-existent '-b' option
git-send-email: add charset header if we add encoded 'From'
Jing Xue (1):
replace reference to git-rm with git-reset in git-commit doc
Johannes Schindelin (1):
Add Documentation/CodingGuidelines
Jonas Fonseca (3):
Remove escaping of '|' in manpage option sections
instaweb: Minor cleanups and fixes for potential problems
Documentation: Fix man page breakage with DocBook XSL v1.72
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Junio C Hamano (12):
grep with unmerged index
refresh_index_quietly(): express "optional" nature of index writing better
Makefile: add missing dependency on wt-status.h
Start preparing for 1.5.3.6
t/t3404: fix test for a bogus todo file.
revert/cherry-pick: allow starting from dirty work tree.
git-clean: honor core.excludesfile
core.excludesfile clean-up
Fix per-directory exclude handing for "git add"
Update draft release notes for 1.5.3.6
grep -An -Bm: fix invocation of external grep command
GIT 1.5.3.6
Kristian Høgsberg (1):
Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.
Marco Costalba (1):
Remove a couple of duplicated include
Mike Hommey (1):
Delay pager setup in git blame
Nicolas Pitre (3):
print warning/error/fatal messages in one shot
git-hash-object should honor config variables
fix index-pack with packs >4GB containing deltas on 32-bit machines
Ralf Wildenhues (3):
git-clone.txt: Improve --depth description.
Avoid a few unportable, needlessly nested "...`...".
Fix sed string regex escaping in module_name.
Sergei Organov (6):
git-filter-branch.txt: fix a typo.
git-format-patch.txt: fix explanation of an example.
Documentation: quote commit messages consistently.
SubmittingPatches: improve the 'Patch:' section of the checklist
core-tutorial.txt: Fix argument mistake in an example.
git-remote.txt: fix typo
Shawn O. Pearce (2):
Fix memory leak in traverse_commit_list
Don't allow fast-import tree delta chains to exceed maximum depth
Vincent Zanotti (1):
gitweb: correct month in date display for atom feeds
Wincent Colaiuta (2):
Grammar fixes for gitattributes documentation
Fix t9101 test failure caused by Subversion "auto-props"
^ permalink raw reply
* Re: [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..."
From: J. Bruce Fields @ 2007-11-18 23:18 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Benoit Sigoure, Andreas Ericsson, Johannes Sixt,
git
In-Reply-To: <C5A2CF54-7055-461A-86B6-5A68489DA2C3@zib.de>
On Sun, Nov 18, 2007 at 10:47:24AM +0100, Steffen Prohaska wrote:
>
> On Nov 18, 2007, at 4:59 AM, J. Bruce Fields wrote:
>
>> On Sat, Nov 10, 2007 at 02:49:54PM +0100, Steffen Prohaska wrote:
>>> +[[bisect-merges]]
>>> +Why bisecting merge commits can be harder than bisecting linear history
>>> +-----------------------------------------------------------------------
>>> +
>>> +This section discusses how gitlink:git-bisect[1] plays
>>> +with differently shaped histories. The text is based upon
>>> +an email by Junio C. Hamano to the git mailing list
>>> +(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
>>> +It was adapted for the user manual.
>>
>> This is not the only text that's been taken from someplace else, but if
>> we attributed them all in the text it would get a little cumbersome....
>> I think the place for that kind of thing is in the commit message, but
>> if we really think we need to include it in the main text, we could add
>> a separate "'acknowledgements" section.
>
> ack for this change.
>
> And a general comment: I had two purposes in\x05 mind when I
> added this paragraph
> 1) Attribution;
> 2) Giving a reference to the original discussion. If someone disagrees,
> or has further questions, the original discussion on the mailing
> list could be useful.
>
> I believe the commit message is sufficient for attribution.
> I don't think we need more. Maybe if the manual goes to print
> we need to reconsider. But who know if this ever will happen.
>
> However, adding a References section with links to other
> resources could be a useful thing. Such resources could give
> additional information, without sacrificing the conciseness of
> the manual. An example are links to the original discussion on
> the list. Often they contain more details, which may sometimes
> be useful.
>
> Does asciidoc provide a mechanism for this? Something like
> \cite{} in LaTeX.
We could add a "for more details, see link:..." at the end, though I
don't think it's necessary in this case.
>>> +Using gitlink:git-bisect[1] on a history with merges can be
>>> +challenging. Bisecting through merges is not a technical
>>> +problem. The real problem is what to do when the culprit turns
>>> +out to be a merge commit. How to spot what really is wrong, and
>>> +figure out how to fix it. The problem is not for the tool but
>>> +for the human, and it is real.
>>
>> I think we can pare that down a little.
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +The gitlink:git-bisect[1] commands deals fine with history that includes
> +merge commits. However, when the final commit that ends on is a merge
> +commit, the user may need to work harder than usual to figure out
> +exactly what the problem was.
>
> If you don't take the text below, first line: s/commands/command/
Whoops, thanks!
>
> I'd reverse the order of the sentences. The section is about
> the difficulty, not about praising git-bisect. How about
>
> When the final commit that a bisect ends on is a merge commit,
> the user may need to work harder than usual to figure out
> exactly what the problem was. This is not a technical
> problem. In principle, the gitlink:git-bisect[1] command
> deals fine with history that includes merge commits.
>
> It's your call. I'm also fine with your version.
OK; I see your point but I think I'll stick with my version (with
another minor fix or two)--the order seems more natural: first dismiss
the obvious objection to the title, then introduce the problem that
leads to the following discussion.
>>> +
>>> +Imagine this history:
>>> +
>>> +................................................
>>> + ---Z---o---X---...---o---A---C---D
>>> + \ /
>>> + o---o---Y---...---o---B
>>> +................................................
>>> +
>>> +Suppose that on the upper development line, the meaning of one
>>> +of the functions that existed at Z was changed at commit X. The
>>> +commits from Z leading to A change both the function's
>>> +implementation and all calling sites that existed at Z, as well
>>> +as new calling sites they add, to be consistent. There is no
>>> +bug at A.
>>> +
>>> +Suppose that in the meantime the lower development line somebody
>>> +added a new calling site for that function at commit Y. The
>>> +commits from Z leading to B all assume the old semantics of that
>>> +function and the callers and the callee are consistent with each
>>> +other. There is no bug at B, either.
>>> +
>>> +Suppose further that the two development lines were merged at C
>>> +and there was no textual conflict with this three way merge.
>>> +The result merged cleanly.
>>> +
>>> +Now, during bisect you find that the merge C is broken. You
>>> +started to bisect, because you found D is bad and you know Z was
>>> +good. The breakage is understandable, as at C, the new calling
>>> +site of the function added by the lower branch is not converted
>>> +to the new semantics, while all the other calling sites that
>>> +already existed at Z would have been converted by the merge. The
>>> +new calling site has semantic adjustment needed, but you do not
>>> +know that yet.
>>> +
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +Nevertheless, the code at C is broken, because the callers added
> +on the lower line of development have not been converted to the new
> +semantics introduced on the upper line of development. So if all
> +you know is that D was bad, Z was good, and that a
>
> s/a//? I'm not sure; you are the native speaker ;)
I agree, it's better without the "a", thanks.
>
> +gitlink:git-bisect[1] identified C as the culprit, how will you
> +figure out that the problem was due to this change in semantics?
>
>
>
>>> +You need to find out what is the cause of the breakage by looking
>>> +at the merge commit C and the history leading to it. How would
>>> +you do that?
>>> +
>>> +Both "git diff A C" and "git diff B C" would be an enormous patch.
>>> +Each of them essentially shows the whole change on each branch
>>> +since they diverged. The developers may have well behaved to
>>> +create good commits that follow the "commit small, commit often,
>>> +commit well contained units" mantra, and each individual commit
>>> +leading from Z to A and from Z to B may be easy to review and
>>> +understand, but looking at these small and easily reviewable
>>> +steps alone would not let you spot the breakage. You need to
>>> +have a global picture of what the upper branch did (and
>>> +among many, one of them is to change the semantics of that
>>> +particular function) and look first at the huge "diff A C"
>>> +(which shows the change the lower branch introduces), and see if
>>> +that huge change is consistent with what have been done between
>>> +Z and A.
>>> +
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +When the result of a git-bisect is a non-merge commit, you should
> +normally be able to discover the problem be examining just that commit.
>
> s/be examining/by examining/
Oops, thanks.
>> I'd say "partly for this reason", as I don't think this is the only
>> reason people do that.
>>
>> I've done the above revisions and a few others and pushed them to
>>
>> git://linux-nfs.org/~bfields/git.git maint
>>
>> I'll take another look in the morning.
>
> Besides the minor fixes above, ack from me. We already spend
> a lot of time on this section. It improved compared to the
> first version and I think it's now ready for the manual.
OK, thanks for your patience! This plus an unrelated trivial fix are
available for Junio to pull from
git://linux-nfs.org/~bfields/git.git maint
(Full history also available from the maint-history branch).
--b.
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Junio C Hamano @ 2007-11-19 0:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, git
In-Reply-To: <200711190005.49990.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> So the question is: how to unpack branches, and how to prevent
> branches from being packed by "git-gc"?
I am afraid that is a wrong question. How long have we had the
packed-refs anyway?
The question is "How to get the list of refs from a Porcelain if
it wants to be compatible with GIT v1.4.4-rc1 (Nov 7, 2006) and
later?", and the answer is for-each-ref.
Having said that, you could explode it by hand like this:
git for-each-ref --format='%(objectname) %(refname)' refs/heads |
while read sha1 refname
do
test -f "$GIT_DIR/$refname" ||
git update-ref "$refname" "$sha1"
done
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: J. Bruce Fields @ 2007-11-19 0:48 UTC (permalink / raw)
To: Michael Smith; +Cc: git, gitster
In-Reply-To: <11949569992214-git-send-email-msmith@cbnco.com>
On Tue, Nov 13, 2007 at 07:29:59AM -0500, Michael Smith wrote:
> +You can view all your local changes--b, d, h, and i--with the
> +gitlink:git-diff[1] command:
> +
> +------------------------------------------
> +$ git diff origin/master...master
> +------------------------------------------
> +
> +The three-dot `\...` tells gitlink:git-diff[1] to show the changes on the
> +master branch since the last common ancestor with origin/master. (If you
> +used two dots instead of three, you'd see the entire patch to go from
> +origin/master to master, including reversing commits "f" and "g".)
I missed the "..." thing when on my first attempt at the manual. It
really should be mentioned in the "Generating diffs" section; I've added
the following to my
git://linux-nfs.org/~bfields/git.git maint
--b.
>From 5b98d9bca16e19710380d2d03f704de9eb98621d Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 18 Nov 2007 19:18:27 -0500
Subject: [PATCH] user-manual: mention "..." in "Generating diffs", etc.
We should mention the use of the "..." syntax for git-diff here. The
note about the difference between diff and the combined output of
git-format-patch then no longer fits so well, so remove it. Add a
reference to the git-format-patch[1] manpage.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e399685..c027353 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -658,16 +658,23 @@ gitlink:git-diff[1]:
$ git diff master..test
-------------------------------------------------
-Sometimes what you want instead is a set of patches:
+That will produce the diff between the tips of the two branches. If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+-------------------------------------------------
+$ git diff master...test
+-------------------------------------------------
+
+Sometimes what you want instead is a set of patches; for this you can
+use gitlink:git-format-patch[1]:
-------------------------------------------------
$ git format-patch master..test
-------------------------------------------------
will generate a file with a patch for each commit reachable from test
-but not from master. Note that if master also has commits which are
-not reachable from test, then the combined result of these patches
-will not be the same as the diff produced by the git-diff example.
+but not from master.
[[viewing-old-file-versions]]
Viewing old file versions
--
1.5.3.5.561.g140d
^ 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