* 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
* 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: [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
* Re: [PATCH 5/3] revert: introduce --abort to cancel a failed cherry-pick
From: Junio C Hamano @ 2011-11-23 0:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122112001.GF7399@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> 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>
> ---
> ...
> @@ -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? Don't you also need another one to the test
after that one? When merged with rr/revert-cherry-pick series, t3510 seems
to misbehave around this area.
^ permalink raw reply
* Re: [PATCH 6/3] revert: remove --reset compatibility option
From: Junio C Hamano @ 2011-11-22 23:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122231145.GE6274@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> If we want to reach this point eventually, given that --reset was not in
>> any released version, and also given that we are deep in pre-release
>> phase, we probably should either just apply the first one (and perhaps
>> this one) from the series immediately before 1.7.8 final, or delay the
>> final and swallow the entire series.
>
> Makes sense.
Ok, then let's do the latter, and make tomorrow's pushout a 1.7.8-rc4; I
read the series over and they seem to make sense.
^ permalink raw reply
* Re: [PATCH 6/3] revert: remove --reset compatibility option
From: Jonathan Nieder @ 2011-11-22 23:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <7vzkfnde05.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> If we want to reach this point eventually, given that --reset was not in
> any released version, and also given that we are deep in pre-release
> phase, we probably should either just apply the first one (and perhaps
> this one) from the series immediately before 1.7.8 final, or delay the
> final and swallow the entire series.
Makes sense.
> I am not quite convinced that quit is *that* superiour over reset
> though. The description in 1/3 "has a confusing name" does not say why it
> is confusing, either, to help readers agree with the conclusion.
Ok, a few words about this.
I should say that I am not deeply attached to --quit. If some other
word for "abandon" (or some other concept entirely) is more obvious,
I'd be happy to see it used. From a couple of days of practice, I can
say that --quit feels fine in a way that --reset didn't, but not much
more.
--reset is a cognate to "git reset", the command to make some
combination of the HEAD, index, and worktree just so. In other
contexts --- rebooting a machine, resetting an alarm clock --- to
reset something also means to return it to a known state. By
contrast, the "git cherry-pick --abandon" command is about leaving the
state alone as much as possible while escaping from the context of a
cherry-pick sequence.
How does that do harm, though? My main fear is that people would not
notice that --reset is the option they want to use and would opt to
"rm -r .git/sequencer" instead, which is a kind of error-prone
wizardry that should not be required.
(I assume cherry-pick --reset was named by analogy with "git bisect
reset", the command to abandon a bisection and return to the branch
you were on before bisection, or a branch or commit named on the
command line. Which is not analagous to cherry-pick --abandon at
all. The command people often run, "git bisect reset HEAD", is a
closer analog if you squint right.)
^ permalink raw reply
* Re: [PATCH 6/3] revert: remove --reset compatibility option
From: Junio C Hamano @ 2011-11-22 21:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122112046.GG7399@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Remove the "git cherry-pick --reset" option, which has a different
> preferred spelling nowadays ("--quit"). Luckily the old --reset name
> was not around long enough for anyone to get used to it.
If we want to reach this point eventually, given that --reset was not in
any released version, and also given that we are deep in pre-release
phase, we probably should either just apply the first one (and perhaps
this one) from the series immediately before 1.7.8 final, or delay the
final and swallow the entire series.
I am not quite convinced that quit is *that* superiour over reset
though. The description in 1/3 "has a confusing name" does not say why it
is confusing, either, to help readers agree with the conclusion.
^ permalink raw reply
* Re: [PATCH 4/3] revert: write REVERT_HEAD pseudoref during conflicted revert
From: Thiago Farina @ 2011-11-22 21:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122111736.GE7399@elie.hsd1.il.comcast.net>
There seems to be something wrong with the subject. I says [4/3],
instead of [4/6]?
On Tue, Nov 22, 2011 at 9:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> When conflicts are encountered while reverting a commit, it can be
> handy to have the name of that commit easily available. For example,
> to produce a copy of the patch to refer to while resolving conflicts:
>
> $ git revert 2eceb2a8
> error: could not revert 2eceb2a8... awesome, buggy feature
> $ git show -R REVERT_HEAD >the-patch
> $ edit $(git diff --name-only)
>
> Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
> for cases like this. This also makes it possible for scripts to
> distinguish between a revert that encountered conflicts and other
> sources of an unmerged index.
>
> After successfully committing, resetting with "git reset", or moving
> to another commit with "git checkout" or "git reset", the pseudoref is
> no longer useful, so remove it.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> branch.c | 1 +
> builtin/commit.c | 1 +
> builtin/revert.c | 8 +++--
> t/t3507-cherry-pick-conflict.sh | 54 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index d8098762..025a97be 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -241,6 +241,7 @@ void create_branch(const char *head,
> void remove_branch_state(void)
> {
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_RR"));
> unlink(git_path("MERGE_MSG"));
> diff --git a/builtin/commit.c b/builtin/commit.c
> index c46f2d18..8f2bebec 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1514,6 +1514,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_MSG"));
> unlink(git_path("MERGE_MODE"));
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 1d112e4c..f5ba67a5 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -289,7 +289,7 @@ static char *get_encoding(const char *message)
> return NULL;
> }
>
> -static void write_cherry_pick_head(struct commit *commit)
> +static void write_cherry_pick_head(struct commit *commit, const char *pseudoref)
> {
> const char *filename;
> int fd;
> @@ -297,7 +297,7 @@ static void write_cherry_pick_head(struct commit *commit)
>
> strbuf_addf(&buf, "%s\n", sha1_to_hex(commit->object.sha1));
>
> - filename = git_path("CHERRY_PICK_HEAD");
> + filename = git_path(pseudoref);
> fd = open(filename, O_WRONLY | O_CREAT, 0666);
> if (fd < 0)
> die_errno(_("Could not open '%s' for writing"), filename);
> @@ -597,7 +597,9 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> * write it at all.
> */
> if (opts->action == CHERRY_PICK && !opts->no_commit && (res == 0 || res == 1))
> - write_cherry_pick_head(commit);
> + write_cherry_pick_head(commit, "CHERRY_PICK_HEAD");
> + if (opts->action == REVERT && ((opts->no_commit && res == 0) || res == 1))
> + write_cherry_pick_head(commit, "REVERT_HEAD");
>
> if (res) {
> error(opts->action == REVERT
> diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
> index cb45574a..ee1659c1 100755
> --- a/t/t3507-cherry-pick-conflict.sh
> +++ b/t/t3507-cherry-pick-conflict.sh
> @@ -253,6 +253,60 @@ test_expect_success 'revert also handles conflicts sanely' '
> test_cmp expected actual
> '
>
> +test_expect_success 'failed revert sets REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> +test_expect_success 'successful revert does not set REVERT_HEAD' '
> + pristine_detach base &&
> + git revert base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'revert --no-commit sets REVERT_HEAD' '
> + pristine_detach base &&
> + git revert --no-commit base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_cmp_rev base REVERT_HEAD
> +'
> +
> +test_expect_success 'revert w/dirty tree does not set REVERT_HEAD' '
> + pristine_detach base &&
> + echo foo > foo &&
> + test_must_fail git revert base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'GIT_CHERRY_PICK_HELP does not suppress REVERT_HEAD' '
> + pristine_detach initial &&
> + (
> + GIT_CHERRY_PICK_HELP="and then do something else" &&
> + GIT_REVERT_HELP="and then do something else, again" &&
> + export GIT_CHERRY_PICK_HELP GIT_REVERT_HELP &&
> + test_must_fail git revert picked
> + ) &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> +test_expect_success 'git reset clears REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + git reset &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'failed commit does not clear REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + test_must_fail git commit &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> test_expect_success 'revert conflict, diff3 -m style' '
> pristine_detach initial &&
> git config merge.conflictstyle diff3 &&
> --
> 1.7.8.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [msysGit] [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Vincent van Ravesteijn @ 2011-11-22 21:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, msysgit, gitster, kusmabite, Johannes.Schindelin
In-Reply-To: <4ECC04E3.70407@kdbg.org>
>> Is there any argument to not redirect stdout to "/dev/null" on all
>> platforms ?
> You paper over a crack in the wall. You hide a bug.
Luckily I'm still trying to find the crack and not ready to tape
anything yet.
Vincent
^ permalink raw reply
* Re: [msysGit] [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Johannes Sixt @ 2011-11-22 20:24 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: git, msysgit, gitster, kusmabite, Johannes.Schindelin
In-Reply-To: <4ECB4501.1060100@lyx.org>
Am 22.11.2011 07:45, schrieb Vincent van Ravesteijn:
>>> To prevent the crash and to prevent git from writing cruft into the
>>> patch
>>> file, we do not close stdout, but redirect it to "nul" instead.
>> A more robust solution is to add invalidcontinue.obj to the linker
>> command line. This installs an invalid argument handler that does not
>> abort, and restores a sane behavior.
>
> This seems to work only for release builds or did I miss something ?
I cannot tell, but I would be surprised if that were the case. I didn't
test with debug builds (only our 'make MSVC=1' build). A cursory look at
the CRT source code does not show anything that would be different
between a debug and a release build regarding invalidcontinue.obj.
> Is there any argument to not redirect stdout to "/dev/null" on all
> platforms ?
You paper over a crack in the wall. You hide a bug.
-- Hannes
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-22 19:46 UTC (permalink / raw)
To: Daniele Segato; +Cc: Andrew Ardill, Git Mailing List, Jeff King
In-Reply-To: <1321977372.3289.38.camel@mastroc3.mobc3.local>
Daniele Segato <daniele.bilug@gmail.com> writes:
> Let me explain my idea with an example:
>
> An issue is discussed, a bug is acknowledged and a proposed solution is
> discussed, this all happen in the mailing list, like it always has.
>
> Someone in the "git management" (the one that usually choose how git
> should evolve) open a ticket, copy the relevant part of the mailing list
> (or link to the discussion in the archive) and (optionally) place the
> bug / feature / enhancement into a roadmap / milestone
This step I wouldn't buy, if you count me as part of "management".
But I suspect that curation of issues, prodding parties involved and
closing inactive/stale ones can be done by volunteer project secretaries
without requiring an authority to choose how git should evolve.
cf. http://thread.gmane.org/gmane.comp.version-control.git/110117/focus=110129
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-22 19:41 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List, Junio C Hamano, Jeff King
In-Reply-To: <1321970646.3289.19.camel@mastroc3.mobc3.local>
Daniele Segato <daniele.bilug@gmail.com> writes:
> [1] according to http://git-scm.com/ the link on "Git source repository"
> is https://github.com/gitster/git
That one is as official as anybody's "git clone" from many of the
distribution points.
I do not see any reason to name an official repository, but if I were
pressed, that copy at github is not the one I would nominate.
^ permalink raw reply
* [ANN] SubGit Early Access Program Build #789
From: Semen Vadishev @ 2011-11-22 19:15 UTC (permalink / raw)
To: jgit-dev, EGit developer discussion, Git Mailing List
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
SubGit uses JGit to work with the Git stuff. JGit handles heavy load
perfectly thus fitting our needs, and we appreciate efforts JGit
community put into this excellent library. Thank you, guys!
SubGit EAP builds are free to use, you may try these and let us know
what do you miss, so that we make sure that all the features you need
are included into the final version of SubGit.
SubGit works on Linux, Windows or OS X and requires Java 5 or newer.
Download new SubGit EAP build from http://subgit.com/ and follow us at
@subgit and +subgit.
--
Semen Vadishev,
TMate Software,
http://subgit.com/ - Two Way Ticket to The Dark Side
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Junio C Hamano @ 2011-11-22 18:29 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Pascal Obry, Git Mailing List
In-Reply-To: <4ECB8917.8010305@ira.uka.de>
Holger Hellmuth <hellmuth@ira.uka.de> writes:
> (see "Bug report - local (and git ignored) file silently removed after
> checkout" on the mailing list why exclude is better than .gitignore at
> the moment)
Don't look at it or encourage people to rely on that bug to be
fixed. exclude and .gitignore should behave the same way.
^ permalink raw reply
* Re: [PATCH] Documentation update for 'git branch --list'
From: Junio C Hamano @ 2011-11-22 18:04 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, git
In-Reply-To: <4ECB43E4.7030607@lyx.org>
Vincent van Ravesteijn <vfr@lyx.org> writes:
> Op 21-11-2011 18:37, Junio C Hamano schreef:
> ...
>> It is natural to expect "git branch --merged pu vr/\*" to list branches
>> that are contained in 'pu' whose names match the given pattern, but it
>> seems to try creating a branch called "vr/*" and fails, for example.
>
> If this is what you naturally would expect, I would expect the
> following "git branch vr/*" to work as well.
> What would you say if we try to interpret the argument as a pattern
> when the argument is not a valid ref name?
We don't, as that is inviting mistakes. "git branch vr/*" if you have a
vr/ directory in your working tree may create vr/a branch from where the
tip of vr/b points at by mistake.
The "--merged" option is an explicit clue that the user is not interested
in creating new branch, and the string being a pattern is additional clue.
The "--list" option was recently added for the explicit purpose of giving
such a clue as safety measure.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-22 18:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
I do not see a strong enough reason to be that draconian.
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
If you make it conditional, it should be per-project, not per-repository.
You may be participating in a cross platform project and you may happen to
be on the case-sensitive system, but absense of such a check for you may
end up hurting other participants who work on a case-insensitive one.
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
I do not see it is worth the effort. If you were to expend much effort
then I could see in the longer term (now I am talking about Git 2.0 in
this paragraph) one solution is to remove on-filesystem $GIT_DIR/refs/
hierarchy, put it in a trivial database of some sort, keyed with case
sensitive strings.
The transfer of refs over the wire will stay case sensitive so such a
change would be purely local to the repository, so transition would only
matter if you network mount a new style repository and attempt to use with
older version of Git.
If you go that route, we still would need to think about how to deal with
the $GIT_DIR/logs/ hierarchy, though.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-22 17:49 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Is it obvious how references *should* be handled on case-insensitive
> filesystems? It's certainly not obvious to me (has it been discussed
> elsewhere?) I don't think it is a good idea to "fix" this one problem
> without defining an overall policy.
Thanks for a very sane comment.
> 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. In a project
where its participants may use, or in a project that is about, a platform
where a case-folding filesystem is the default choice, the project would
avoid in-tree paths that are different only in case and would not have
xt_TCPMSS.c and xt_tcpmss.c at the same time. Even though Git allows you
on such a platform to add case-conflicting pair of paths by using
"update-index --cacheinfo", people would not do that, because it is not a
useful thing to do. And Git by default does not forbid recording such pair
of paths, as projects for whatever reason may want to use such pair of
paths if they know its participants can deal with case sensitivity just
fine.
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.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Jay Soffian @ 2011-11-22 17:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
On Tue, Nov 22, 2011 at 12:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Is it obvious how references *should* be handled on case-insensitive
> filesystems? It's certainly not obvious to me (has it been discussed
> elsewhere?) I don't think it is a good idea to "fix" this one problem
> without defining an overall policy.
Indeed, I hadn't thought this through very well at all. My initial
take was just that if I were on a case-insensitive file system, I
don't get to have references that differ only in case. This is of
course quite short-sighted in a distributed VCS. :-(
> Currently git handles references names case-sensitively and allows
> multiple reference names that differ only in case. If this behavior is
> to be preserved on case-insensitive filesystems, then either loose
> references must be stored differently (e.g., multiple references in the
> same file) or ambiguous references need always to be packed. Moreover,
> given a refname, we would need to be careful not to just try to open a
> file with that name and assume that it is the correct reference; rather,
> we would have to ask the filesystem for the name of the file in its
> original case and make sure that it agrees with the case of the refname
> that we seek.
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.
> By the way, this could have ramifications for the recently-added test
> that top-level refnames should be in ALL_CAPS.
>
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
>
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
>
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
>
> The above all assumes a case-insensitive filesystem that is
> *case-preserving*. If we want to support filesystems that do not
> preserve case, things get even more complicated.
>
> And if we want to pretend to support non-ASCII refnames, then the issue
> of encodings is another nasty can of worms...
These all seem like sub-optimal things to do if we can just always
used packed refs.
j.
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 17:29 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECBCA4F.5090505@ira.uka.de>
Holger,
> In my not-really-expert opinion no. At least git diff master has to show
> something because there obviously is a difference between what is in
> master (that you can't gitignore) and your branch (whether you ignore it
> or not).
I had come to the same conclusion. Sad, it would have been nice to have
an option to fully ignore a path in a repository.
Anyway, thanks a lot for your feedback.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Holger Hellmuth @ 2011-11-22 16:14 UTC (permalink / raw)
To: pascal; +Cc: Git Mailing List
In-Reply-To: <4ECBBDE3.3010904@obry.net>
On 22.11.2011 16:21, Pascal Obry wrote:
> In fact I want to do that in a branch (say work) and keep master as-is
> as this branch is used to pull changes from origin. And in this case,
> doing 'git diff master' still shows the files under src2. See script to
> reproduce:
[...]
> # let's replace src2 by sd in branch work
>
> git checkout -b work
> git rm src2/*
> git ci -m "no more src2"
> # ln -s ../sd src2
> cp -r ../sd src2
>
> # make sure src2 is excluded
>
> echo 'src2'>> .git/info/exclude
>
> # the following output should be clean
>
> echo '============== Status'
> git status
>
> echo '============== Diff'
> git diff
>
> echo '============== Diff master'
> git diff master
>>>
>
> Is that possible?
>
In my not-really-expert opinion no. At least git diff master has to show
something because there obviously is a difference between what is in
master (that you can't gitignore) and your branch (whether you ignore it
or not).
I would
a) use a different directory name for src2 and adapt the Makefile to
cope with that
or
b) remove the src2 link from .git/info/exclude and commit it into the
branch. That way whenever you switch branch and master, the correct dir
or link will be present and still because of the link none of the files
in the svn will be handled by git in any way
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Daniele Segato @ 2011-11-22 15:56 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Git Mailing List, Junio C Hamano, Jeff King
In-Reply-To: <CAH5451==iXuB=QPW7bQvahB-jMnKC2axJYnW2OfFq=UNO9U6mg@mail.gmail.com>
On Wed, 2011-11-23 at 01:29 +1100, Andrew Ardill wrote:
> > Since the *official* repo is now hosted on github, why don't making
> use
> > of the github ticketing system? [1]
>
> From memory, only members of an organisation/owner of an account can
> manage tickets on github. This would be difficult to organise for
> git.
Well... Actually I think the mailing list works pretty well.
And the ticketing system would only be useful to use as a shared TODO
list.
Let me explain my idea with an example:
An issue is discussed, a bug is acknowledged and a proposed solution is
discussed, this all happen in the mailing list, like it always has.
Someone in the "git management" (the one that usually choose how git
should evolve) open a ticket, copy the relevant part of the mailing list
(or link to the discussion in the archive) and (optionally) place the
bug / feature / enhancement into a roadmap / milestone
If the issue is not assigned anyone can see it and come by in the email
with a patch proposal.
This is just an idea, I can't propose myself to such a job, I wouldn't
be able to provide the appropriate support to it.
> > You probably already discussed this tons of times but I can't figure
> out
> > how you are gonna remember to do something if you don't have a
> roadmap
> > and a ticketing system that allow you to trace the bugs and
> features.
> We have previously discussed this, and it boils down to "if someone
> can ensure it is maintained, let's do it". So far no-one has put their
> hand up and there is a fear of the system becoming clogged with many
> issues that are not maintained.
I see, I can understand why, it's hard to just find the time to read all
the messages in this mailing list.
Regards,
Daniele Segato
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 15:21 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECBBAD4.6080206@ira.uka.de>
Holger,
> You should also remove src2 and all files in it from the git repository.
> Something like
>
> git rm -r src2
> git ci
> echo 'src2' >> .git/info/exclude
>
> instead of
>
> rm -fr src2
> echo 'src2/*' >> .git/info/exclude
Thanks this is working indeed. But it was not the whole story :)
In fact I want to do that in a branch (say work) and keep master as-is
as this branch is used to pull changes from origin. And in this case,
doing 'git diff master' still shows the files under src2. See script to
reproduce:
<<
#!/bin/sh
# create sd (directory that will replace src2)
mkdir sd
echo sd1 > sd/file1
echo sd2 > sd/file2
# create Git repo
mkdir repo
cd repo
git init
mkdir src1
mkdir src2
echo file > src1/file
echo 3 > src2/file3
git add .
git ci -a -m "first"
# let's replace src2 by sd in branch work
git checkout -b work
git rm src2/*
git ci -m "no more src2"
# ln -s ../sd src2
cp -r ../sd src2
# make sure src2 is excluded
echo 'src2' >> .git/info/exclude
# the following output should be clean
echo '============== Status'
git status
echo '============== Diff'
git diff
echo '============== Diff master'
git diff master
>>
Is that possible?
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-22 15:19 UTC (permalink / raw)
To: David Aguilar; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <-8099236111493298698@unknownmsgid>
Am 22.11.2011 11:24, schrieb David Aguilar:
> On Nov 21, 2011, at 4:41 AM, dexen deVries <dexen.devries@gmail.com> wrote:
>
>> On Monday 21 of November 2011 11:53:03 Stefan Näwe wrote:
>>> You can simply put the following in your ~/.gitconfig:
>>>
>>> [guitool "Stash/show"]
>>> cmd = git stash show -p
>>> [guitool "Stash/list"]
>>> cmd = git stash list
>>> [guitool "Stash/pop"]
>>> cmd = git stash pop
>>> [guitool "Stash/drop"]
>>> cmd = git stash drop
>>> confirm = yes
>>
>> that's nice, but doesn't list visually the stashed changes. I'd rather have a
>> listing similar to Unstanged Changes / Staged Changes, with ability to view
>> line-by-line diff just like for Changes.
>
> [blatant plug]
>
> 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 ?
Stefan
--
----------------------------------------------------------------
/dev/random says: This is a Tagline mirror><rorrim enilgaT a si sihT
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Holger Hellmuth @ 2011-11-22 15:08 UTC (permalink / raw)
To: pascal; +Cc: Git Mailing List
In-Reply-To: <4ECBAFB7.9040505@obry.net>
On 22.11.2011 15:20, Pascal Obry wrote:
>
> Holger,
>
>> Remove SD in P1, make a logical link from P2 to SD, add SD to
>> .git/info/exclude
>
> Thanks for your quick reply. That's what I have tested but...
>
>> (see "Bug report - local (and git ignored) file silently removed after
>> checkout" on the mailing list why exclude is better than .gitignore at
>> the moment)
>
> Seems like this is working only if file names are different. This is not
> my case as the replacement is very similar. With the following script
> I'm expecting empty status and no diff:
>
> <<
> #!/bin/sh
>
> # create sd (directory that will replace src2)
> mkdir sd
> echo sd1> sd/file1
> echo sd2> sd/file2
>
> # create Git repo
> mkdir repo
> cd repo
> git init
> mkdir src1
> mkdir src2
> echo file> src1/file
> echo 3> src2/file3
> git add .
> git ci -a -m "first"
>
> # let's replace src2 by sd
>
> rm -fr src2
> # ln -s ../sd src2
> cp -r ../sd src2
>
> # make sure src2 is excluded
>
> echo 'src2/*'>> .git/info/exclude
>
> # the following output should be clean
You should also remove src2 and all files in it from the git repository.
Something like
git rm -r src2
git ci
echo 'src2' >> .git/info/exclude
instead of
rm -fr src2
echo 'src2/*' >> .git/info/exclude
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 14:20 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECB8917.8010305@ira.uka.de>
Holger,
> Remove SD in P1, make a logical link from P2 to SD, add SD to
> .git/info/exclude
Thanks for your quick reply. That's what I have tested but...
> (see "Bug report - local (and git ignored) file silently removed after
> checkout" on the mailing list why exclude is better than .gitignore at
> the moment)
Seems like this is working only if file names are different. This is not
my case as the replacement is very similar. With the following script
I'm expecting empty status and no diff:
<<
#!/bin/sh
# create sd (directory that will replace src2)
mkdir sd
echo sd1 > sd/file1
echo sd2 > sd/file2
# create Git repo
mkdir repo
cd repo
git init
mkdir src1
mkdir src2
echo file > src1/file
echo 3 > src2/file3
git add .
git ci -a -m "first"
# let's replace src2 by sd
rm -fr src2
# ln -s ../sd src2
cp -r ../sd src2
# make sure src2 is excluded
echo 'src2/*' >> .git/info/exclude
# the following output should be clean
echo '============== Status'
git status
echo '============== Diff'
git diff
>>
But the output is actually:
Initialized empty Git repository in /home/obry/tmp/repo/.git/
[master (root-commit) 527c7a1] first
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 src1/file
create mode 100644 src2/file3
cp: cannot stat `../src': No such file or directory
============== Status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# deleted: src2/file3
#
no changes added to commit (use "git add" and/or "git commit -a")
============== Diff
diff --git a/src2/file3 b/src2/file3
deleted file mode 100644
index 00750ed..0000000
--- a/src2/file3
+++ /dev/null
@@ -1 +0,0 @@
-3
Any other idea?
Thanks.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ 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