* Re: [PATCH 5/3] revert: introduce --abort to cancel a failed cherry-pick
From: Jonathan Nieder @ 2011-11-23 1:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <7vr50zd5x0.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> ...
>> @@ -168,6 +265,7 @@ test_expect_success '--continue continues after conflicts are resolved' '
>> OBJID
>> :100644 100644 OBJID OBJID M unrelated
>> OBJID
>> + :000000 100644 OBJID OBJID A bar
>> :000000 100644 OBJID OBJID A foo
>> :000000 100644 OBJID OBJID A unrelated
>> EOF
>
> What is this hunk about?
Just laziness. It would have been more polite for changes to the
script's setup to be made in such a way as not to require changing
unrelated tests, like this.
-- >8 --
Subject: revert: introduce --abort to cancel a failed cherry-pick
After running some ill-advised command like "git cherry-pick
HEAD..linux-next", the bewildered novice may want to return to more
familiar territory. Introduce a "git cherry-pick --abort" command
that rolls back the entire cherry-pick sequence and places the
repository back on solid ground.
Just like "git merge --abort", this internally uses "git reset
--merge", so local changes not involved in the conflict resolution are
preserved.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-cherry-pick.txt | 1 +
Documentation/git-revert.txt | 1 +
Documentation/sequencer.txt | 3 +
builtin/revert.c | 87 ++++++++++++++++++++++++++++++++-
t/t3510-cherry-pick-sequence.sh | 96 +++++++++++++++++++++++++++++++++++++
5 files changed, 185 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 21998b82..fed5097e 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -11,6 +11,7 @@ SYNOPSIS
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
'git cherry-pick' --continue
'git cherry-pick' --quit
+'git cherry-pick' --abort
DESCRIPTION
-----------
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index b0fcabc8..b699a345 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -11,6 +11,7 @@ SYNOPSIS
'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
'git revert' --continue
'git revert' --quit
+'git revert' --abort
DESCRIPTION
-----------
diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt
index 75f8e869..5747f442 100644
--- a/Documentation/sequencer.txt
+++ b/Documentation/sequencer.txt
@@ -7,3 +7,6 @@
Forget about the current operation in progress. Can be used
to clear the sequencer state after a failed cherry-pick or
revert.
+
+--abort::
+ Cancel the operation and return to the pre-sequence state.
diff --git a/builtin/revert.c b/builtin/revert.c
index f5ba67a5..70a5fbb6 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -40,7 +40,12 @@ static const char * const cherry_pick_usage[] = {
};
enum replay_action { REVERT, CHERRY_PICK };
-enum replay_subcommand { REPLAY_NONE, REPLAY_REMOVE_STATE, REPLAY_CONTINUE };
+enum replay_subcommand {
+ REPLAY_NONE,
+ REPLAY_REMOVE_STATE,
+ REPLAY_CONTINUE,
+ REPLAY_ROLLBACK
+};
struct replay_opts {
enum replay_action action;
@@ -135,9 +140,11 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
const char *me = action_name(opts);
int remove_state = 0;
int contin = 0;
+ int rollback = 0;
struct option options[] = {
OPT_BOOLEAN(0, "quit", &remove_state, "end revert or cherry-pick sequence"),
OPT_BOOLEAN(0, "continue", &contin, "resume revert or cherry-pick sequence"),
+ OPT_BOOLEAN(0, "abort", &rollback, "cancel revert or cherry-pick sequence"),
OPT_BOOLEAN('n', "no-commit", &opts->no_commit, "don't automatically commit"),
OPT_BOOLEAN('e', "edit", &opts->edit, "edit the commit message"),
OPT_NOOP_NOARG('r', NULL),
@@ -173,6 +180,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
verify_opt_mutually_compatible(me,
"--quit", remove_state,
"--continue", contin,
+ "--abort", rollback,
NULL);
/* Set the subcommand */
@@ -180,6 +188,8 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
opts->subcommand = REPLAY_REMOVE_STATE;
else if (contin)
opts->subcommand = REPLAY_CONTINUE;
+ else if (rollback)
+ opts->subcommand = REPLAY_ROLLBACK;
else
opts->subcommand = REPLAY_NONE;
@@ -188,8 +198,12 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
char *this_operation;
if (opts->subcommand == REPLAY_REMOVE_STATE)
this_operation = "--quit";
- else
+ else if (opts->subcommand == REPLAY_CONTINUE)
this_operation = "--continue";
+ else {
+ assert(opts->subcommand == REPLAY_ROLLBACK);
+ this_operation = "--abort";
+ }
verify_opt_compatible(me, this_operation,
"--no-commit", opts->no_commit,
@@ -850,7 +864,7 @@ static int create_seq_dir(void)
if (file_exists(seq_dir)) {
error(_("a cherry-pick or revert is already in progress"));
- advise(_("try \"git cherry-pick (--continue | --quit)\""));
+ advise(_("try \"git cherry-pick (--continue | --quit | --abort)\""));
return -1;
}
else if (mkdir(seq_dir, 0777) < 0)
@@ -873,6 +887,71 @@ static void save_head(const char *head)
die(_("Error wrapping up %s."), head_file);
}
+static int reset_for_rollback(const unsigned char *sha1)
+{
+ const char *argv[4]; /* reset --merge <arg> + NULL */
+ argv[0] = "reset";
+ argv[1] = "--merge";
+ argv[2] = sha1_to_hex(sha1);
+ argv[3] = NULL;
+ return run_command_v_opt(argv, RUN_GIT_CMD);
+}
+
+static int rollback_single_pick(void)
+{
+ unsigned char head_sha1[20];
+
+ if (!file_exists(git_path("CHERRY_PICK_HEAD")) &&
+ !file_exists(git_path("REVERT_HEAD")))
+ return error(_("no cherry-pick or revert in progress"));
+ if (!resolve_ref("HEAD", head_sha1, 0, NULL))
+ return error(_("cannot resolve HEAD"));
+ if (is_null_sha1(head_sha1))
+ return error(_("cannot abort from a branch yet to be born"));
+ return reset_for_rollback(head_sha1);
+}
+
+static int sequencer_rollback(struct replay_opts *opts)
+{
+ const char *filename;
+ FILE *f;
+ unsigned char sha1[20];
+ struct strbuf buf = STRBUF_INIT;
+
+ filename = git_path(SEQ_HEAD_FILE);
+ f = fopen(filename, "r");
+ if (!f && errno == ENOENT) {
+ /*
+ * There is no multiple-cherry-pick in progress.
+ * If CHERRY_PICK_HEAD or REVERT_HEAD indicates
+ * a single-cherry-pick in progress, abort that.
+ */
+ return rollback_single_pick();
+ }
+ if (!f)
+ return error(_("cannot open %s: %s"), filename,
+ strerror(errno));
+ if (strbuf_getline(&buf, f, '\n')) {
+ error(_("cannot read %s: %s"), filename, ferror(f) ?
+ strerror(errno) : _("unexpected end of file"));
+ goto fail;
+ }
+ if (get_sha1_hex(buf.buf, sha1) || buf.buf[40] != '\0') {
+ error(_("stored pre-cherry-pick HEAD file '%s' is corrupt"),
+ filename);
+ goto fail;
+ }
+ if (reset_for_rollback(sha1))
+ goto fail;
+ strbuf_release(&buf);
+ fclose(f);
+ return 0;
+fail:
+ strbuf_release(&buf);
+ fclose(f);
+ return -1;
+}
+
static void save_todo(struct commit_list *todo_list, struct replay_opts *opts)
{
const char *todo_file = git_path(SEQ_TODO_FILE);
@@ -977,6 +1056,8 @@ static int pick_revisions(struct replay_opts *opts)
remove_sequencer_state(1);
return 0;
}
+ if (opts->subcommand == REPLAY_ROLLBACK)
+ return sequencer_rollback(opts);
if (opts->subcommand == REPLAY_CONTINUE) {
if (!file_exists(git_path(SEQ_TODO_FILE)))
return error(_("No %s in progress"), action_name(opts));
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index bb67cdcb..e97397f9 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -2,6 +2,7 @@
test_description='Test cherry-pick continuation features
+ + yetanotherpick: rewrites foo to e
+ anotherpick: rewrites foo to d
+ picked: rewrites foo to c
+ unrelatedpick: rewrites unrelated to reallyunrelated
@@ -19,6 +20,12 @@ pristine_detach () {
git clean -d -f -f -q -x
}
+test_cmp_rev () {
+ git rev-parse --verify "$1" >expect.rev &&
+ git rev-parse --verify "$2" >actual.rev &&
+ test_cmp expect.rev actual.rev
+}
+
test_expect_success setup '
echo unrelated >unrelated &&
git add unrelated &&
@@ -27,6 +34,7 @@ test_expect_success setup '
test_commit unrelatedpick unrelated reallyunrelated &&
test_commit picked foo c &&
test_commit anotherpick foo d &&
+ test_commit yetanotherpick foo e &&
git config advice.detachedhead false
'
@@ -75,6 +83,11 @@ test_expect_success '--quit does not complain when no cherry-pick is in progress
git cherry-pick --quit
'
+test_expect_success '--abort requires cherry-pick in progress' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick --abort
+'
+
test_expect_success '--quit cleans up sequencer state' '
pristine_detach initial &&
test_must_fail git cherry-pick base..picked &&
@@ -103,6 +116,79 @@ test_expect_success 'cherry-pick --reset (another name for --quit)' '
test_cmp expect actual
'
+test_expect_success '--abort to cancel multiple cherry-pick' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick base..anotherpick &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev initial HEAD &&
+ git update-index --refresh &&
+ git diff-index --exit-code HEAD
+'
+
+test_expect_success '--abort to cancel single cherry-pick' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick picked &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev initial HEAD &&
+ git update-index --refresh &&
+ git diff-index --exit-code HEAD
+'
+
+test_expect_success 'cherry-pick --abort to cancel multiple revert' '
+ pristine_detach anotherpick &&
+ test_must_fail git revert base..picked &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev anotherpick HEAD &&
+ git update-index --refresh &&
+ git diff-index --exit-code HEAD
+'
+
+test_expect_success 'revert --abort works, too' '
+ pristine_detach anotherpick &&
+ test_must_fail git revert base..picked &&
+ git revert --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev anotherpick HEAD
+'
+
+test_expect_success '--abort to cancel single revert' '
+ pristine_detach anotherpick &&
+ test_must_fail git revert picked &&
+ git revert --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev anotherpick HEAD &&
+ git update-index --refresh &&
+ git diff-index --exit-code HEAD
+'
+
+test_expect_success '--abort keeps unrelated change, easy case' '
+ pristine_detach unrelatedpick &&
+ echo changed >expect &&
+ test_must_fail git cherry-pick picked..yetanotherpick &&
+ echo changed >unrelated &&
+ git cherry-pick --abort &&
+ test_cmp expect unrelated
+'
+
+test_expect_success '--abort refuses to clobber unrelated change, harder case' '
+ pristine_detach initial &&
+ echo changed >expect &&
+ test_must_fail git cherry-pick base..anotherpick &&
+ echo changed >unrelated &&
+ test_must_fail git cherry-pick --abort &&
+ test_cmp expect unrelated &&
+ git rev-list HEAD >log &&
+ test_line_count = 2 log &&
+ test_must_fail git update-index --refresh &&
+
+ git checkout unrelated &&
+ git cherry-pick --abort &&
+ test_cmp_rev initial HEAD
+'
+
test_expect_success 'cherry-pick cleans up sequencer state when one commit is left' '
pristine_detach initial &&
test_must_fail git cherry-pick base..picked &&
@@ -127,6 +213,16 @@ test_expect_success 'cherry-pick cleans up sequencer state when one commit is le
test_cmp expect actual
'
+test_expect_failure '--abort after last commit in sequence' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick base..picked &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_cmp_rev initial HEAD &&
+ git update-index --refresh &&
+ git diff-index --exit-code HEAD
+'
+
test_expect_success 'cherry-pick does not implicitly stomp an existing operation' '
pristine_detach initial &&
test_must_fail git cherry-pick base..anotherpick &&
--
1.7.8.rc3
^ permalink raw reply related
* git not resuming push
From: Paul Brossier @ 2011-11-23 3:58 UTC (permalink / raw)
To: git
Hi!
I'm trying to upload large amount of data from a connection that often
cuts.
If the connection fails after uploading part of the data, it seems I
need to start over from zero again. Is there a way to resume the upload
instead?
Here is an example:
$ git push
Counting objects: 504, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (475/475), done.
Write failed: Broken pipe1/476), 533.78 MiB | 60 KiB/s
fatal: The remote end hung up unexpectedly
error: pack-objects died of signal 13
error: failed to push some refs to 'myhost.org:/git/myrepo/'
$ git push
Counting objects: 504, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (475/475), done.
Writing objects: 12% (61/476), 89.34 MiB | 23 KiB/s
Thanks, piem
^ permalink raw reply
* Re: git not resuming push
From: Jeff King @ 2011-11-23 5:02 UTC (permalink / raw)
To: Paul Brossier; +Cc: git
In-Reply-To: <4ECC6F80.6010907@piem.org>
On Tue, Nov 22, 2011 at 08:58:56PM -0700, Paul Brossier wrote:
> If the connection fails after uploading part of the data, it seems I
> need to start over from zero again. Is there a way to resume the upload
> instead?
No, there isn't a way to resume just using push.
If you have shell access on the server, one workaround you can do is to
create a bundle with the commits in question, upload it via some
resumable protocol (like sftp, http, rsync, etc), possibly taking many
attempts, and then fetch the result on the server side from the bundle
into the repository.
See "git help bundle" for some examples.
-Peff
^ permalink raw reply
* Re: git not resuming push
From: Junio C Hamano @ 2011-11-23 6:24 UTC (permalink / raw)
To: Paul Brossier; +Cc: git
In-Reply-To: <20111123050220.GA9127@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 22, 2011 at 08:58:56PM -0700, Paul Brossier wrote:
>
>> If the connection fails after uploading part of the data, it seems I
>> need to start over from zero again. Is there a way to resume the upload
>> instead?
>
> No, there isn't a way to resume just using push.
>
> If you have shell access on the server, one workaround you can do is to
> create a bundle with the commits in question, upload it via some
> resumable protocol (like sftp, http, rsync, etc), possibly taking many
> attempts, and then fetch the result on the server side from the bundle
> into the repository.
>
> See "git help bundle" for some examples.
Another possibility, if it is the connection between you and the other
side that is the problem, is to chunk your push in smaller pieces. That
is, if you are trying to push out v3.0, you first push only to v1.0, then
to v2.0, and then finally to v3.0.
Peff, by the way, wouldn't this request reminds of us of a scenario we
discussed recently, which I said I would imagine would be common while you
dismissed as not likely to be common?
^ permalink raw reply
* [PATCH] builtin-branch: Fix crash on invalid use of --force
From: vfr @ 2011-11-23 6:31 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
From: Vincent van Ravesteijn <vfr@lyx.org>
The option --force should not put us in 'create branch' mode. The
fact that this option is only valid in 'create branch' mode is
already caught by the the next 'if' in which we assure that we
are in the correct mode.
Without this patch, we end up calling create_branch without any
arguments. This means that argv[0] makes not much sense and
that we will finally crash because the branch name is a NULL
pointer. Hence the added safety check that we should not try
to create a branch without a name.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
builtin/branch.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 51ca6a0..55cad76 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -705,7 +705,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
- if (!delete && !rename && !force_create && argc == 0)
+ if (!delete && !rename && argc == 0)
list = 1;
if (!!delete + !!rename + !!force_create + !!list > 1)
@@ -726,7 +726,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(argv[0], argv[1], rename > 1);
else
usage_with_options(builtin_branch_usage, options);
- } else if (argc <= 2) {
+ } else if (argc > 0 && argc <= 2) {
if (kinds != REF_LOCAL_BRANCH)
die(_("-a and -r options to 'git branch' do not make sense with a branch name"));
create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
--
1.7.8-rc3
^ permalink raw reply related
* [PATCH] builtin-reset: Documentation update
From: vfr @ 2011-11-23 6:44 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
From: Vincent van Ravesteijn <vfr@lyx.org>
The second mode of 'git reset' is defined by the --patch
option, while the third mode is defined by the <mode> option.
Hence, these options are mandatory in the description of the
individual modes.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
Documentation/git-reset.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index b2832fc..b674866 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git reset' [-q] [<commit>] [--] <paths>...
-'git reset' [--patch|-p] [<commit>] [--] [<paths>...]
-'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
+'git reset' (--patch | -p) [<commit>] [--] [<paths>...]
+'git reset' (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>]
DESCRIPTION
-----------
@@ -34,7 +34,7 @@ Alternatively, using linkgit:git-checkout[1] and specifying a commit, you
can copy the contents of a path out of a commit to the index and to the
working tree in one go.
-'git reset' --patch|-p [<commit>] [--] [<paths>...]::
+'git reset' (--patch | -p) [<commit>] [--] [<paths>...]::
Interactively select hunks in the difference between the index
and <commit> (defaults to HEAD). The chosen hunks are applied
in reverse to the index.
@@ -43,7 +43,7 @@ This means that `git reset -p` is the opposite of `git add -p`, i.e.
you can use it to selectively reset hunks. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.
-'git reset' [--<mode>] [<commit>]::
+'git reset' --<mode> [<commit>]::
This form resets the current branch head to <commit> and
possibly updates the index (resetting it to the tree of <commit>) and
the working tree depending on <mode>, which
--
1.7.8-rc3
^ permalink raw reply related
* [PATCH] Fix https interactive authentication problem
From: Steinmann Ruedi @ 2011-11-23 7:58 UTC (permalink / raw)
To: git@vger.kernel.org, gitster@pobox.com
>From 986e29085ee2215a3e0a412ee7874dc2d0ef36be Mon Sep 17 00:00:00 2001
From: Ruedi Steinmann <ruediste@student.ethz.ch>
Date: Wed, 23 Nov 2011 08:41:52 +0100
Subject: [PATCH] Fix https interactive authentication problem
Cloning a repository over https works fine when the username/password is
given in the URL. But if it is queried interactively, an error occurs(see below).
I found that the username/password is not set when a connection is reused.
With this patch, the username/password is set whenever a connection is reused.
Sample output showing the error:
git clone https://n.ethz.ch/student/...
Cloning into ...
Username:
Password:
error: Unable to get pack file https://n.ethz.ch/student/.../objects/pack/pack-1ced2ebff0c9fc1f07e0c7cc9dd3fc75f6ac6962.pack
The requested URL returned error: 401
...
error: Fetch failed.
Signed-off-by: Ruedi Steinmann <ruediste@student.ethz.ch>
---
http.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index e6c7597..c7b3558 100644
--- a/http.c
+++ b/http.c
@@ -550,7 +550,10 @@ struct active_request_slot *get_active_slot(void)
curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
-
+
+ // set username and password if already set
+ init_curl_http_auth(slot->curl);
+
return slot;
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-23 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAH6sp9MxbDhQ3RiA6jO1fswAZX3R6C2fv0gzJdpGp432ovWsjQ@mail.gmail.com>
On Tue, Nov 22, 2011 at 10:31 AM, Frans Klaver <fransklaver@gmail.com> wrote:
> If git is going to do some diagnostics on why the execvp returned
> EACCES, it can still give a few hints. Most of the more likely options
> are then ruled out.
If there are no objections, I'm going to cook up a patch that
- Keeps the current behavior (bail on EACCES)
- Adds a more helpful diagnostic message somewhat like libexplain's,
but more terse and if possible with slightly more domain knowledge
- Takes into account the notes made following
http://article.gmane.org/gmane.comp.version-control.git/171838
Frans
^ permalink raw reply
* Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 8:28 UTC (permalink / raw)
To: git
Hello,
A lot of time when I want to use reset for smth else than "--hard" I
have to go and look the documentation.
I think the modes could be improved by creating new aliases like this:
Optional: a new mode would be introduced for consistency:
--worktree (or maybe --tree): only updates the worktree but not the index
Then the existing mode could be aliased like this:
--mixed would be aliased as --index
--hard would be aliased as --all
--soft could be aliased as --no-changes
Additionally:
--merge could be removed in favor of an additional --preserve-staged flag
--keep could be removed in favor of an additional --safe flag
So if I recap my ideas:
"I want to discard my changes" --> git reset --all HEAD^
"I want to discard the last commit" --> git reset --index HEAD^
"I want to discard the last commit, but let's be safe in case I forgot
about a modified file" --> git reset --all --safe HEAD^
"I want to discard the last commit, keep my current staged changes"
--> git reset --all --preserve-staged HEAD^
Philippe
^ permalink raw reply
* git reset --merge documentation improvments
From: Philippe Vaucher @ 2011-11-23 8:31 UTC (permalink / raw)
To: git
Hello,
The current documentation for --merge is:
"Resets the index [1] and updates the files in the working tree that
are different between <commit> and HEAD, but keeps those which are
different between the index [2] and working tree"
I think this is confusing, because [1] is the *after-reset* index and
[2] is the *before-reset* index. If you fail to realise this it looks
like this "resets index (so index is empty) and then updates worktree
but skip files staged from index" --> "but there's nothing staged, the
index was reset!"
I think a better sentence would be:
"Updates the files in the working tree that are different between
<commit> and HEAD, but keeps those which are different between the
index and working tree, and finally resets the index."
Or something along those lines.
Philippe
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Matthieu Moy @ 2011-11-23 8:49 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
Philippe Vaucher <philippe.vaucher@gmail.com> writes:
> A lot of time when I want to use reset for smth else than "--hard" I
> have to go and look the documentation.
I have to agree with this, I took a lot of time to understand/memorize
the meaning of reset options.
> Optional: a new mode would be introduced for consistency:
> --worktree (or maybe --tree): only updates the worktree but not the index
That would be an alias for "git checkout <rev> -- path", right?
I don't really like this "there is more than one way to do it" in Git's
command-line, I think we should think very carefully before introducing
yet another instance of it.
> --keep could be removed in favor of an additional --safe flag
If you are to change the option names, then you should also make the
behavior safe by default:
* "git reset --all" = "git reset --keep"
* "git reset --all --force" = "git reset --hard"
With the current terminology, --hard has the advantage that it makes it
realatively clear how dangerous it is. Still, I've seen users losing
data because they did a "git reset --hard" with uncommited changes. Git
is safe by default most of the time, and "git reset --hard" is one
unfortunate exception (because it was there before --keep, people are
more used to it).
"git reset --all" would make it worse, because the option name is less
scary, people would be less reluctant to use it, and would get more
chance to lose data.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Fix revert --abort on Windows
From: Johannes Sixt @ 2011-11-23 8:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111123012721.GA14217@elie.hsd1.il.comcast.net>
From: Johannes Sixt <j6t@kdbg.org>
On Windows, it is not possible to rename or remove a directory that has
open files. 'revert --abort' renamed .git/sequencer when it still had
.git/sequencer/head open. Close the file as early as possible to allow
the rename operation on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I guess it's too late to squash this in. ;)
-- Hannes
builtin/revert.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 0c61668..5dedb51 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -931,8 +931,10 @@ static int sequencer_rollback(struct replay_opts *opts)
if (strbuf_getline(&buf, f, '\n')) {
error(_("cannot read %s: %s"), filename, ferror(f) ?
strerror(errno) : _("unexpected end of file"));
+ fclose(f);
goto fail;
}
+ fclose(f);
if (get_sha1_hex(buf.buf, sha1) || buf.buf[40] != '\0') {
error(_("stored pre-cherry-pick HEAD file '%s' is corrupt"),
filename);
@@ -941,11 +943,9 @@ static int sequencer_rollback(struct replay_opts *opts)
if (reset_for_rollback(sha1))
goto fail;
strbuf_release(&buf);
- fclose(f);
return 0;
fail:
strbuf_release(&buf);
- fclose(f);
return -1;
}
--
1.7.8.rc3.1164.gba869.dirty
^ permalink raw reply related
* Re: Possible bug with branch names and case sensitivity
From: Michael Haggerty @ 2011-11-23 8:54 UTC (permalink / raw)
To: Jay Soffian; +Cc: Gerd Knops, git, Junio C Hamano
In-Reply-To: <CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com>
On 11/22/2011 06:31 PM, Jay Soffian wrote:
> I wonder what the downside would be of always using packed refs on
> case-insenstive file systems. This would seem analogous to how git no
> longer uses symlinks.
The theoretical downside is that when the total number of packed refs is
very large, it is more expensive to access or change a single ref if it
is packed than if it is loose (because the whole packed refs file has to
be read, parsed, then rewritten, and thus scales like O(N)). OTOH the
number of references must be quite large before loose references win,
because the constant factor for loose references is much larger than
that for packed references. I also believe that there is still scope
for optimizing the handling of packed references to make them yet faster
and perhaps even improve their scaling.
But I think that a lot of code would have to change to make this happen.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git reset --merge documentation improvments
From: Vincent van Ravesteijn @ 2011-11-23 8:57 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr59bN8rjhLHAK0Vq=bOBBHG=N02CgGe-np=OBdTyS+rsA@mail.gmail.com>
Op 23-11-2011 9:31, Philippe Vaucher schreef:
> Hello,
>
> The current documentation for --merge is:
>
> "Resets the index [1] and updates the files in the working tree that
> are different between<commit> and HEAD, but keeps those which are
> different between the index [2] and working tree"
>
> I think this is confusing, because [1] is the *after-reset* index and
> [2] is the *before-reset* index.
You mean that you read that the *after-reset* index is reset ? They both
refer to the *before-reset* index.
> If you fail to realise this it looks
> like this "resets index (so index is empty) and then updates worktree
> but skip files staged from index" --> "but there's nothing staged, the
> index was reset!"
The misunderstanding comes from the added "then".
>
> I think a better sentence would be:
>
> "Updates the files in the working tree that are different between
> <commit> and HEAD, but keeps those which are different between the
> index and working tree, and finally resets the index."
There is nothing to update as long as the index is not reset.
Vincent
^ permalink raw reply
* Re: [ANN] SubGit Early Access Program Build #789
From: Andreas Ericsson @ 2011-11-23 9:03 UTC (permalink / raw)
To: Semen Vadishev; +Cc: jgit-dev, EGit developer discussion, Git Mailing List
In-Reply-To: <4ECBF4EF.7070705@tmatesoft.com>
On 11/22/2011 08:15 PM, Semen Vadishev wrote:
> Hello All,
>
> Let me introduce our new project: SubGit (http://subgit.com/).
>
> SubGit is a tool for smooth migration from Subversion to Git. As well as
> from Git to Subversion. Without git-svn insanity.
>
> It works like this:
>
> - Install SubGit into your repository on the server side
>
> - Let initial translation complete (time depends on the size of repository)
>
> - SubGit installs hooks into repository, so it translates every svn
> revision and git commit
>
> - Committers may now use either Git or Subversion (or both) with the
> tools of their choice
>
How does it handle merges?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* git fetch overwriting local tags
From: Uwe Kleine-König @ 2011-11-23 9:08 UTC (permalink / raw)
To: git; +Cc: John Kacur
Hello,
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git tag some_tag
git fetch --tags ../a
After that I have:
git log -1 --oneline some_tag
c4ad89a some commit log
so b's tag was overwritten.
Is this intended?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Michael Haggerty @ 2011-11-23 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <7vwrasdp3t.fsf@alter.siamese.dyndns.org>
On 11/22/2011 06:49 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> Currently git handles references names case-sensitively and allows
>> multiple reference names that differ only in case.
>
> We do the same for in-tree paths, by the way. Ultimately, I think the
> sane thing to do is to appeal to the user's common sense. [...common
> sense aka "if it hurts don't do it" omitted...]
>
> I think refnames have exactly the same issue. In theory, you could have
> "Master" and "master" branches, and nothing stops you from trying to do
> so, but in practice, if it is not useful for you and your project, and
> if it is equally fine to use some other name instead of "Master" for the
> purpose of you and your project, then there is no strong reason for doing
> so, unless you are trying to irritate users on case folding platforms.
I agree.
But git could nevertheless help users (1) by providing config settings
or hook scripts or something that could be configured in a repository to
prevent case-conflicts from entering the project history; (2) by
emitting an error when such a conflict arises rather than getting so
confused.
Note that Unicode encoding differences can cause very similar problems
(even assuming utf8, there can be multiple ways to encode the same
string) and should maybe be addressed similarly.
By the way, I'm not volunteering for this project; case-sensitive
ASCII's good enough for me :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Jonathan Nieder @ 2011-11-23 10:04 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <4ECCB3A2.5030102@viscovery.net>
Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> On Windows, it is not possible to rename or remove a directory that has
> open files. 'revert --abort' renamed .git/sequencer when it still had
> .git/sequencer/head open. Close the file as early as possible to allow
> the rename operation on Windows.
Nice catch.
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Speaking of which, it doesn't make a lot of sense for "git revert
--abort" to be leaving a .git/sequencer-old directory around. How
about this on top?
-- >8 --
Subject: revert --abort: do not leave behind useless sequencer-old directory
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident. cherry-pick --abort is designed to
work in three steps:
1) find which commit to roll back to
2) call "git reset --merge <commit>" to move to that commit
3) remove the .git/sequencer directory
But the careless author forgot step 3 entirely. The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.
By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking. Remove
the (renamed) .git/sequencer directory as intended all along.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
By the way, as the length of the second-to-last paragraph above might
have hinted, I am not convinced that allowing "git reset --hard" as an
escape route from a cherry-pick sequence was very sensible. It
_would_ be nice to have a command to return to a known state,
discarding progress in all pending multiple-command guided workflows
(am, rebase, bisect), but git reset is not that command.
builtin/revert.c | 1 +
t/t7106-reset-sequence.sh | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5dedb51c..818b4abb 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -942,6 +942,7 @@ static int sequencer_rollback(struct replay_opts *opts)
}
if (reset_for_rollback(sha1))
goto fail;
+ remove_sequencer_state(1);
strbuf_release(&buf);
return 0;
fail:
diff --git a/t/t7106-reset-sequence.sh b/t/t7106-reset-sequence.sh
index 3f86e8c5..83f7ea59 100755
--- a/t/t7106-reset-sequence.sh
+++ b/t/t7106-reset-sequence.sh
@@ -41,4 +41,12 @@ test_expect_success 'reset --hard cleans up sequencer state, providing one-level
test_path_is_missing .git/sequencer-old
'
+test_expect_success 'cherry-pick --abort does not leave sequencer-old dir' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick base..anotherpick &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_path_is_missing .git/sequencer-old
+'
+
test_done
--
1.7.8.rc3
^ permalink raw reply related
* Re: [PATCH] Fix revert --abort on Windows
From: Johannes Sixt @ 2011-11-23 10:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111123100452.GA30629@elie.hsd1.il.comcast.net>
Am 11/23/2011 11:04, schrieb Jonathan Nieder:
> ... "git reset --merge <commit>" renames the
> .git/sequencer directory as a secondary effect --- after moving to
> <commit>, or so the logic goes, it is unlikely but possible that the
> caller of git reset wants to continue the series of cherry-picks that
> was in progress, so git renames the sequencer state to
> .git/sequencer-old to be helpful while allowing the cherry-pick to be
> resumed if the caller did not want to end the sequence after all.
> ...
> By the way, as the length of [this paragraph] might
> have hinted, I am not convinced that allowing "git reset --hard" as an
> escape route from a cherry-pick sequence was very sensible. It
> _would_ be nice to have a command to return to a known state,
> discarding progress in all pending multiple-command guided workflows
> (am, rebase, bisect), but git reset is not that command.
IMO, it doesn't make sense that git-reset aborts a cherry-pick sequence:
When I messed up a difficult conflict in the middle of a cherry-pick
sequence, it might be useful to be able to 'git reset --hard && git
cherry-pick that-one-commit' to restart the conflict resolution.
(But does a single-commit cherry-pick during a multi-commit cherry-pick
work to begin with?)
-- Hannes
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: David Aguilar @ 2011-11-23 11:20 UTC (permalink / raw)
To: Stefan Näwe; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <4ECBBD72.40101@atlas-elektronik.com>
On Tue, Nov 22, 2011 at 7:19 AM, Stefan Näwe
<stefan.naewe@atlas-elektronik.com> wrote:
> Am 22.11.2011 11:24, schrieb David Aguilar:
>>
>> git-cola has this feature.
>>>
>>
>> http://git-cola.github.com/
>
> Yeah, right. I totally forgot about git cola.
>
> But I guess there's no way of starting only the stash view like the 'DAG'
> view, is there ?
That's a good idea.
https://github.com/git-cola/git-cola/commit/0b1bf59c0b4a455cc8a9149dcfcafb5bed3a19ab
git cola stash
git cola classic
(and a few others)
...
--
David
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-23 11:24 UTC (permalink / raw)
To: David Aguilar; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <CAJDDKr78CV+eDrfSg4Tqp5W2N4MDTaqAcxiB5JrNpUyEn5vqAQ@mail.gmail.com>
Am 23.11.2011 12:20, schrieb David Aguilar:
> On Tue, Nov 22, 2011 at 7:19 AM, Stefan Näwe
> <stefan.naewe@atlas-elektronik.com> wrote:
>> Am 22.11.2011 11:24, schrieb David Aguilar:
>>>
>>> git-cola has this feature.
>>>>
>>>
>>> http://git-cola.github.com/
>>
>> Yeah, right. I totally forgot about git cola.
>>
>> But I guess there's no way of starting only the stash view like the 'DAG'
>> view, is there ?
>
> That's a good idea.
>
> https://github.com/git-cola/git-cola/commit/0b1bf59c0b4a455cc8a9149dcfcafb5bed3a19ab
>
> git cola stash
> git cola classic
> (and a few others)
> ...
Perfetto!
Stefan
--
----------------------------------------------------------------
/dev/random says: Thesaurus: ancient reptile with an excellent vocabulary.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vfwhhgzcb.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> It dated back to f8a9d42 (read-tree: further loosen "working file will
>> be lost" check. - 2006-12-04) when you introduced --exclude-per-directory
>> to read-tree, but not --exclude-from to explicitly add .git/info/exclude.
>
> That one together with 1127148 (Loosen "working file will be lost" check
> in Porcelain-ish, 2006-12-04) complets the picture. Thanks for digging
> this out.
>
>> I guess it's time to add "read-tree --exclude-from".
>
> Perhaps, also --exclude-standard to match?
Yep, will do.
--
Duy
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 11:32 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4nxvusty.fsf@bauges.imag.fr>
>> Optional: a new mode would be introduced for consistency:
>> --worktree (or maybe --tree): only updates the worktree but not the index
>
> That would be an alias for "git checkout <rev> -- path", right?
Hum... yeah probably, what motivated me was that there's a way to
reset the index and not the worktree, but there's no way to reset the
worktree but not the index. I guess it's "checkout" as you pointed
out.
>> --keep could be removed in favor of an additional --safe flag
>
> If you are to change the option names, then you should also make the
> behavior safe by default:
>
> * "git reset --all" = "git reset --keep"
> * "git reset --all --force" = "git reset --hard"
Yes that's actually much better. Let's change my proposal to that.
Philippe
^ permalink raw reply
* Re: git reset --merge documentation improvments
From: Philippe Vaucher @ 2011-11-23 11:39 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git
In-Reply-To: <4ECCB565.9020706@lyx.org>
>> "Updates the files in the working tree that are different between
>> <commit> and HEAD, but keeps those which are different between the
>> index and working tree, and finally resets the index."
>
> There is nothing to update as long as the index is not reset.
Well then I simply don't understand what --merge does. Is it like
--keep but instead of failing when a file-to-be-overwritten has
changes it simply ignores the overwriting and continues?
Philippe
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vk46th5bz.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
"info/precious" might be a better name
> In the longer term, we should carefully determine if we need "precious" in
> the first place. The last time this was brought up there were people who
> argued they are OK with having to remove the ignored file by hand when
> checking out another branch (i.e. we switch the semantics of "ignored" so
> that they are "not tracked but all precious").
>
> I think it matters in two cases.
>
> (1) If you change an untracked "cruft" file on branch A into a directory
> with tracked files in it on another branch B. If you are on branch A,
> have that "cruft" file (perhaps it is a build product after running
> "make"), and try to checkout branch B, such an updated "git checkout"
> will start erroring out telling you that "cruft" will be lost.
>
> (2) If you have a directory on branch A, underneath of which there are
> untracked "cruft" files (e.g. think "build/" directory that is full
> of "*.o" files and ".gitignore" to mark object files as ignored but
> is otherwise empty), and another branch B that has the same path as a
> file. If you are on branch A, have "cruft" files in that directory,
> and try to checkout branch B, such an updated "git checkout" will
> start erroring out telling you that "cruft" will be lost.
I think we should do this regardless precious being added or not.
> If people are OK with such a behaviour, we can do without "precious".
What about git-clean to remove ignored but not precious files?
> Otherwise we would need to update excluded() in dir.c to return tristate
> (ignored, precious or unspecified) instead of the current boolean (ignored
> or unspecified), examine and decide for each caller what they want to do
> to "precious" files.
Or do excluded() twice, the first time to check for precious files,
the second for all ignored rules. Callers are changed anyway, but this
way git-add for example will be untouched because it does not care
about precious stuff. Only unpack-trees and maybe git-clean are
changed.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox