* [PATCH v3] builtin-push: add --delete as syntactic sugar for :foo
From: Jan Krüger @ 2009-12-30 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Git ML, Sverre Rabbelier
In-Reply-To: <7vvdfpg1je.fsf@alter.siamese.dyndns.org>
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
git push origin --delete tag sometag
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line, and will refuse to accept refspecs with
colons to prevent undue confusion.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Junio C Hamano <gitster@pobox.com> wrote:
> namely, (1) barf and abort if src:dst is given; (2) touch only refs
> given from the command line, "push there --delete" without any
> refspec is an error; (3) be careful about "git push there tag v1.0.0"
> form.
>
> So if Jan or Sverre want to resurrect the topic, I am all for it.
Alrighty. I assume by (3) you meant that it should be possible to use
something like "push there --delete tag v1.0.0". Version 3 of the patch
adds this, and it also includes updated tests and (brief) documentation.
Documentation/git-push.txt | 4 ++++
builtin-push.c | 26 +++++++++++++++++++++++---
t/t5516-fetch-push.sh | 16 ++++++++++++++++
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 52c0538..e3eb1e8 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -91,6 +91,10 @@ nor in any Push line of the corresponding remotes file---see below).
will be tab-separated and sent to stdout instead of stderr. The full
symbolic names of the refs will be given.
+--delete::
+ All listed refs are deleted from the remote repository. This is
+ the same as prefixing all refs with a colon.
+
--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
diff --git a/builtin-push.c b/builtin-push.c
index dcfb53f..f7661d2 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -15,6 +15,7 @@ static const char * const push_usage[] = {
};
static int thin;
+static int deleterefs;
static const char *receivepack;
static const char **refspec;
@@ -39,11 +40,24 @@ static void set_refspecs(const char **refs, int nr)
if (nr <= ++i)
die("tag shorthand without <tag>");
len = strlen(refs[i]) + 11;
- tag = xmalloc(len);
- strcpy(tag, "refs/tags/");
+ if (deleterefs) {
+ tag = xmalloc(len+1);
+ strcpy(tag, ":refs/tags/");
+ } else {
+ tag = xmalloc(len);
+ strcpy(tag, "refs/tags/");
+ }
strcat(tag, refs[i]);
ref = tag;
- }
+ } else if (deleterefs && !strchr(ref, ':')) {
+ char *delref;
+ int len = strlen(ref)+1;
+ delref = xmalloc(len);
+ strcpy(delref, ":");
+ strcat(delref, ref);
+ ref = delref;
+ } else if (deleterefs)
+ die("--delete only accepts plain target ref names");
add_refspec(ref);
}
}
@@ -196,6 +210,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+ OPT_BOOLEAN( 0, "delete", &deleterefs, "delete refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
@@ -209,6 +224,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
+ die("--delete is incompatible with --all, --mirror and --tags");
+ if (deleterefs && argc < 2)
+ die("--delete doesn't make sense without any refs");
+
if (tags)
add_refspec("refs/tags/*");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 516127b..a17666c 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -547,6 +547,22 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'allow deleting a ref using --delete' '
+ mk_test heads/master &&
+ (cd testrepo && git config receive.denyDeleteCurrent warn) &&
+ git push testrepo --delete master &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/heads/master)
+'
+
+test_expect_success 'allow deleting a tag using --delete' '
+ mk_test heads/master &&
+ git tag -a -m dummy_message deltag heads/master &&
+ git push testrepo --tags &&
+ (cd testrepo && git rev-parse --verify -q refs/tags/deltag) &&
+ git push testrepo --delete tag deltag &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/tags/deltag)
+'
+
test_expect_success 'warn on push to HEAD of non-bare repository' '
mk_test heads/master
(cd testrepo &&
--
1.6.6.60.gc2ff1
^ permalink raw reply related
* [PATCH] textconv: stop leaking file descriptors
From: Jeff King @ 2009-12-30 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We read the output from textconv helpers over a pipe, but we
never actually closed our end of the pipe after using it.
Signed-off-by: Jeff King <peff@peff.net>
---
This should go onto 'maint'. Now I'll just go find a brown paper bag...
diff.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index d14a575..aad4b39 100644
--- a/diff.c
+++ b/diff.c
@@ -3823,11 +3823,13 @@ static char *run_textconv(const char *pgm, struct diff_filespec *spec,
if (start_command(&child) != 0 ||
strbuf_read(&buf, child.out, 0) < 0 ||
finish_command(&child) != 0) {
+ close(child.out);
strbuf_release(&buf);
remove_tempfile();
error("error running textconv command '%s'", pgm);
return NULL;
}
+ close(child.out);
remove_tempfile();
return strbuf_detach(&buf, outsize);
--
1.6.6.320.g7c9b3
^ permalink raw reply related
* [PATCH] reset: unbreak hard resets with GIT_WORK_TREE
From: Jeff King @ 2009-12-30 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fyn Fynn, Nguyen Thai Ngoc Duy, Nanako Shiraishi, git
In-Reply-To: <20091229215015.GA1529@coredump.intra.peff.net>
Commit 952dfc6 tried to tighten the safety valves for doing
a "reset --hard" in a bare repository or outside the work
tree, but accidentally broke the case for GIT_WORK_TREE.
This patch unbreaks it.
Most git commands which need a work tree simply use
NEED_WORK_TREE in git.c to die before they get to their
cmd_* function. Reset, however, only needs a work tree in
some cases, and so must handle the work tree itself. The
error that 952dfc6 made was to simply forbid certain
operations if the work tree was not set up; instead, we need
to do the same thing that NEED_WORK_TREE does, which is to
call setup_work_tree(). We no longer have to worry about dying
in the non-worktree case, as setup_work_tree handles that
for us.
Signed-off-by: Jeff King <peff@peff.net>
---
Junio, this should probably go onto maint. I based it directly on
952dfc6, which is in v1.6.6 and v1.6.5.5.
builtin-reset.c | 6 ++----
t/t7103-reset-bare.sh | 6 ++++++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 11d1c6e..e4418bc 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -286,10 +286,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (reset_type == NONE)
reset_type = MIXED; /* by default */
- if ((reset_type == HARD || reset_type == MERGE)
- && !is_inside_work_tree())
- die("%s reset requires a work tree",
- reset_type_names[reset_type]);
+ if (reset_type == HARD || reset_type == MERGE)
+ setup_work_tree();
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
index 68041df..afb55b3 100755
--- a/t/t7103-reset-bare.sh
+++ b/t/t7103-reset-bare.sh
@@ -29,6 +29,12 @@ test_expect_success 'soft reset is ok' '
(cd .git && git reset --soft)
'
+test_expect_success 'hard reset works with GIT_WORK_TREE' '
+ mkdir worktree &&
+ GIT_WORK_TREE=$PWD/worktree GIT_DIR=$PWD/.git git reset --hard &&
+ test_cmp file worktree/file
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
--
1.6.6.320.g7c9b3
^ permalink raw reply related
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Junio C Hamano @ 2009-12-30 8:45 UTC (permalink / raw)
To: Mike Hommey; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20091230080002.GA31088@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Fri, Nov 27, 2009 at 10:28:38AM -0800, Junio C Hamano wrote:
>> Mike Hommey <mh@glandium.org> writes:
>> ...
>> > Then it's fine. But shouldn't that be noted somewhere, like in the
>> > INSTALL file ?
>>
>> Surely. Please make it so.
>
> I had another idea in the interim. If GNU make is necessary, why not
> make the Makefile an explicit GNU make only Makefile, by renaming it
> GNUmakefile ?
>
> That wouldn't remove the need to add a note in the INSTALL file, though.
I think you answered the question yourself.
Personally, when I am dealing with other people's projects, I dislike ones
that do not name their own Makefile "Makefile", as I traditionally have
done my local customization by having a higher precedence Makefile
("makefile" in the old world order, or "GNUmakefile" for gmake) that sets
things up and then call into upstream "Makefile". For this project, since
I am the upstream, I do want to keep the file named "Makefile".
^ permalink raw reply
* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Gisle Aas @ 2009-12-30 8:17 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, gitster, Gisle Aas
In-Reply-To: <fabb9a1e0912290606ib1f2e46y1ddbae9aa68e5194@mail.gmail.com>
On Dec 29, 2009, at 15:06, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Dec 29, 2009 at 06:51, Gisle Aas <gisle.aas@it.uib.no> wrote:
>> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
>> +{
>> + if (p != sb->buf) {
>> + strbuf_reset(sb);
>> + strbuf_addstr(sb, p);
>> + }
>> + strbuf_insert(sb, 0, path_prefix, path_prefix_len);
>> + return sb->buf;
>> +}
>> +
>> static void file_change_m(struct branch *b)
>> {
>> const char *p = command_buf.buf + 2;
>> @@ -1909,6 +1921,8 @@ static void file_change_m(struct branch *b)
>> die("Garbage after path in: %s", command_buf.buf);
>> p = uq.buf;
>> }
>> + if (path_prefix)
>> + p = path_prefix_prepend(&uq, p);
>
> You could reduce the size of this change by having path_prefix_prepend
> check for path_prefix and just do nothing if it is not set.
I felt the explict test was better style -- more obvious that nothing happens to p
when there is no path_prefix.
--Gisle
^ permalink raw reply
* Re: [PATCH] Fix archive format with -- on the command line
From: Junio C Hamano @ 2009-12-30 8:11 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: René Scharfe, Miklos Vajna, Ilari Liusvaara, git
In-Reply-To: <20091230121309.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> "git archive HEAD non-existing-path" doesn't complain like "git
> add" does, and the patch is to fix it. No discussion.
It walks the tree twice, once for the checking and then another for doing
its real work. Doing that way obviously looks stupid and inefficient but
on the other hand it can fail before doing anything, which may be a big
plus. I couldn't decide the pros-and-cons at the moment.
Probably it is worth queuing the patch as is, and if there are motivated
people who want to, let them "optimize" it by rolling that check into the
main loop.
I dunno.
^ permalink raw reply
* Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy
From: Junio C Hamano @ 2009-12-30 8:06 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jeff King, Joey Korkames, git
In-Reply-To: <20091230121329.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> I think this is probably related to the "textconv" change.
Yeah, you guessed right. I think the unified way to launch user specified
programs would come first and then spawning proxy the same way as others
would become trivial.
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-30 8:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Jeff King
In-Reply-To: <20091230121325.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> I use this patch myself, and it works really well.
I stopped promoting the patch after Peff mentioned he was planning a
rework of textconv, but now I re-read it, I think his rework would be
orthogonal to the patch.
Also Peff gives a good hint about borrowing how launch_editor() calls out
to the shell. I think the codepath we fork&exec user-defined commands
(not hooks, but filters like smudge/clean/textconv and EDITOR/PAGER that
take a command line) need to be first enumerated, then we need to see if
we can refactor what launch_editor() does into a common helper function.
I felt it was unclear what we would want to do with GIT_EXTERNAL_DIFF,
diff.external, and diff.<driver>.command trio, but I tend to agree that we
should run things the same way, honoring $IFS and shell everywhere.
http://thread.gmane.org/gmane.comp.version-control.git/135250/focus=135312
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Mike Hommey @ 2009-12-30 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7v7htbom95.fsf@alter.siamese.dyndns.org>
(Nanako's bunch of reminders reminded me of this thread)
On Fri, Nov 27, 2009 at 10:28:38AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > On Fri, Nov 27, 2009 at 09:50:47AM +0100, Johannes Sixt wrote:
> >> Mike Hommey schrieb:
> >> > I don't know if the current Makefile works with Solaris' make,...
> >>
> >> No, it doesn't. You have to use GNU make anyway.
> >
> > Then it's fine. But shouldn't that be noted somewhere, like in the
> > INSTALL file ?
>
> Surely. Please make it so.
I had another idea in the interim. If GNU make is necessary, why not
make the Makefile an explicit GNU make only Makefile, by renaming it
GNUmakefile ?
That wouldn't remove the need to add a note in the INSTALL file, though.
Mike
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-12-30 7:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <20091230121319.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
See http://thread.gmane.org/gmane.comp.version-control.git/132983/focus=133414
In short, the particular way to call difftool this patch implements was
found to be inadequate to support existing external diff support by gitk
and a small difftool update will happen first, followed by a patch to gitk
to use the updated difftool, to avoid regression.
^ permalink raw reply
* Re: [PATCH v2] gitk: Honor TMPDIR when viewing diffs externally
From: Junio C Hamano @ 2009-12-30 7:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <20091230121314.6117@nanako3.lavabit.com>
If my recollection is correct, I think this approach was scrapped in favor
of using difftool to dispatch the external diff viewers.
^ permalink raw reply
* Re: [PATCH] Add completion for git-svn mkdirs,reset,and gc
From: Junio C Hamano @ 2009-12-30 7:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robert Zeh, git
In-Reply-To: <20091230005950.GC6914@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Robert Zeh <robert.a.zeh@gmail.com> wrote:
>>
>> Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
>> ---
>> contrib/completion/git-completion.bash | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> --
> Shawn.
Thanks.
Robert, if you are planning to be a regular contributor, please check your
MUA settings, and next time, please first send a patch to yourself and try
running "git am" on it to make sure it applies. Your patch was seriously
whitespace damaged (all the leading SP on the context lines were
stripped).
^ permalink raw reply
* Re: Question about 'branch -d' safety
From: Junio C Hamano @ 2009-12-30 6:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Nicolas Sebrecht, git
In-Reply-To: <20091230121238.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
>
>> The 30/12/09, Nanako Shiraishi wrote:
>>
>>> I think the safety feature should check if the branch to be deleted is merged to the remote tracking branch it was forked from, instead of checking the current branch.
>>>
>>> What do you think?
>>
>> I think we shouldn't. At first, every repository don't have a remote.
>> This may easily be passed by a "double check" with a logical OR between
>> the two statements.
>
> Sorry, I was unclear. What I meant was that checking with the branch the
> branch to be deleted was forked from, if and only if such a branch
> exists. Otherwise, we can keep using the old default behavior to check
> with the current branch.
Back when the original "safety valve" was added, there was no mechanical
"this branch _always_ merges from/rebases on that other one" settings.
The users were supposed to keep track of the correspondence, and the
canonical workflow was "checkout this && merge that && branch -d that".
But I actually think it is quite a natural thing to do in year 2010 to
change the safety valve as suggested.
A patch to do so would look like this.
-- >8 --
branch -d: base the "already-merged" safety on the branch it merges with
When a branch is marked to merge with another ref (e.g. local 'next' that
merges from and pushes back to origin's 'next', with 'branch.next.merge'
set to 'refs/heads/next'), it makes little sense to base the "branch -d"
safety, whose purpose is not to lose commits that are not merged to other
branches, on the current branch. It is much more sensible to check if it
is merged with the other branch it merges with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 64 ++++++++++++++++++++++++++++++++++++++++++++--------
t/t3200-branch.sh | 26 +++++++++++++++++++++
2 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index c87e63b..d2a35fe 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -93,9 +93,60 @@ static const char *branch_get_color(enum color_branch ix)
return "";
}
+static int branch_merged(int kind, const char *name,
+ struct commit *rev, struct commit *head_rev)
+{
+ /*
+ * This checks whether the merge bases of branch and HEAD (or
+ * the other branch this branch builds upon) contains the
+ * branch, which means that the branch has already been merged
+ * safely to HEAD (or the other branch).
+ */
+ struct commit *reference_rev = NULL;
+ const char *reference_name = NULL;
+ int merged;
+
+ if (kind == REF_LOCAL_BRANCH) {
+ struct branch *branch = branch_get(name);
+ unsigned char sha1[20];
+
+ if (branch &&
+ branch->merge &&
+ branch->merge[0] &&
+ branch->merge[0]->dst &&
+ (reference_name =
+ resolve_ref(branch->merge[0]->dst, sha1, 1, NULL)) != NULL)
+ reference_rev = lookup_commit_reference(sha1);
+ }
+ if (!reference_rev)
+ reference_rev = head_rev;
+
+ merged = in_merge_bases(rev, &reference_rev, 1);
+
+ /*
+ * After the safety valve is fully redefined to "check with
+ * upstream, if any, otherwise with HEAD", we should just
+ * return the result of the in_merge_bases() above without
+ * any of the following code, but during the transition period,
+ * a gentle reminder is in order.
+ */
+ if ((head_rev != reference_rev) &&
+ in_merge_bases(rev, &head_rev, 1) != merged) {
+ if (merged)
+ warning("deleting branch '%s' that has been merged to\n"
+ " '%s', but it is not yet merged to HEAD.",
+ name, reference_name);
+ else
+ warning("not deleting branch '%s' that is not yet merged to\n"
+ " '%s', even though it is merged to HEAD.",
+ name, reference_name);
+ }
+ return merged;
+}
+
static int delete_branches(int argc, const char **argv, int force, int kinds)
{
- struct commit *rev, *head_rev = head_rev;
+ struct commit *rev, *head_rev = NULL;
unsigned char sha1[20];
char *name = NULL;
const char *fmt, *remote;
@@ -148,15 +199,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
continue;
}
- /* This checks whether the merge bases of branch and
- * HEAD contains branch -- which means that the HEAD
- * contains everything in both.
- */
-
- if (!force &&
- !in_merge_bases(rev, &head_rev, 1)) {
- error("The branch '%s' is not an ancestor of "
- "your current HEAD.\n"
+ if (!force && !branch_merged(kinds, bname.buf, rev, head_rev)) {
+ error("The branch '%s' is not fully merged.\n"
"If you are sure you want to delete it, "
"run 'git branch -D %s'.", bname.buf, bname.buf);
ret = 1;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index d59a9b4..e0b7605 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -468,4 +468,30 @@ test_expect_success 'detect misconfigured autosetuprebase (no value)' '
git config --unset branch.autosetuprebase
'
+test_expect_success 'attempt to delete a branch without base and unmerged to HEAD' '
+ git checkout my9 &&
+ git config --unset branch.my8.merge &&
+ test_must_fail git branch -d my8
+'
+
+test_expect_success 'attempt to delete a branch merged to its base' '
+ # we are on my9 which is the initial commit; traditionally
+ # we would not have allowed deleting my8 that is not merged
+ # to my9, but it is set to track master that already has my8
+ git config branch.my8.merge refs/heads/master &&
+ git branch -d my8
+'
+
+test_expect_success 'attempt to delete a branch merged to its base' '
+ git checkout master &&
+ echo Third >>A &&
+ git commit -m "Third commit" A &&
+ git branch -t my10 my9 &&
+ git branch -f my10 HEAD^ &&
+ # we are on master which is at the third commit, and my10
+ # is behind us, so traditionally we would have allowed deleting
+ # it; but my10 is set to track my9 that is further behind.
+ test_must_fail git branch -d my10
+'
+
test_done
^ permalink raw reply related
* Re: git fast-import not verifying commit author lines?
From: David Reiss @ 2009-12-30 6:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git@vger.kernel.org
In-Reply-To: <20091222150649.GI10687@spearce.org>
>> author <somename> 1261454209 +0000
>> committer <somename> 1261454209 +0000
> a foreign system where the data might not reasonably exist.
But shouldn't there still be an extra space? One to separate "author"
from the empty name, and one to separate the empty name from the email?
If not, then I think this change should be made. (I couldn't find any
authoritative documentation on what constitutes a valid commit object.)
(Sorry, this has been sitting in my outbox for a week.)
--David
diff --git i/Documentation/git-fast-import.txt w/Documentation/git-fast-import.txt
index 288032c..6917739 100644
--- i/Documentation/git-fast-import.txt
+++ w/Documentation/git-fast-import.txt
@@ -312,6 +312,6 @@ change to the project.
'commit' SP <ref> LF
mark?
- ('author' SP <name> SP LT <email> GT SP <when> LF)?
- 'committer' SP <name> SP LT <email> GT SP <when> LF
+ ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
+ 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
('from' SP <committish> LF)?
^ permalink raw reply related
* [PATCH v6 3/4] reset: add a few tests for "git reset --merge"
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01),
added the --merge option to git reset, but there were no test cases
for it.
This was not a big problem because "git reset" was just forking and
execing "git read-tree", but this will change in a following patch.
So let's add a few test cases to make sure that there will be no
regression.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7110-reset-merge.sh | 159 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 159 insertions(+), 0 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
new file mode 100755
index 0000000..4c46083
--- /dev/null
+++ b/t/t7110-reset-merge.sh
@@ -0,0 +1,159 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Christian Couder
+#
+
+test_description='Tests for "git reset --merge"'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ for i in 1 2 3; do echo line $i; done >file1 &&
+ cat file1 >file2 &&
+ git add file1 file2 &&
+ test_tick &&
+ git commit -m "Initial commit" &&
+ git tag initial &&
+ echo line 4 >>file1 &&
+ cat file1 >file2 &&
+ test_tick &&
+ git commit -m "add line 4 to file1" file1 &&
+ git tag second
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: C C C D --merge D D D
+# file2: C D D D --merge C D D
+test_expect_success 'reset --merge is ok with changes in file it does not touch' '
+ git reset --merge HEAD^ &&
+ ! grep 4 file1 &&
+ grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
+ test -z "$(git diff --cached)"
+'
+
+test_expect_success 'reset --merge is ok when switching back' '
+ git reset --merge second &&
+ grep 4 file1 &&
+ grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: B B C D --merge D D D
+# file2: C D D D --merge C D D
+test_expect_success 'reset --merge discards changes added to index (1)' '
+ git reset --hard second &&
+ cat file1 >file2 &&
+ echo "line 5" >> file1 &&
+ git add file1 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file1 &&
+ ! grep 5 file1 &&
+ grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
+ test -z "$(git diff --cached)"
+'
+
+test_expect_success 'reset --merge is ok again when switching back (1)' '
+ git reset --hard initial &&
+ echo "line 5" >> file2 &&
+ git add file2 &&
+ git reset --merge second &&
+ ! grep 4 file2 &&
+ ! grep 5 file1 &&
+ grep 4 file1 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: C C C D --merge D D D
+# file2: C C D D --merge D D D
+test_expect_success 'reset --merge discards changes added to index (2)' '
+ git reset --hard second &&
+ echo "line 4" >> file2 &&
+ git add file2 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
+ test -z "$(git diff)" &&
+ test -z "$(git diff --cached)"
+'
+
+test_expect_success 'reset --merge is ok again when switching back (2)' '
+ git reset --hard initial &&
+ git reset --merge second &&
+ ! grep 4 file2 &&
+ grep 4 file1 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: A B B C --merge (disallowed)
+test_expect_success 'reset --merge fails with changes in file it touches' '
+ git reset --hard second &&
+ echo "line 5" >> file1 &&
+ test_tick &&
+ git commit -m "add line 5" file1 &&
+ sed -e "s/line 1/changed line 1/" <file1 >file3 &&
+ mv file3 file1 &&
+ test_must_fail git reset --merge HEAD^ 2>err.log &&
+ grep file1 err.log | grep "not uptodate"
+'
+
+test_expect_success 'setup 2 different branches' '
+ git reset --hard second &&
+ git branch branch1 &&
+ git branch branch2 &&
+ git checkout branch1 &&
+ echo "line 5 in branch1" >> file1 &&
+ test_tick &&
+ git commit -a -m "change in branch1" &&
+ git checkout branch2 &&
+ echo "line 5 in branch2" >> file1 &&
+ test_tick &&
+ git commit -a -m "change in branch2" &&
+ git tag third
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: X U B C --merge (disallowed)
+test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD^ &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
+ test -n "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: X U B B --merge (disallowed)
+test_expect_success '"reset --merge HEAD" fails with pending merge' '
+ git reset --hard third &&
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
+ test -n "$(git diff --cached)"
+'
+
+test_done
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 2/4] Documentation: reset: add some tables to describe the different options
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
This patch adds a DISCUSSION section that contains some tables to
show how the different "git reset" options work depending on the
states of the files in the working tree, the index, HEAD and the
target commit.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 66 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2d27e40..c9044c9 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -67,6 +67,72 @@ linkgit:git-add[1]).
<commit>::
Commit to make the current HEAD. If not given defaults to HEAD.
+DISCUSSION
+----------
+
+The tables below show what happens when running:
+
+----------
+git reset --option target
+----------
+
+to reset the HEAD to another commit (`target`) with the different
+reset options depending on the state of the files.
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+
+In these tables, A, B, C and D are some different states of a
+file. For example, the last line of the last table means that if a
+file is in state B in the working tree and the index, and in a
+different state C in HEAD and in the target, then "git reset
+--merge target" will put the file in state C in the working tree,
+in the index and in HEAD.
+
+The following tables show what happens when there are unmerged
+entries:
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge (disallowed)
+
+X means any state and U means an unmerged index.
+
Examples
--------
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 1/4] reset: improve mixed reset error message when in a bare repo
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
When running a "git reset --mixed" in a bare repository, the
message displayed is something like:
fatal: This operation must be run in a work tree
fatal: Could not reset index file to revision 'HEAD^'.
This message is a little bit misleading because a mixed reset is
ok in a git directory, so it is not absolutely needed to run it in
a work tree.
So this patch improves upon the above by changing the message to:
fatal: mixed reset is not allowed in a bare repository
And if "git reset" is ever sped up by using unpack_tree() directly
(instead of execing "git read-tree"), this patch will also make
sure that a mixed reset is still disallowed in a bare repository.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-reset.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 11d1c6e..3180c2b 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -291,6 +291,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
die("%s reset requires a work tree",
reset_type_names[reset_type]);
+ if (reset_type == MIXED && is_bare_repository())
+ die("%s reset is not allowed in a bare repository",
+ reset_type_names[reset_type]);
+
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
* the index file to the tree object we are switching to. */
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This patch makes "reset_index_file()" call "unpack_trees()" directly
instead of forking and execing "git read-tree". So the code is more
efficient.
And it's also easier to see which unpack_tree() options will be used,
as we don't need to follow "git read-tree"'s command line parsing
which is quite complex.
As Daniel Barkalow found, there is a difference between this new
version and the old one. The old version gives an error for
"git reset --merge" with unmerged entries, and the new version does
not when we reset the entries to some states that differ from HEAD.
But in 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) there is
the following:
"
- if the index has unmerged entries, "--merge" will currently
simply refuse to reset ("you need to resolve your current index
first"). You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the
working tree file should have matched the source tree, so the
correct action is likely to make --merge reset such a path to
the target (like --hard), regardless of dirty state in-tree or
in-index. But that's not how read-tree has ever worked, so..
"
So the new behavior looks better according to the original
implementation of "git reset --merge".
The code comes from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 2 +-
builtin-reset.c | 41 ++++++++++++++++++++++++++++++-----------
t/t7110-reset-merge.sh | 12 +++++++-----
3 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index c9044c9..b40999f 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -122,7 +122,7 @@ entries:
X U A B --soft (disallowed)
--mixed X B B
--hard B B B
- --merge (disallowed)
+ --merge X B B
working index HEAD target working index HEAD
----------------------------------------------------
diff --git a/builtin-reset.c b/builtin-reset.c
index 3180c2b..2c880a7 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -18,6 +18,8 @@
#include "tree.h"
#include "branch.h"
#include "parse-options.h"
+#include "unpack-trees.h"
+#include "cache-tree.h"
static const char * const git_reset_usage[] = {
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
@@ -54,27 +56,44 @@ static inline int is_merge(void)
static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet)
{
- int i = 0;
- const char *args[6];
+ int nr = 1;
+ int newfd;
+ struct tree_desc desc[2];
+ struct unpack_trees_options opts;
+ struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
- args[i++] = "read-tree";
+ memset(&opts, 0, sizeof(opts));
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.fn = oneway_merge;
+ opts.merge = 1;
if (!quiet)
- args[i++] = "-v";
+ opts.verbose_update = 1;
switch (reset_type) {
case MERGE:
- args[i++] = "-u";
- args[i++] = "-m";
+ opts.update = 1;
break;
case HARD:
- args[i++] = "-u";
+ opts.update = 1;
/* fallthrough */
default:
- args[i++] = "--reset";
+ opts.reset = 1;
}
- args[i++] = sha1_to_hex(sha1);
- args[i] = NULL;
- return run_command_v_opt(args, RUN_GIT_CMD);
+ newfd = hold_locked_index(lock, 1);
+
+ read_cache_unmerged();
+
+ if (!fill_tree_descriptor(desc + nr - 1, sha1))
+ return error("Failed to find tree of %s.", sha1_to_hex(sha1));
+ if (unpack_trees(nr, desc, &opts))
+ return -1;
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_locked_index(lock))
+ return error("Could not write new index file.");
+
+ return 0;
}
static void print_new_head_line(struct commit *commit)
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
index 4c46083..ff2875c 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -135,12 +135,14 @@ test_expect_success 'setup 2 different branches' '
#
# working index HEAD target working index HEAD
# ----------------------------------------------------
-# file1: X U B C --merge (disallowed)
-test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+# file1: X U B C --merge X C C
+test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
test_must_fail git merge branch1 &&
- test_must_fail git reset --merge HEAD^ &&
- test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
- test -n "$(git diff --cached)"
+ cat file1 >orig_file1 &&
+ git reset --merge HEAD^ &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)" &&
+ test_cmp file1 orig_file1
'
# The next test will test the following:
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 0/4] "git reset --merge" related improvements
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
Another reroll with the following changes:
- patches to add --keep option have been removed for now
- documentation patch has been moved before the core code changes
- commit messages have been improved
- tests have been much improved thanks to Junio's suggestions
Christian Couder (3):
reset: improve mixed reset error message when in a bare repo
Documentation: reset: add some tables to describe the different
options
reset: add a few tests for "git reset --merge"
Stephan Beyer (1):
reset: use "unpack_trees()" directly instead of "git read-tree"
Documentation/git-reset.txt | 66 ++++++++++++++++++
builtin-reset.c | 45 +++++++++---
t/t7110-reset-merge.sh | 161 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 261 insertions(+), 11 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
^ permalink raw reply
* Re: [PATCH v5 4/7] reset: add option "--keep" to "git reset"
From: Christian Couder @ 2009-12-30 5:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7viqcbn9w3.fsf@alter.siamese.dyndns.org>
On samedi 12 décembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > B B C D --keep (disallowed)
> > --merge C C C
>
> For --keep this is the same as the first case (except that the "partially
> updated the index" happened to be "100% pertially") and it makes sense to
> disallow it.
>
> However, I think --merge _should_ have D (target) in all of the three in
> the result in this case, as I mentioned in my response to [PATCH 3/7].
> Is that "the bug" you talked about there?
No it is not the bug I talked about. It was a bug in the documentation
patch. Thanks for finding it! I left some "C" on the merge line from an
earlier documentation patch but I should have changed them to "D" like
that:
B B C D --keep (disallowed)
--merge D D D
[...]
> It also is tempting to say that we should forbid "reset --merge" without
> an unmerged entry in the index, but that wouldn't work. A mergy
> operation would have left unmerged entries in the index initially before
> giving the control back to the user, but the user may have used "edit &&
> git add" to resolve them, and then decided that it is not worth
> committing. By the time "reset --merge" is run, there may not be any
> unmerged path left in the index.
>
> I am suggesting extra safety measures primarily because I am worried that
> people will get confused by these two similar looking options that are
> meant for entirely different use cases. An obvious alternative solution
> to avoid the confusion is not to add "--keep" in the first place. While
> I think that is rather a cop-out than a solution, it might make more
> sense. It is hopeless to educate users to pick the right one, if even the
> author of the new option mistakenly thinks that "--keep is merely a
> better version of --merge".
I just think it is better in some cases not always.
> My preference is at this point to first have patches [1/7] to [3/7] to
> update "reset --merge" (I am not sure about the "--mixed in $GIT_DIR"
> change, though), with a new follow-up patch [3.5/7] to fix "reset
> --merge" to reset paths that were cloberred by the merge to the target
> (not HEAD), and start cooking these changes in 'pu' and then 'next'.
Ok, I will send a patch series to do that except that I I don't understand
exactly what the follow up patch [3.5/7] shoud do. Perhaps you asked for
this additional patch because of the documentation bug above?
> That will lay groundwork of using unpack_trees() in "reset" and after
> they stabilize, build new modes like "--keep" on top of it.
Ok.
Thanks,
Christian.
^ permalink raw reply
* Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joey Korkames, git
In-Reply-To: <cone.1261179562.490491.4033.1000@toolshiner.phx1.kidfixit.com>
Junio, could you tell us what happened to this thread?
I think this is probably related to the "textconv" change.
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvdg9ceud.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
I use this patch myself, and it works really well.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <1258341126-2108-1-git-send-email-davvid@gmail.com>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH v2] gitk: Honor TMPDIR when viewing diffs externally
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <1258680422-42179-1-git-send-email-davvid@gmail.com>
Junio, could you tell us what happened to this thread?
A patch to help running diff command from gitk in a read-only place.
^ permalink raw reply
* Re: [PATCH] Fix archive format with -- on the command line
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Miklos Vajna, Ilari Liusvaara, git
In-Reply-To: <4B23B019.40106@lsrfire.ath.cx>
Junio, could you tell us what happened to this thread?
"git archive HEAD non-existing-path" doesn't complain like "git
add" does, and the patch is to fix it. No discussion.
^ 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