* Re: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Eric Raible @ 2011-09-27 20:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Witten, Michael J Gruber, Carlos Martín Nieto,
vra5107, git
In-Reply-To: <7v39fhyk21.fsf@alter.siamese.dyndns.org>
On 11:59 AM, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> It seems like a more logical approach would be instead for "git
>> commit" to take a "--root" option that would create a new root commit
>> based on the current index and then point the current branch head to
>> the new root commit. Thus:
>>
>> $ git checkout -b new_branch old_branch
>> $ # Manipulate or not
>> $ git commit --root
>>
>> That's how people think.
Not this person.
I like the idea but I'd rather see:
git commit --no-parent
"parent" at least appears in gitk and therefore newcomers will prob
have a better chance of understanding the intent w/out needing to
otherwise unnecessary terminology.
^ permalink raw reply
* [PATCH] add --progress to git-gc and git-repack
From: Oleg Andreev @ 2011-09-27 20:32 UTC (permalink / raw)
To: git, gitster
[-- Attachment #1: Type: text/plain, Size: 6019 bytes --]
Hello,
Here are two patches adding --progress option to git-gc and git-repack.
You can also pull them from here: git://github.com/oleganza/git.git
Just in case, if some spaces get corrupted, you can find the patches in the attachment.
From 1f261e13e72770deabd77087e354f304be850efc Mon Sep 17 00:00:00 2001
From: Oleg Andreev <oleganza@gmail.com>
Date: Tue, 27 Sep 2011 08:24:25 +0200
Subject: [PATCH 1/2] git-repack: pass --progress down to git-pack-objects
---
Documentation/git-repack.txt | 4 ++++
git-repack.sh | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 40af321..1c22076 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -74,6 +74,10 @@ other objects in that pack they already have locally.
Pass the `-q` option to 'git pack-objects'. See
linkgit:git-pack-objects[1].
+--progress::
+ Pass the `--progress` option to 'git pack-objects'. See
+ linkgit:git-pack-objects[1].
+
-n::
Do not update the server information with
'git update-server-info'. This option skips
diff --git a/git-repack.sh b/git-repack.sh
index 624feec..b86d60e 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -14,6 +14,7 @@ f pass --no-reuse-delta to git-pack-objects
F pass --no-reuse-object to git-pack-objects
n do not run git-update-server-info
q,quiet be quiet
+progress pass --progress to git-pack-objects
l pass --local to git-pack-objects
Packing constraints
window= size of the window used for delta compression
@@ -25,7 +26,7 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
no_update_info= all_into_one= remove_redundant= unpack_unreachable=
-local= no_reuse= extra=
+local= no_reuse= extra= progress=
while test $# != 0
do
case "$1" in
@@ -35,6 +36,7 @@ do
unpack_unreachable=--unpack-unreachable ;;
-d) remove_redundant=t ;;
-q) GIT_QUIET=t ;;
+ --progress) progress=--progress ;;
-f) no_reuse=--no-reuse-delta ;;
-F) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
@@ -85,7 +87,7 @@ esac
mkdir -p "$PACKDIR" || exit
args="$args $local ${GIT_QUIET:+-q} $no_reuse$extra"
-names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $progress $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
say Nothing new to pack.
--
1.7.6.1
From 01437ba2785a23221f246c37f6ba317274bfa6f4 Mon Sep 17 00:00:00 2001
From: Oleg Andreev <oleganza@gmail.com>
Date: Tue, 27 Sep 2011 08:38:20 +0200
Subject: [PATCH 2/2] git-gc: pass --progress down to git-repack
---
Documentation/git-gc.txt | 11 +++++++++--
builtin/gc.c | 7 ++++++-
contrib/examples/git-gc.sh | 6 +++++-
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 815afcb..b65fa3e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -9,7 +9,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
[verse]
-'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]
+'git gc' [--aggressive] [--auto] [--quiet] [--progress] [--prune=<date> | --no-prune]
DESCRIPTION
-----------
@@ -69,7 +69,14 @@ automatic consolidation of packs.
Do not prune any loose objects.
--quiet::
- Suppress all progress reports.
+ Suppress all progress reports. Progress is not reported to
+ the standard error stream.
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
Configuration
-------------
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..e146985 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -28,7 +28,7 @@ static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static const char *prune_expire = "2.weeks.ago";
-#define MAX_ADD 10
+#define MAX_ADD 11
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
@@ -177,10 +177,12 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
int aggressive = 0;
int auto_gc = 0;
int quiet = 0;
+ int progress = 0;
char buf[80];
struct option builtin_gc_options[] = {
OPT__QUIET(&quiet, "suppress progress reporting"),
+ OPT_BOOLEAN(0, "progress", &progress, "force progress reporting"),
{ OPTION_STRING, 0, "prune", &prune_expire, "date",
"prune unreferenced objects",
PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
@@ -213,6 +215,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (quiet)
append_option(argv_repack, "-q", MAX_ADD);
+ if (progress)
+ append_option(argv_repack, "--progress", MAX_ADD);
+
if (auto_gc) {
/*
* Auto-gc should be least intrusive as possible.
diff --git a/contrib/examples/git-gc.sh b/contrib/examples/git-gc.sh
index 1597e9f..52ea808 100755
--- a/contrib/examples/git-gc.sh
+++ b/contrib/examples/git-gc.sh
@@ -9,12 +9,16 @@ SUBDIRECTORY_OK=Yes
. git-sh-setup
no_prune=:
+progress=
while test $# != 0
do
case "$1" in
--prune)
no_prune=
;;
+ --progress)
+ progress=--progress
+ ;;
--)
usage
;;
@@ -32,6 +36,6 @@ esac
test "true" != "$pack_refs" ||
git pack-refs --prune &&
git reflog expire --all &&
-git-repack -a -d -l &&
+git-repack -a -d -l $progress &&
$no_prune git prune &&
git rerere gc || exit
--
1.7.6.1
[-- Attachment #2: 0001-git-repack-pass-progress-down-to-git-pack-objects.patch --]
[-- Type: application/octet-stream, Size: 2388 bytes --]
From 1f261e13e72770deabd77087e354f304be850efc Mon Sep 17 00:00:00 2001
From: Oleg Andreev <oleganza@gmail.com>
Date: Tue, 27 Sep 2011 08:24:25 +0200
Subject: [PATCH 1/2] git-repack: pass --progress down to git-pack-objects
---
Documentation/git-repack.txt | 4 ++++
git-repack.sh | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 40af321..1c22076 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -74,6 +74,10 @@ other objects in that pack they already have locally.
Pass the `-q` option to 'git pack-objects'. See
linkgit:git-pack-objects[1].
+--progress::
+ Pass the `--progress` option to 'git pack-objects'. See
+ linkgit:git-pack-objects[1].
+
-n::
Do not update the server information with
'git update-server-info'. This option skips
diff --git a/git-repack.sh b/git-repack.sh
index 624feec..b86d60e 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -14,6 +14,7 @@ f pass --no-reuse-delta to git-pack-objects
F pass --no-reuse-object to git-pack-objects
n do not run git-update-server-info
q,quiet be quiet
+progress pass --progress to git-pack-objects
l pass --local to git-pack-objects
Packing constraints
window= size of the window used for delta compression
@@ -25,7 +26,7 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
no_update_info= all_into_one= remove_redundant= unpack_unreachable=
-local= no_reuse= extra=
+local= no_reuse= extra= progress=
while test $# != 0
do
case "$1" in
@@ -35,6 +36,7 @@ do
unpack_unreachable=--unpack-unreachable ;;
-d) remove_redundant=t ;;
-q) GIT_QUIET=t ;;
+ --progress) progress=--progress ;;
-f) no_reuse=--no-reuse-delta ;;
-F) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
@@ -85,7 +87,7 @@ esac
mkdir -p "$PACKDIR" || exit
args="$args $local ${GIT_QUIET:+-q} $no_reuse$extra"
-names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $progress $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
say Nothing new to pack.
--
1.7.6.1
[-- Attachment #3: 0002-git-gc-pass-progress-down-to-git-repack.patch --]
[-- Type: application/octet-stream, Size: 3372 bytes --]
From 01437ba2785a23221f246c37f6ba317274bfa6f4 Mon Sep 17 00:00:00 2001
From: Oleg Andreev <oleganza@gmail.com>
Date: Tue, 27 Sep 2011 08:38:20 +0200
Subject: [PATCH 2/2] git-gc: pass --progress down to git-repack
---
Documentation/git-gc.txt | 11 +++++++++--
builtin/gc.c | 7 ++++++-
contrib/examples/git-gc.sh | 6 +++++-
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 815afcb..b65fa3e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -9,7 +9,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
[verse]
-'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]
+'git gc' [--aggressive] [--auto] [--quiet] [--progress] [--prune=<date> | --no-prune]
DESCRIPTION
-----------
@@ -69,7 +69,14 @@ automatic consolidation of packs.
Do not prune any loose objects.
--quiet::
- Suppress all progress reports.
+ Suppress all progress reports. Progress is not reported to
+ the standard error stream.
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
Configuration
-------------
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..e146985 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -28,7 +28,7 @@ static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static const char *prune_expire = "2.weeks.ago";
-#define MAX_ADD 10
+#define MAX_ADD 11
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
@@ -177,10 +177,12 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
int aggressive = 0;
int auto_gc = 0;
int quiet = 0;
+ int progress = 0;
char buf[80];
struct option builtin_gc_options[] = {
OPT__QUIET(&quiet, "suppress progress reporting"),
+ OPT_BOOLEAN(0, "progress", &progress, "force progress reporting"),
{ OPTION_STRING, 0, "prune", &prune_expire, "date",
"prune unreferenced objects",
PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
@@ -213,6 +215,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (quiet)
append_option(argv_repack, "-q", MAX_ADD);
+ if (progress)
+ append_option(argv_repack, "--progress", MAX_ADD);
+
if (auto_gc) {
/*
* Auto-gc should be least intrusive as possible.
diff --git a/contrib/examples/git-gc.sh b/contrib/examples/git-gc.sh
index 1597e9f..52ea808 100755
--- a/contrib/examples/git-gc.sh
+++ b/contrib/examples/git-gc.sh
@@ -9,12 +9,16 @@ SUBDIRECTORY_OK=Yes
. git-sh-setup
no_prune=:
+progress=
while test $# != 0
do
case "$1" in
--prune)
no_prune=
;;
+ --progress)
+ progress=--progress
+ ;;
--)
usage
;;
@@ -32,6 +36,6 @@ esac
test "true" != "$pack_refs" ||
git pack-refs --prune &&
git reflog expire --all &&
-git-repack -a -d -l &&
+git-repack -a -d -l $progress &&
$no_prune git prune &&
git rerere gc || exit
--
1.7.6.1
[-- Attachment #4: Type: text/plain, Size: 2 bytes --]
^ permalink raw reply related
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <7v39fhyk21.fsf@alter.siamese.dyndns.org>
On Tue, 27 Sep 2011 10:25:10 -0700, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> It seems like a more logical approach would be instead for "git
>> commit" to take a "--root" option that would create a new root commit
>> based on the current index and then point the current branch head to
>> the new root commit. Thus:
>>
>> $ git checkout -b new_branch old_branch
>> $ # Manipulate or not
>> $ git commit --root
>>
>> That's how people think.
>
> This may indeed be an improvement. I suspect that we'd need to think about
> it a bit more, but it feels right (perhaps introduce this new option,
> deprecate --orphan from the checkout, and then eventually remove it
> sometime in 1.8.0 timeframe).
>
>>>> The index and the working tree are adjusted as if you had previously run
>>>> "git checkout <start_point>". This allows you to start a new history
>>>> -that records a set of paths similar to <start_point> by easily running
>>>> +that records a set of paths similar to <start_point> by just running
>>>> "git commit -a" to make the root commit.
>>>
>>> "similar" is an understatement here, maybe "as in"?
>
> I do not think "as in" is an improvement. It completely ignores the
> "Manipulate or not" part in the above, and "similar" was very much an
> attempt to say "you do not have to commit it right away, but start from
> the state and commit a deviation of it".
Actually, that kind of change might make a lot of sense with respect to
[PATCH v2]; here's the kind of text that [PATCH v2.1] will yield:
...
Furthermore, the working tree and the index are adjusted as if
you ran "git checkout <start_point>"; thus, by just running
"git commit", you can create a root commit with a tree that is
exactly the same as the tree of <start_point>.
Naturally, before creating the commit, you may manipulate the
index in any way you want. For example, if you want to create
a root commit with a tree that is totally different from the
tree of <start_point>, then just clear the working tree and
index first: From the top level of the working tree, run
"git rm -rf .", and then prepare your new working tree
and index as desired.
^ permalink raw reply
* [PATCH 3/3] git-remote-mediawiki: obey advice.pushNonFastForward
From: Matthieu Moy @ 2011-09-27 17:55 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1317146100-22938-1-git-send-email-Matthieu.Moy@imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 9bb58ab..b809792 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -603,13 +603,16 @@ sub mw_import_ref {
}
sub error_non_fast_forward {
- # Native git-push would show this after the summary.
- # We can't ask it to display it cleanly, so print it
- # ourselves before.
- print STDERR "To prevent you from losing history, non-fast-forward updates were rejected\n";
- print STDERR "Merge the remote changes (e.g. 'git pull') before pushing again. See the\n";
- print STDERR "'Note about fast-forwards' section of 'git push --help' for details.\n";
-
+ my $advice = run_git("config --bool advice.pushNonFastForward");
+ chomp($advice);
+ if ($advice ne "false") {
+ # Native git-push would show this after the summary.
+ # We can't ask it to display it cleanly, so print it
+ # ourselves before.
+ print STDERR "To prevent you from losing history, non-fast-forward updates were rejected\n";
+ print STDERR "Merge the remote changes (e.g. 'git pull') before pushing again. See the\n";
+ print STDERR "'Note about fast-forwards' section of 'git push --help' for details.\n";
+ }
print STDOUT "error $_[0] \"non-fast-forward\"\n";
return 0;
}
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* [PATCH 1/3] git-remote-mediawiki: trivial fixes
From: Matthieu Moy @ 2011-09-27 17:54 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
Fix a whitespace issue (no space before :) and remove unused %status in
mw_push.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 0ba88de..768b42d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -656,7 +656,7 @@ sub mw_push_file {
$mediawiki->{error}->{code} .
' from mediwiki: ' . $mediawiki->{error}->{details};
$newrevid = $result->{edit}->{newrevid};
- print STDERR "Pushed file : $new_sha1 - $title\n";
+ print STDERR "Pushed file: $new_sha1 - $title\n";
} else {
print STDERR "$complete_file_name not a mediawiki file (Not pushable on this version of git-remote-mediawiki).\n"
}
@@ -666,7 +666,6 @@ sub mw_push_file {
sub mw_push {
# multiple push statements can follow each other
my @refsspecs = (shift, get_more_refs("push"));
- my %status;
my $pushed;
for my $refspec (@refsspecs) {
my ($force, $local, $remote) = $refspec =~ /^(\+)?([^:]*):([^:]*)$/
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* [PATCH 2/3] git-remote-mediawiki: set 'basetimestamp' to let the wiki handle conflicts
From: Matthieu Moy @ 2011-09-27 17:54 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1317146100-22938-1-git-send-email-Matthieu.Moy@imag.fr>
We already have a check that no new revisions are on the wiki at the
beginning of the push, but this didn't handle concurrent accesses to the
wiki.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 43 +++++++++++++++++++++++++++----
1 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 768b42d..9bb58ab 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -287,6 +287,9 @@ sub get_last_local_revision {
return $lastrevision_number;
}
+# Remember the timestamp corresponding to a revision id.
+my %basetimestamps;
+
sub get_last_remote_revision {
mw_connect_maybe();
@@ -300,7 +303,7 @@ sub get_last_remote_revision {
my $query = {
action => 'query',
prop => 'revisions',
- rvprop => 'ids',
+ rvprop => 'ids|timestamp',
pageids => $id,
};
@@ -308,6 +311,8 @@ sub get_last_remote_revision {
my $lastrev = pop(@{$result->{query}->{pages}->{$id}->{revisions}});
+ $basetimestamps{$lastrev->{revid}} = $lastrev->{timestamp};
+
$max_rev_num = ($lastrev->{revid} > $max_rev_num ? $lastrev->{revid} : $max_rev_num);
}
@@ -649,18 +654,32 @@ sub mw_push_file {
action => 'edit',
summary => $summary,
title => $title,
+ basetimestamp => $basetimestamps{$newrevid},
text => mediawiki_clean($file_content, $page_created),
}, {
skip_encoding => 1 # Helps with names with accentuated characters
- }) || die 'Fatal: Error ' .
- $mediawiki->{error}->{code} .
- ' from mediwiki: ' . $mediawiki->{error}->{details};
+ });
+ if (!$result) {
+ if ($mediawiki->{error}->{code} == 3) {
+ # edit conflicts, considered as non-fast-forward
+ print STDERR 'Warning: Error ' .
+ $mediawiki->{error}->{code} .
+ ' from mediwiki: ' . $mediawiki->{error}->{details} .
+ ".\n";
+ return ($newrevid, "non-fast-forward");
+ } else {
+ # Other errors. Shouldn't happen => just die()
+ die 'Fatal: Error ' .
+ $mediawiki->{error}->{code} .
+ ' from mediwiki: ' . $mediawiki->{error}->{details};
+ }
+ }
$newrevid = $result->{edit}->{newrevid};
print STDERR "Pushed file: $new_sha1 - $title\n";
} else {
print STDERR "$complete_file_name not a mediawiki file (Not pushable on this version of git-remote-mediawiki).\n"
}
- return $newrevid;
+ return ($newrevid, "ok");
}
sub mw_push {
@@ -767,13 +786,25 @@ sub mw_push_revision {
chomp($commit_msg);
# Push every blob
while (@diff_info_list) {
+ my $status;
# git diff-tree -z gives an output like
# <metadata>\0<filename1>\0
# <metadata>\0<filename2>\0
# and we've split on \0.
my $info = shift(@diff_info_list);
my $file = shift(@diff_info_list);
- $mw_revision = mw_push_file($info, $file, $commit_msg, $mw_revision);
+ ($mw_revision, $status) = mw_push_file($info, $file, $commit_msg, $mw_revision);
+ if ($status eq "non-fast-forward") {
+ # we may already have sent part of the
+ # commit to MediaWiki, but it's too
+ # late to cancel it. Stop the push in
+ # the middle, but still give an
+ # accurate error message.
+ return error_non_fast_forward($remote);
+ }
+ if ($status ne "ok") {
+ die("Unknown error from mw_push_file()");
+ }
}
unless ($dumb_push) {
run_git("notes --ref=$remotename/mediawiki add -m \"mediawiki_revision: $mw_revision\" $sha1_commit");
--
1.7.7.rc0.75.g56f27
^ permalink raw reply related
* Re: [PATCH] gitweb: Add js=1 before an URI fragment to fix line number links
From: Junio C Hamano @ 2011-09-27 17:40 UTC (permalink / raw)
To: Peter Stuge; +Cc: Johannes Sixt, git
In-Reply-To: <20110927094947.10955.qmail@stuge.se>
Peter Stuge <peter@stuge.se> writes:
> I disagree, but I agree with you if we qualify that a little. The
> right balance is a matter of subjective review, so the only way it
> can be practiced with relevance is by actually working with the same
> reviewers for a while, to learn what they consider right.
>
> It can absolutely not be practiced out of context,...
You are right that you need to practice in the context of working in the
Git project to explain your change with the right amount of details when
preparing a change for the Git project, and the same goes for the openocd
project.
We aim to write our commit log messages primarily for future developers
who want to read "git log -p" output and understand why these changes had
to be made, to help them avoid intentionally breaking what the old commit
wanted to achieve when they want to modify the existing code 6 months down
the road. Your reviewers aim to make sure that your log message gives
sufficient information to such future developers, as opposed to themselves
while reviewing the patch and the issue is still fresh in their head.
I suspect that the target audience of log message may even be different
depending on the project, and openocd may not work that way, and that is
perfectly fine.
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Junio C Hamano @ 2011-09-27 17:25 UTC (permalink / raw)
To: Michael Witten; +Cc: Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1BsvnZ7PyfjOJURX+B7vCZcYheLS4pissGvPNjEivbYXtw@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> It seems like a more logical approach would be instead for "git
> commit" to take a "--root" option that would create a new root commit
> based on the current index and then point the current branch head to
> the new root commit. Thus:
>
> $ git checkout -b new_branch old_branch
> $ # Manipulate or not
> $ git commit --root
>
> That's how people think.
This may indeed be an improvement. I suspect that we'd need to think about
it a bit more, but it feels right (perhaps introduce this new option,
deprecate --orphan from the checkout, and then eventually remove it
sometime in 1.8.0 timeframe).
>>> The index and the working tree are adjusted as if you had previously run
>>> "git checkout <start_point>". This allows you to start a new history
>>> -that records a set of paths similar to <start_point> by easily running
>>> +that records a set of paths similar to <start_point> by just running
>>> "git commit -a" to make the root commit.
>>
>> "similar" is an understatement here, maybe "as in"?
I do not think "as in" is an improvement. It completely ignores the
"Manipulate or not" part in the above, and "similar" was very much an
attempt to say "you do not have to commit it right away, but start from
the state and commit a deviation of it".
^ permalink raw reply
* Re: [PATCH] gitweb: Fix links to lines in blobs when javascript-actions are enabled
From: Junio C Hamano @ 2011-09-27 17:17 UTC (permalink / raw)
To: Peter Stuge; +Cc: git
In-Reply-To: <1317117060-3955-1-git-send-email-peter@stuge.se>
Peter Stuge <peter@stuge.se> writes:
> Some javascript code will run in the browser onLoad and signals back to
> gitweb that the browser can actually do javascript.
>
> The code adds [?;]js=1 into the URL of all links on the page. The code
> always added [?;]js=1 to the end of links, which is wrong when links
> contain a URI fragment, such as links directly to a line in a blob:
> ..?p=repo.git;a=blob;f=file#l123
>
> In this case, [?;]js=1 must be added before the hashmark.
>
> Signed-off-by: Peter Stuge <peter@stuge.se>
Nicely done. You forgot to mention another bug you fixed (see Jakub's
sample in the thread), so I'll amend in a few sentences to describe it as
well.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 17:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq8vpa2agq.fsf@bauges.imag.fr>
On Tue, Sep 27, 2011 at 16:53, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> I think that the last paragraph provides enough context to understand
>> its usefulness.
>
> The last paragraph tells the user how to commit something different from
> what is already here, which is pretty much the opposite.
>
> IOW, I see two uses for --orphan:
>
> 1) Publish the same tree without its history
>
> 2) Start a different project, but for some reason you wanted it to leave
> in the same repository and you didn't want a "git init".
>
> The next paragraph documents 2), but your removed paragraph was
> documenting 1). Reading the new version, it feels like the user is
> encourraged to modify the index, while it's just an option.
Those 2 uses are not really different; both are manifestations of
creating a new root commit using some tree.
The way I see it, people would think:
1. I've got to get rid of this proprietary stuff
before I publish as open source.
2. I'll need a new root commit for the open source
stuff, too, otherwise it'll still be accessible.
3a. Aha! I can create a root commit based on the
proprietary stuff, but altered in any way that
I need.
3b. Aha! I've already got a cleaned commit, I can
just use that as the basis for the root commit
without further alteration.
In any case, removing history is probably better handled by
filter-branch or rebase, as I bet more often than not there are
existing descendants of the proposed root commit that need to be
played back anyway.
^ permalink raw reply
* Re: [PATCH] notes_merge_commit(): do not pass temporary buffer to other function
From: Junio C Hamano @ 2011-09-27 16:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Johan Herland
In-Reply-To: <1317098813-30839-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I discovered this problem when an innocent modification to unrelated
> code triggered test failures.
>
> notes-merge.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git notes-merge.c notes-merge.c
> index e1aaf43..baaf31f 100644
> --- notes-merge.c
> +++ notes-merge.c
It is Ok to play with -p0 yourself but please don't do that in the public.
> @@ -680,7 +680,7 @@ int notes_merge_commit(struct notes_merge_options *o,
> * Finally store the new commit object SHA1 into 'result_sha1'.
> */
> struct dir_struct dir;
> - const char *path = git_path(NOTES_MERGE_WORKTREE "/");
> + char *path = xstrdup(git_path(NOTES_MERGE_WORKTREE "/"));
> int path_len = strlen(path), i;
> const char *msg = strstr(partial_commit->buffer, "\n\n");
>
> @@ -720,6 +720,7 @@ int notes_merge_commit(struct notes_merge_options *o,
> result_sha1);
> OUTPUT(o, 4, "Finalized notes merge commit: %s",
> sha1_to_hex(result_sha1));
> + free(path);
> return 0;
> }
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Junio C Hamano @ 2011-09-27 16:56 UTC (permalink / raw)
To: Pang Yan Han
Cc: git, Sitaram Chamarty, Shawn O. Pearce, Jeff King,
Johannes Schindelin
In-Reply-To: <20110927090225.GA1493@myhost>
[offtopic: where does that annoying M-F-T header come from? It even seems
to be pointless in this case as it lists the same people as are already on
To/Cc/From of the message.]
Pang Yan Han <pangyanhan@gmail.com> writes:
> Should I reroll this patch with this behaviour:
>
> - Everything as usual for valid ref updates and deletes
> - For deleting corrupt (dangling?) ref, post-receive and post-update hooks
> also receive the same args as per valid update / delete
Suonds sensible.
> - For deleting non-existent refs:
> - post-receive shall have empty stdin for those refs
> - post-update shall have an empty arg for those refs
I do not think these hooks should see names of refs that ended up being a
no-op. If the push is only about attempting to delete a ref that did not
exist, these hooks should not even get called. If there were other refs
that got updated, these hooks have to be called, but they should not be
told about the no-op. IOW
$ git push $there :no-such-ref master:refs/remotes/origin/master
should:
(1) not call the post-* hooks if the refs/remotes/origin/master was
already pointing at the same commit; or
(2) invoke the post-* hooks if refs/remotes/origin/master is updated, but
should tell hooks only about the update of refs/remotes/origin/master.
That is pretty much in line with how a normal attempt to push the same
commit to an already up-to-date ref works. For example, if you:
$ git push $there master next
when 'master' is lagging and 'next' is already up-to-date, post-update and
post-receive hooks run and told only about 'master' and not 'next'.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 16:53 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1Buf5KxbN59o8QK_dMmF_SEY_Ckuz4DALorZpwuL9gx-Pg@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> I think that the last paragraph provides enough context to understand
> its usefulness.
The last paragraph tells the user how to commit something different from
what is already here, which is pretty much the opposite.
IOW, I see two uses for --orphan:
1) Publish the same tree without its history
2) Start a different project, but for some reason you wanted it to leave
in the same repository and you didn't want a "git init".
The next paragraph documents 2), but your removed paragraph was
documenting 1). Reading the new version, it feels like the user is
encourraged to modify the index, while it's just an option.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: "Resetting" a repository
From: Randal L. Schwartz @ 2011-09-27 16:22 UTC (permalink / raw)
To: gitlist; +Cc: git
In-Reply-To: <4E81EAA7.5030708@myword.co.uk>
>>>>> "gitlist" == gitlist <gitlist@myword.co.uk> writes:
gitlist> I have a project with a test repository and a live repository (and a
gitlist> development repository).
You haven't mentioned what kind of access you have to the two repos.
Are they both bare remote repos? Or can you just rsync one over the
other?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 16:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpqsjni6kkk.fsf@bauges.imag.fr>
On Tue, Sep 27, 2011 at 16:01, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> -This can be useful when you want to publish the tree from a commit
>> -without exposing its full history. You might want to do this to publish
>> -an open source branch of a project whose current tree is "clean", but
>> -whose full history contains proprietary or otherwise encumbered bits of
>> -code.
>
> This part used to be just this in v1:
>
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> +This can be useful when you want to publish a tree without exposing its
> +full history; for instance, you might want to do this to publish
> an open source branch of a project whose current tree is "clean", but
> whose full history contains proprietary or otherwise encumbered bits of
> code.
>
> is it intentionnal that you discarded completely the paragraph? If so,
> then I disagree, the paragraph was one of the main motivation for
> someone to use --orphan, without it, someone may understand _what_ it
> does, but not _why_ it is useful.
It was intentional; I was finding it difficult to express that
paragraph succintly in a way that is consistent with correct
terminology. Then I realized it's fairly redundant, anyway.
I think that the last paragraph provides enough context to understand
its usefulness. Also, anybody who ever independently decided to carve
out proprietary bits in that way would immediately recognize the need
for creating a commit without parents, a notion which would lead him
or her pretty quickly to this documentation or jog his or her memory
about it based on the text of v2.
If everyone else is quite set on keeping that paragraph, though, I'll
take the challenge; however, I think that would be a waste of time.
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 16:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <4E81F080.7010905@drmicha.warpmail.net>
On Tue, Sep 27, 2011 at 15:49, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael Witten venit, vidit, dixit 27.09.2011 16:43:
>> See:
>>
>> Re: Can a git changeset be created with no parent
>> Carlos Martín Nieto <cmn@elego.de>
>> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
>> http://article.gmane.org/gmane.comp.version-control.git/182170
>>
>> and:
>>
>> git help glossary
>>
>> Signed-off-by: Michael Witten <mfwitten@gmail.com>
>> ---
>> Documentation/git-checkout.txt | 13 +++++--------
>> 1 files changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
>> index c0a96e6..c963a0f 100644
>> --- a/Documentation/git-checkout.txt
>> +++ b/Documentation/git-checkout.txt
>> @@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
>> below for details.
>>
>> --orphan::
>> - Create a new 'orphan' branch, named <new_branch>, started from
>> - <start_point> and switch to it. The first commit made on this
>> - new branch will have no parents and it will be the root of a new
>> - history totally disconnected from all the other branches and
>> - commits.
>> + Tell git to make the next commit you make a root commit referenced by
>> + the branch head <new_branch>.
>
> I recall objecting to the name "--orphan" (to no avail) because the
> first commit is the root commit and there is no "orphan branch nor
> "parent branch"...
It seems like a more logical approach would be instead for "git
commit" to take a "--root" option that would create a new root commit
based on the current index and then point the current branch head to
the new root commit. Thus:
$ git checkout -b new_branch old_branch
$ # Manipulate or not
$ git commit --root
That's how people think.
> In any case, I think the above is indeed an improvement, but I would
> keep at least something which connects to the misnamed option, e.g.
>
> ...root commit (i.e. without parents) referenced by...
>
Agreed! See the new v2 patch:
http://article.gmane.org/gmane.comp.version-control.git/182245
>> +
>> The index and the working tree are adjusted as if you had previously run
>> "git checkout <start_point>". This allows you to start a new history
>> -that records a set of paths similar to <start_point> by easily running
>> +that records a set of paths similar to <start_point> by just running
>> "git commit -a" to make the root commit.
>
> "similar" is an understatement here, maybe "as in"?
Damn! I'll send a patch on top of v2.
>> +
>> -This can be useful when you want to publish the tree from a commit
>> -without exposing its full history. You might want to do this to publish
>> +This can be useful when you want to publish a tree without exposing its
>> +full history; for instance, you might want to do this to publish
>> an open source branch of a project whose current tree is "clean", but
>> whose full history contains proprietary or otherwise encumbered bits of
>> code.
>
> +1 ;)
Actually, in v2, I got rid of that entire paragraph, as it's redundant
and difficult to state succinctly AND consistently.
^ permalink raw reply
* Re: [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 16:01 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <69d6fb3199bc4f74b25dae7992a9f132-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> -an open source branch of a project whose current tree is "clean", but
> -whose full history contains proprietary or otherwise encumbered bits of
> -code.
This part used to be just this in v1:
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
+This can be useful when you want to publish a tree without exposing its
+full history; for instance, you might want to do this to publish
an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.
is it intentionnal that you discarded completely the paragraph? If so,
then I disagree, the paragraph was one of the main motivation for
someone to use --orphan, without it, someone may understand _what_ it
does, but not _why_ it is useful.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 15:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq39fi9gf5.fsf@bauges.imag.fr>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..68ae6c9 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,29 +125,22 @@ explicitly give a name with '-b' in such a case.
below for details.
--orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
+ Tell git to make the next commit you create a root commit (that is,
+ a commit without any parent); creating the next commit is similar to
+ creating the first commit after running "git init", except that the
+ new commit will be referenced by the branch head <new_branch> rather
+ than "master".
+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
+Furthermore, the index and the working tree are adjusted as if you ran
+"git checkout <start_point>"; by just running "git commit -a", you can
+create a root commit that records a tree similar to that of <start_point>.
+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
-an open source branch of a project whose current tree is "clean", but
-whose full history contains proprietary or otherwise encumbered bits of
-code.
-+
-If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
-Afterwards you will be ready to prepare your new files, repopulating the
-working tree, by copying them from elsewhere, extracting a tarball, etc.
+Naturally, before creating the commit, you may manipulate the index in any
+way you want. For example, if you want to create a root commit that records
+a tree that is totally different from the one of <start_point>, then just
+clear the working tree and index by running "git rm -rf ." from the top
+level of the working tree, after which you may prepare your new working
+tree and index as desired.
-m::
--merge::
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael J Gruber @ 2011-09-27 15:49 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <e88b6e560cab4ed1937dd191b4180387-mfwitten@gmail.com>
Michael Witten venit, vidit, dixit 27.09.2011 16:43:
> See:
>
> Re: Can a git changeset be created with no parent
> Carlos Martín Nieto <cmn@elego.de>
> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
> http://article.gmane.org/gmane.comp.version-control.git/182170
>
> and:
>
> git help glossary
>
> Signed-off-by: Michael Witten <mfwitten@gmail.com>
> ---
> Documentation/git-checkout.txt | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index c0a96e6..c963a0f 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
> below for details.
>
> --orphan::
> - Create a new 'orphan' branch, named <new_branch>, started from
> - <start_point> and switch to it. The first commit made on this
> - new branch will have no parents and it will be the root of a new
> - history totally disconnected from all the other branches and
> - commits.
> + Tell git to make the next commit you make a root commit referenced by
> + the branch head <new_branch>.
I recall objecting to the name "--orphan" (to no avail) because the
first commit is the root commit and there is no "orphan branch nor
"parent branch"...
In any case, I think the above is indeed an improvement, but I would
keep at least something which connects to the misnamed option, e.g.
...root commit (i.e. without parents) referenced by...
> +
> The index and the working tree are adjusted as if you had previously run
> "git checkout <start_point>". This allows you to start a new history
> -that records a set of paths similar to <start_point> by easily running
> +that records a set of paths similar to <start_point> by just running
> "git commit -a" to make the root commit.
"similar" is an understatement here, maybe "as in"?
> +
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> +This can be useful when you want to publish a tree without exposing its
> +full history; for instance, you might want to do this to publish
> an open source branch of a project whose current tree is "clean", but
> whose full history contains proprietary or otherwise encumbered bits of
> code.
+1 ;)
Michael
^ permalink raw reply
* "Resetting" a repository
From: gitlist @ 2011-09-27 15:24 UTC (permalink / raw)
To: git
I have a project with a test repository and a live repository (and a
development repository).
Over time, the test repository has had merges which were in a quite
different order to the live repository, so it no longer fulfills its
role of being pretty much like the live repository and therefore a good
place to test. The two have diverged too far.
We've reached a point in the project when it would be good to reset the
test repository so that it is exactly the same as the live one. We can
then merge new work from the development repository.
I think that if I just merge the live repository into the test
respository it will not remove extra (non-conflicting) code. On this
occasion I want to remove all extra code and resolve all conflicts in
favour of the live repository version.
I'd appreciate advice on the best way to do this.
Thanks
Roddie Grant
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-27 15:02 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Carlos Martín Nieto, vra5107, git
In-Reply-To: <e88b6e560cab4ed1937dd191b4180387-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> + Tell git to make the next commit you make a root commit
I'd even add
(just like the first commit after "git init")
at this point.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-27 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, vra5107, git
In-Reply-To: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..c963a0f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,19 +125,16 @@ explicitly give a name with '-b' in such a case.
below for details.
--orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
+ Tell git to make the next commit you make a root commit referenced by
+ the branch head <new_branch>.
+
The index and the working tree are adjusted as if you had previously run
"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
+that records a set of paths similar to <start_point> by just running
"git commit -a" to make the root commit.
+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
+This can be useful when you want to publish a tree without exposing its
+full history; for instance, you might want to do this to publish
an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: [PATCH] show git tag output in pager
From: Matthieu Moy @ 2011-09-27 14:19 UTC (permalink / raw)
To: Michal Vyskocil; +Cc: git
In-Reply-To: <20110927134235.GA27478@zelva.suse.cz>
The commit message should explain why this is needed, and in particular
why you prefer this to setting pager.tag in your ~/.gitconfig.
Michal Vyskocil <mvyskocil@suse.cz> writes:
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -147,6 +147,8 @@ static int list_tags(const char **patterns, int lines,
> struct commit_list *with_commit)
> {
> struct tag_filter filter;
> +
> + setup_pager();
Git indents with tabs, not spaces, and does not leave trailing
whitespaces.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] show git tag output in pager
From: Michal Vyskocil @ 2011-09-27 13:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
---
builtin/tag.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 667515e..9f70fa8 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -147,6 +147,8 @@ static int list_tags(const char **patterns, int lines,
struct commit_list *with_commit)
{
struct tag_filter filter;
+
+ setup_pager();
filter.patterns = patterns;
filter.lines = lines;
--
1.7.6.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [RFC/PATCHv2] git-p4: handle files with shell metacharacters
From: Pete Wyckoff @ 2011-09-27 13:03 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, vitor.hda
In-Reply-To: <1317112836-14135-1-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Tue, 27 Sep 2011 09:40 +0100:
> Updated git-p4 changes incorporating Pete's comments.
>
> - p4CmdList's stdin argument can now be a list.
I think this fits in with the rest of the patch and can stay.
> - Getting rid of the string option entirely is very hard; there are
> places where currently git-p4 creates a pipeline.
Yeah, thanks for checking though. Best to leave it consistent
like you did.
> - I wonder if verbose should actually be enabled for all the test
> cases?
It is way too verbose, even for test, but I see the argument.
One easy place to change it would be in the definition in
t/lib-git-p4.sh. You could do this by hand when testing the
tests perhaps.
> - The $ENV{PWD} is needed now because the shell used to set that; now
> that the shell isn't in use git-p4 has to set it.
>
> Pete - I wasn't sure whether you were saying I should rework
> my patch against next (and you would then rework your series) or
> something else. That sounds complicated though - let me know!
If you don't mind, I'll just queue it up with the utf16 and
test-refactor stuff I have, and send it all to Junio post-1.7.7.
Here's how I plan to adjust your tests, given the feedback that
Junio gave earlier and from reading other tests in t/.
-- Pete
-----------8<------------------
From 6b4bd671df338210ffd0348358420f0feb6f35c0 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@padd.com>
Date: Tue, 27 Sep 2011 08:53:25 -0400
Subject: [PATCH] git-p4 t9803: align syntax with other tests
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9803-git-shell-metachars.sh | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/t/t9803-git-shell-metachars.sh b/t/t9803-git-shell-metachars.sh
index c166603..6cf4298 100755
--- a/t/t9803-git-shell-metachars.sh
+++ b/t/t9803-git-shell-metachars.sh
@@ -5,9 +5,7 @@ test_description='git-p4 transparency to shell metachars in filenames'
. ./lib-git-p4.sh
test_expect_success 'start p4d' '
- kill_p4d || : &&
- start_p4d &&
- cd "$TRASH_DIRECTORY"
+ start_p4d
'
test_expect_success 'init depot' '
@@ -30,25 +28,18 @@ test_expect_success 'shell metachars in filenames' '
echo f2 >"file with spaces" &&
git add "file with spaces" &&
P4EDITOR=touch git commit -m "add files" &&
- "$GITP4" submit --verbose &&
+ "$GITP4" submit
+ ) &&
+ (
cd "$cli" &&
p4 sync ... &&
- ls -l "file with spaces" &&
- ls -l "foo\$bar"
+ test -e "file with spaces" &&
+ test -e "foo\$bar"
)
'
-check_missing () {
- for i in $*; do
- if [ -f $i ]; then
- echo $i found but should be missing 1>&2
- exit 1
- fi
- done
-}
-
test_expect_success 'deleting with shell metachars' '
- "$GITP4" clone --dest="$git" --verbose //depot &&
+ "$GITP4" clone --dest="$git" //depot &&
test_when_finished cleanup_git &&
(
cd "$git" &&
@@ -56,10 +47,13 @@ test_expect_success 'deleting with shell metachars' '
git rm foo\$bar &&
git rm file\ with\ spaces &&
P4EDITOR=touch git commit -m "remove files" &&
- "$GITP4" submit --verbose
+ "$GITP4" submit
+ ) &&
+ (
cd "$cli" &&
p4 sync ... &&
- check_missing "file with spaces" foo\$bar
+ test ! -e "file with spaces" &&
+ test ! -e foo\$bar
)
'
--
1.7.6.3
^ 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