* [PATCH] builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
From: Michele Ballabio @ 2008-07-20 12:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-push.c | 29 ++++++++---------------------
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 03db28c..c1ed68d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -14,7 +14,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin, verbose;
+static int thin;
static const char *receivepack;
static const char **refspec;
@@ -84,7 +84,7 @@ static int do_push(const char *repo, int flags)
if (thin)
transport_set_option(transport, TRANS_OPT_THIN, "yes");
- if (verbose)
+ if (flags & TRANSPORT_PUSH_VERBOSE)
fprintf(stderr, "Pushing to %s\n", remote->url[i]);
err = transport_push(transport, refspec_nr, refspec, flags);
err |= transport_disconnect(transport);
@@ -101,22 +101,19 @@ static int do_push(const char *repo, int flags)
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
- int all = 0;
- int mirror = 0;
- int dry_run = 0;
- int force = 0;
int tags = 0;
int rc;
const char *repo = NULL; /* default repository */
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
- OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
- OPT_BOOLEAN( 0 , "mirror", &mirror, "mirror all refs"),
+ 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 , "tags", &tags, "push tags"),
- OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
- OPT_BOOLEAN('f', "force", &force, "force updates"),
+ OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
@@ -125,18 +122,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, push_usage, 0);
- if (force)
- flags |= TRANSPORT_PUSH_FORCE;
- if (dry_run)
- flags |= TRANSPORT_PUSH_DRY_RUN;
- if (verbose)
- flags |= TRANSPORT_PUSH_VERBOSE;
if (tags)
add_refspec("refs/tags/*");
- if (all)
- flags |= TRANSPORT_PUSH_ALL;
- if (mirror)
- flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
if (argc > 0) {
repo = argv[0];
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Petr Baudis @ 2008-07-20 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ibhdmii.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
> "git update-index --refresh", "git reset" and "git add --refresh" have
> reported paths that have local modifications as "needs update" since the
> beginning of git.
>
> Although this is logically correct in that you need to update the index at
> that path before you can commit that change, it is now becoming more and
> more clear, especially with the continuous push for user friendliness
> since 1.5.0 series, that the message is suboptimal. After all, the change
> may be something the user might want to get rid of, and "updating" would
> be absolutely a wrong thing to do if that is the case.
>
> I prepared two alternatives to solve this. Both aim to reword the message
> to more neutral "locally modified".
>
> This patch is a more straightforward variant that changes the message not
> only for Porcelain commands ("add" and "reset") but also changes the
> output from the plumbing command "update-index".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
I believe this is a good thing. Scripts need to be modified for the
reorganization anyway, and I'm not sure if there are any actually
depening on this particular string. I think having inconsistent error
messaging is worse in long term.
FWIW, looking at Cogito,
cg-Xlib: git-update-index --refresh | sed 's/needs update$/locally modified/'
is the only reference to this. ;-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: What's in git.git (stable)
From: Lars Noschinski @ 2008-07-20 11:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsjhgvtn.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>Lars Noschinski (2):
> cvsserver: Add support for packed refs
> cvsserver: Add cvs co -c support
Any specific reason why you did not merge the test for packed refs
support? Was it considered superfluous?
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Johannes Schindelin @ 2008-07-20 11:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vk5fhc6qo.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So what I really would like is this: leave the plumbing pages as they
> > are, but enhance those pages that users (especially new ones) are
> > likely to see most often.
>
> Regarding the original "do we want to ever teach plumbing to new users?"
> issue, I suspect that, with sufficient enhancement to Porcelain, we
> might be able to reach a point where end users can work without ever
> touching a single plumbing command at all.
I just went back to the thread I mentioned earlier,
http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62021
and I did not find where you need plumbing.
> Perhaps move the plumbing documentation to section 3; just like Perl has
> DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will
> describe what scripts can do with the command.
But of course! I was wondering where to put it, but understanding
plumbing as a sort of library for shell scripts makes sense absolutely!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Johannes Schindelin @ 2008-07-20 10:56 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, Michael J Gruber, Jay Soffian
In-Reply-To: <905315640807192120k45b8c0e3k5b341e77c466dde@mail.gmail.com>
Hi,
On Sat, 19 Jul 2008, Tarmigan wrote:
> It's too bad that 'commit -a' and 'add -a' will have different
> meanings.
Two things:
- add and commit are two _different_ operations, not only in name, but
also in nature. The fact that "commit -a" calls "add" is a _pure_
convenience. It does not change the fact that "add" and "commit" are
completely, utterly different.
- if you are a heavy user of "commit -a", chances are that your history is
not really useful, because you committed unrelated changes accidentally
in the same commit.
The latter point, BTW, is the reason I _never_ teach the "-a" option
(actually, I teach no option at all) in my first two Git lessons.
Ciao,
Dscho
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-20 10:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <alpine.DEB.1.00.0807201233010.3305@eeepc-johanness>
Hi,
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> You call that "worse"? Pasky tried to convert all Perl scripts at once
> IIRC, and my numerous problems just _making_ the Git scripts led me to
> rewrite a few Perl scripts in C, so I could safely exclude the Perl
> scripts from my personal fork.
I don't remember any concrete report of such problems ever reaching
me; exactly what trouble are you hitting with the Perl scripts using
Git.pm? I will be glad to try to fix it.
> I guess that it was this experience which prevented more of the old
> scripts from being converted.
>
> But your mention of git-add--interactive actually brings up my pet-peeve:
> this script is the only Perl script needed for common operations, i.e. the
> only reason msysGit has to ship bloated with Perl.
_Many_ people seem to be using git-svn, whether we like it or not. ;-)
Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
using stg mail.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 10:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Lea Wiemann, git, John Hawley
In-Reply-To: <200807192254.24622.jnareb@gmail.com>
Hi,
On Sat, 19 Jul 2008, Jakub Narebski wrote:
> From git commands in Perl the following include "use Git" in their
> sources: git-cvsexportcommit, git-send-email, git-svn, and helper
> script git-add--interactive. There are Perl scripts which do not
> use Git.pm: git-archimport (which I think should be obsoleted or
> moved to contrib), git-cvsimport, git-cvsserver, git-relink. This
> means that half of Perl scripts use Git Perl API.
>
> The situation is worse for scripts in 'contrib/'. From those, only
> contrib/examples/git-remote.perl uses Git.pm; neither blameview,
> continuous, git-import and import-tars in fast-import, setgitperms
> and update-paranoid in hooks, stats, nor other Perl scripts in
> examples (git-rerere, git-svnimport) include "use Git".
You call that "worse"? Pasky tried to convert all Perl scripts at once
IIRC, and my numerous problems just _making_ the Git scripts led me to
rewrite a few Perl scripts in C, so I could safely exclude the Perl
scripts from my personal fork.
I guess that it was this experience which prevented more of the old
scripts from being converted.
But your mention of git-add--interactive actually brings up my pet-peeve:
this script is the only Perl script needed for common operations, i.e. the
only reason msysGit has to ship bloated with Perl.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 10:27 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <1216491512.3911.9.camel@pc7.dolda2000.com>
Hi,
On Sat, 19 Jul 2008, Fredrik Tolf wrote:
> On Sat, 2008-07-19 at 10:57 -0700, Keith Packard wrote:
> > On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> > > By removing the DISPLAY env variable before forking, SSH
> > > can thus be forced into non-interactive mode, without any obvious
> > > ill effects.
> >
> > This will keep ssh-askpass from using any X-based password input
> > program.
>
> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
I think this would be the correct way, together with "-T".
> I imagine that that might make git less portable to SSH implementations
> other than OpenSSH, but I don't know if that is considered a problem.
Well, this was to be expected, after what I wrote in response to 3. in
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
Reality always catches up with you, and here again we see that plink and
other siblings of OpenSSH should be best handled with scripts, preferably
ones that strip out options they do not recognize.
IOW something like
-- snip --
#!/bin/bash
plinkopt=
while test $# != 0
do
case "$1" in
-p)
plinkopt="$plinkopt -P $2"
shift
;;
-*)
# unrecognized; strip out
;;
*)
break
;;
esac
shift
done
exec plink $plinkopt "$@"
-- snap --
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-merge -s theirs
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Sometimes people wonder why "-s ours" strategy exists but "-s theirs" does
not. The reason was explained on the mailing list recently:
Quoting Junio C Hamano <gitster@pobox.com>:
> One big problem "-s theirs" has, compared to the "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs". Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch. When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.
This patch steals much code from "git-merge-resolve" to add "theirs"
strategy. Its purpose is to always fail and suggest using the preferred
command "git reset --hard the-other-commit".
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Makefile | 3 ++-
builtin-merge.c | 1 +
git-merge-theirs.sh | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 1 deletions(-)
create mode 100755 git-merge-theirs.sh
diff --git a/Makefile b/Makefile
index 2b670d7..22f699a 100644
--- a/Makefile
+++ b/Makefile
@@ -240,6 +240,7 @@ SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
+SCRIPT_SH += git-merge-theirs.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
@@ -1433,7 +1434,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
- git-merge-resolve | git-merge-subtree | \
+ git-merge-resolve | git-merge-subtree | git-merge-theirs | \
git-fsck-objects | git-init-db | \
git-?*--?* ) continue ;; \
esac ; \
diff --git a/builtin-merge.c b/builtin-merge.c
index edc6016..8ed815b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -55,6 +55,7 @@ static struct strategy all_strategy[] = {
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
{ "ours", NO_FAST_FORWARD | NO_TRIVIAL },
+ { "theirs", NO_FAST_FORWARD | NO_TRIVIAL },
{ "subtree", NO_FAST_FORWARD | NO_TRIVIAL },
};
diff --git a/git-merge-theirs.sh b/git-merge-theirs.sh
new file mode 100755
index 0000000..e228d2b
--- /dev/null
+++ b/git-merge-theirs.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+
+# The first parameters up to -- are merge bases; the rest are heads.
+bases= head= remotes= sep_seen=
+for arg
+do
+ case ",$sep_seen,$head,$arg," in
+ *,--,)
+ sep_seen=yes
+ ;;
+ ,yes,,*)
+ head=$arg
+ ;;
+ ,yes,*)
+ remotes="$remotes$arg "
+ ;;
+ *)
+ bases="$bases$arg "
+ ;;
+ esac
+done
+
+# Give up if we are given two or more remotes -- not handling octopus.
+case "$remotes" in
+?*' '?*)
+ exit 2 ;;
+esac
+
+echo "If you wanted to say the other history is better than your history,"
+echo "use 'git reset --hard $remotes' instead."
+echo "If you want to keep a record of your failure, you can create a"
+echo "new branch from the current HEAD before running the reset command."
+
+exit 2
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] builtin-merge-recursive.c: make merge_recursive() static
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This function is not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
builtin-merge-recursive.c | 2 +-
merge-recursive.h | 7 -------
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index 1ab1945..553aa16 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -1247,7 +1247,7 @@ static struct commit_list *reverse_commit_list(struct commit_list *list)
* Merge the commits h1 and h2, return the resulting virtual
* commit object and a flag indicating the cleanness of the merge.
*/
-int merge_recursive(struct commit *h1,
+static int merge_recursive(struct commit *h1,
struct commit *h2,
const char *branch1,
const char *branch2,
diff --git a/merge-recursive.h b/merge-recursive.h
index f37630a..8924371 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -1,13 +1,6 @@
#ifndef MERGE_RECURSIVE_H
#define MERGE_RECURSIVE_H
-int merge_recursive(struct commit *h1,
- struct commit *h2,
- const char *branch1,
- const char *branch2,
- struct commit_list *ancestors,
- struct commit **result);
-
int merge_trees(struct tree *head,
struct tree *merge,
struct tree *common,
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] Teach "git-merge" that "stupid" merge strategy no longer exists
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Next release 1.6.0 will not have "stupid" merge strategy, but
"git merge -s confused origin" still includs it in the list of
available merge strategies.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
builtin-merge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..edc6016 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -54,7 +54,6 @@ static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
- { "stupid", 0 },
{ "ours", NO_FAST_FORWARD | NO_TRIVIAL },
{ "subtree", NO_FAST_FORWARD | NO_TRIVIAL },
};
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-20 10:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807181356010.3932@eeepc-johanness>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 18 Jul 2008, Nanako Shiraishi wrote:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>> > This needs to be merged to master iff/when merge-theirs gets merged,
>> > but I do not think this series is widely supported, so both are on
>> > hold.
>>
>> Why do you say it is not widely supported? I may be wrong but I think
>> you developed these patches after somebody from the mailing list asked
>> for this feature.
>
> Asking for a feature, and then not doing a single thing to defend why it
> makes sense, of a single person, who does not even speak up now, does not
> count for "wide support".
For the record, I was not the one who asked for such a feature.
It seems that the conclusion of the discussion is that "theirs" promotes a bad workflow, and I am happy with that.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Hacks for AIX
From: Junio C Hamano @ 2008-07-20 8:33 UTC (permalink / raw)
To: Chris Cowan; +Cc: git, Brandon Casey
In-Reply-To: <7v3am9sn2p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> * /usr/bin/patch - really old version, doesn't do well with some
>> diff formats. I avoid using it.
>
> t4109 seems to use patch to produce expected output for the tests; we
> should ship a precomputed expected results. Do you know of any other
> places "patch" is used?
As usual, I won't commit this patch unless I hear from people who
potentially would benefit from it. I do not need such a patch myself and
I really shouldn't be spending too much of my time on these.
-- >8 --
[PATCH] do not rely on external "patch" in tests
Some of our tests assumed a working "patch" command to produce expected
results when checking "git-apply", but some systems have broken "patch".
We can compare our output with expected output that is precomputed
instead to sidestep this issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4109-apply-multifrag.sh | 119 +++++++++++++++++++++++++++++++++++---------
t/t4110-apply-scan.sh | 35 ++++++++++---
2 files changed, 123 insertions(+), 31 deletions(-)
diff --git a/t/t4109-apply-multifrag.sh b/t/t4109-apply-multifrag.sh
index bd40a21..4805863 100755
--- a/t/t4109-apply-multifrag.sh
+++ b/t/t4109-apply-multifrag.sh
@@ -138,39 +138,112 @@ diff --git a/main.c b/main.c
EOF
-test_expect_success "S = git apply (1)" \
- 'git apply patch1.patch patch2.patch'
-mv main.c main.c.git
+cat >expect_1 <<\EOF
+#include <stdlib.h>
+#include <stdio.h>
-test_expect_success "S = patch (1)" \
- 'cat patch1.patch patch2.patch | patch -p1'
+int func(int num);
+void print_int(int num);
+void print_ln();
-test_expect_success "S = cmp (1)" \
- 'cmp main.c.git main.c'
+int main() {
+ int i;
-rm -f main.c main.c.git
+ for (i = 0; i < 10; i++) {
+ print_int(func(i));
+ }
-test_expect_success "S = git apply (2)" \
- 'git apply patch1.patch patch2.patch patch3.patch'
-mv main.c main.c.git
+ print_ln();
-test_expect_success "S = patch (2)" \
- 'cat patch1.patch patch2.patch patch3.patch | patch -p1'
+ return 0;
+}
-test_expect_success "S = cmp (2)" \
- 'cmp main.c.git main.c'
+int func(int num) {
+ return num * num;
+}
-rm -f main.c main.c.git
+void print_int(int num) {
+ printf("%d", num);
+}
-test_expect_success "S = git apply (3)" \
- 'git apply patch1.patch patch4.patch'
-mv main.c main.c.git
+void print_ln() {
+ printf("\n");
+}
-test_expect_success "S = patch (3)" \
- 'cat patch1.patch patch4.patch | patch -p1'
+EOF
+
+test_expect_success 'git apply (1)' '
+ git apply patch1.patch patch2.patch &&
+ mv main.c actual &&
+ test_cmp expect_1 actual
+'
+
+cat >expect_2 <<\EOF
+#include <stdio.h>
+
+int func(int num);
+void print_int(int num);
+
+int main() {
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ print_int(func(i));
+ }
+
+ return 0;
+}
+
+int func(int num) {
+ return num * num;
+}
+
+void print_int(int num) {
+ printf("%d", num);
+}
+
+EOF
-test_expect_success "S = cmp (3)" \
- 'cmp main.c.git main.c'
+test_expect_success 'git apply (2)' '
+ rm -f main.c &&
+ git apply patch1.patch patch2.patch patch3.patch &&
+ mv main.c actual &&
+ test_cmp expect_2 actual
+'
+
+cat >expect_3 <<\EOF
+#include <stdio.h>
+
+int func(int num);
+int func2(int num);
+
+int main() {
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ printf("%d", func(i));
+ printf("%d", func3(i));
+ }
+
+ return 0;
+}
+
+int func(int num) {
+ return num * num;
+}
+
+int func2(int num) {
+ return num * num * num;
+}
+
+EOF
+
+test_expect_success 'git apply (3)' '
+ rm -f main.c &&
+ git apply patch1.patch patch4.patch &&
+ mv main.c actual &&
+ test_cmp expect_3 actual
+'
test_done
diff --git a/t/t4110-apply-scan.sh b/t/t4110-apply-scan.sh
index db60652..ae300ca 100755
--- a/t/t4110-apply-scan.sh
+++ b/t/t4110-apply-scan.sh
@@ -86,15 +86,34 @@ diff --git a/new.txt b/new.txt
+c2222
EOF
-test_expect_success "S = git apply scan" \
- 'git apply patch1.patch patch2.patch patch3.patch patch4.patch patch5.patch'
-mv new.txt apply.txt
+cat >expect <<\EOF
+a1
+a11
+a111
+a1111
+b1
+b11
+b111
+b1111
+b2
+b22
+b222
+b2222
+c1
+c11
+c111
+c1111
+c2
+c22
+c222
+c2222
+EOF
-test_expect_success "S = patch scan" \
- 'cat patch1.patch patch2.patch patch3.patch patch4.patch patch5.patch | patch'
-mv new.txt patch.txt
-test_expect_success "S = cmp" \
- 'cmp apply.txt patch.txt'
+test_expect_success 'apply series of patches' '
+ git apply patch1.patch patch2.patch patch3.patch patch4.patch patch5.patch &&
+ mv new.txt actual &&
+ test_cmp expect actual
+'
test_done
^ permalink raw reply related
* Re: Suggestion: doc restructuring
From: Junio C Hamano @ 2008-07-20 8:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, git
In-Reply-To: <alpine.DEB.1.00.0807190314010.3064@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So what I really would like is this: leave the plumbing pages as they are,
> but enhance those pages that users (especially new ones) are likely to see
> most often.
Regarding the original "do we want to ever teach plumbing to new users?"
issue, I suspect that, with sufficient enhancement to Porcelain, we might
be able to reach a point where end users can work without ever touching a
single plumbing command at all.
Side note, that was why I suggested us to first think about use
cases in our every day work that we still need to resort to the
plumbing, so that we can identify what that enhancement would
consist of.
When we reach that point, we might want to restructure the documentation
into two volumes. One volume for end-users who exclusively use the stock
git Porcelain, and another that describes plumbing commands for Porcelain
writers.
Perhaps move the plumbing documentation to section 3; just like Perl has
DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will
describe what scripts can do with the command.
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Junio C Hamano @ 2008-07-20 7:56 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080718092001.GD16102@mail.local.tull.net>
Nick Andrew <nick@nick-andrew.net> writes:
> ...Without
> a working "--quiet" nor exit code I can pipe the output to "wc -l"
> but is there a more efficient/reliable way to implement the requirement?
Did you read the whole thread before asking the above question?
IOW, does this answer the above question?
http://mid.gmane.org/7vy73zd8ok.fsf@gitster.siamese.dyndns.org
^ permalink raw reply
* [RFC] "needs update" considered harmful
From: Junio C Hamano @ 2008-07-20 7:48 UTC (permalink / raw)
To: git
In-Reply-To: <7v3am5f20f.fsf@gitster.siamese.dyndns.org>
The previous two variants both aim to reword the somewhat unpopular "needs
update" message to easier "locally modified".
"Politically correct" thing to do would be to keep the output from the
update-index (plumbing) intact and update only output from "reset" and
"add --refresh -v" which are Porcelain. This has smaller chance of
breaking people's existing scripts, but some people may find the two
messages that say the same thing inconsistent.
Rewording to "locally modified" even at the plumbing level is a simpler
patch, keeps the API to refresh_index() intact, and probably is a better
approach in the longer term, especially if we can ignore people's existing
scripts.
^ permalink raw reply
* [RFC variant 2 of 2] "needs update" considered harmful
From: Junio C Hamano @ 2008-07-20 7:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzelf4mf.fsf@gitster.siamese.dyndns.org>
"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.
Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal. After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.
I prepared two alternatives to solve this. Both aim to reword the message
to more neutral "locally modified".
This patch is a more straightforward variant that changes the message not
only for Porcelain commands ("add" and "reset") but also changes the
output from the plumbing command "update-index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
read-cache.c | 2 +-
t/t2103-update-index-ignore-missing.sh | 2 +-
t/t7102-reset.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index f83de8c..d37aec0 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1019,7 +1019,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- printf("%s: needs update\n", ce->name);
+ printf("%s: locally modified\n", ce->name);
has_errors = 1;
continue;
}
diff --git a/t/t2103-update-index-ignore-missing.sh b/t/t2103-update-index-ignore-missing.sh
index 4fbf855..f775acb 100755
--- a/t/t2103-update-index-ignore-missing.sh
+++ b/t/t2103-update-index-ignore-missing.sh
@@ -62,7 +62,7 @@ test_expect_success '--unmerged --refresh' '
test_must_fail git update-index --refresh &&
git update-index --unmerged --refresh &&
echo 2 >two &&
- echo "two: needs update" >expect &&
+ echo "two: locally modified" >expect &&
test_must_fail git update-index --unmerged --refresh >actual &&
test_cmp expect actual
'
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 96d1508..da4b142 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -419,7 +419,7 @@ test_expect_success 'resetting an unmodified path is a no-op' '
'
cat > expect << EOF
-file2: needs update
+file2: locally modified
EOF
test_expect_success '--mixed refreshes the index' '
--
1.5.6.4.570.g052e6
^ permalink raw reply related
* [RFC variant 1 of 2] "needs update" considered harmful
From: Junio C Hamano @ 2008-07-20 7:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzelf4mf.fsf@gitster.siamese.dyndns.org>
"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.
Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal. After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.
I prepared two alternatives to solve this. Both aim to reword the message
to more neutral "locally modified".
This patch is a more intrusive variant that changes the message for only
Porcelain commands ("add" and "reset") while keeping the plumbing
"update-index" intact.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-add.c | 3 ++-
builtin-reset.c | 2 +-
cache.h | 1 +
read-cache.c | 5 ++++-
t/t7102-reset.sh | 2 +-
5 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 9930cf5..5ffe4da 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -142,7 +142,8 @@ static void refresh(int verbose, const char **pathspec)
seen = xcalloc(specs, 1);
if (read_cache() < 0)
die("index file corrupt");
- refresh_index(&the_index, verbose ? 0 : REFRESH_QUIET, pathspec, seen);
+ refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
+ pathspec, seen);
for (i = 0; i < specs; i++) {
if (!seen[i])
die("pathspec '%s' did not match any files", pathspec[i]);
diff --git a/builtin-reset.c b/builtin-reset.c
index a032169..98dbe1c 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -96,7 +96,7 @@ static int update_index_refresh(int fd, struct lock_file *index_lock)
if (read_cache() < 0)
return error("Could not read index");
- result = refresh_cache(0) ? 1 : 0;
+ result = refresh_cache(REFRESH_SAY_CHANGED) ? 1 : 0;
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(index_lock))
return error ("Could not refresh index");
diff --git a/cache.h b/cache.h
index 9735b66..da87c72 100644
--- a/cache.h
+++ b/cache.h
@@ -397,6 +397,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
#define REFRESH_IGNORE_SUBMODULES 0x0010 /* ignore submodules */
+#define REFRESH_SAY_CHANGED 0x0020 /* say "changed" not "needs update" */
extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
struct lock_file {
diff --git a/read-cache.c b/read-cache.c
index f83de8c..9839362 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -980,7 +980,10 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
+ const char *needs_update_message;
+ needs_update_message = ((flags & REFRESH_SAY_CHANGED)
+ ? "locally modified" : "needs update");
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce, *new;
int cache_errno = 0;
@@ -1019,7 +1022,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- printf("%s: needs update\n", ce->name);
+ printf("%s: %s\n", ce->name, needs_update_message);
has_errors = 1;
continue;
}
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 96d1508..da4b142 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -419,7 +419,7 @@ test_expect_success 'resetting an unmodified path is a no-op' '
'
cat > expect << EOF
-file2: needs update
+file2: locally modified
EOF
test_expect_success '--mixed refreshes the index' '
^ permalink raw reply related
* Re: [PATCH] refresh-index: fix bitmask assignment
From: Junio C Hamano @ 2008-07-20 7:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5fhf35p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This hopefully protects the previous fix (and other --refresh related
> options) from future breakages.
>
> I'll squash it in to the previous one.
Actually, I'll squash this further on top, for a reason that will become
clear with the next series...
---
t/t2103-update-index-ignore-missing.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t2103-update-index-ignore-missing.sh b/t/t2103-update-index-ignore-missing.sh
index 332694e..4fbf855 100755
--- a/t/t2103-update-index-ignore-missing.sh
+++ b/t/t2103-update-index-ignore-missing.sh
@@ -62,10 +62,9 @@ test_expect_success '--unmerged --refresh' '
test_must_fail git update-index --refresh &&
git update-index --unmerged --refresh &&
echo 2 >two &&
+ echo "two: needs update" >expect &&
test_must_fail git update-index --unmerged --refresh >actual &&
- grep two actual &&
- ! grep one actual &&
- ! grep three actual
+ test_cmp expect actual
'
test_expect_success '--ignore-submodules --refresh (1)' '
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-20 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprp9f3ne.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 11:52:53PM -0700, Junio C Hamano (gitster@pobox.com) wrote:
> >> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=88402
> >
> > Better late than never :)
>
> You should have said "better redundant than never", though ;-)
Indeed, although there were no mention that error occurs with clone, so
I would find it :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] refresh-index: fix bitmask assignment
From: Junio C Hamano @ 2008-07-20 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzelf4mf.fsf@gitster.siamese.dyndns.org>
This hopefully protects the previous fix (and other --refresh related
options) from future breakages.
I'll squash it in to the previous one.
---
t/t2103-update-index-ignore-missing.sh | 89 ++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100755 t/t2103-update-index-ignore-missing.sh
diff --git a/t/t2103-update-index-ignore-missing.sh b/t/t2103-update-index-ignore-missing.sh
new file mode 100755
index 0000000..332694e
--- /dev/null
+++ b/t/t2103-update-index-ignore-missing.sh
@@ -0,0 +1,89 @@
+#!/bin/sh
+
+test_description='update-index with options'
+
+. ./test-lib.sh
+
+test_expect_success basics '
+ >one &&
+ >two &&
+ >three &&
+
+ # need --add when adding
+ test_must_fail git update-index one &&
+ test -z "$(git ls-files)" &&
+ git update-index --add one &&
+ test zone = "z$(git ls-files)" &&
+
+ # update-index is atomic
+ echo 1 >one &&
+ test_must_fail git update-index one two &&
+ echo "M one" >expect &&
+ git diff-files --name-status >actual &&
+ test_cmp expect actual &&
+
+ git update-index --add one two three &&
+ for i in one three two; do echo $i; done >expect &&
+ git ls-files >actual &&
+ test_cmp expect actual &&
+
+ test_tick &&
+ (
+ test_create_repo xyzzy &&
+ cd xyzzy &&
+ >file &&
+ git add file
+ git commit -m "sub initial"
+ ) &&
+ git add xyzzy &&
+
+ test_tick &&
+ git commit -m initial &&
+ git tag initial
+'
+
+test_expect_success '--ignore-missing --refresh' '
+ git reset --hard initial &&
+ echo 2 >one &&
+ test_must_fail git update-index --refresh &&
+ echo 1 >one &&
+ git update-index --refresh &&
+ rm -f two &&
+ test_must_fail git update-index --refresh &&
+ git update-index --ignore-missing --refresh
+
+'
+
+test_expect_success '--unmerged --refresh' '
+ git reset --hard initial &&
+ info=$(git ls-files -s one | sed -e "s/ 0 / 1 /") &&
+ git rm --cached one &&
+ echo "$info" | git update-index --index-info &&
+ test_must_fail git update-index --refresh &&
+ git update-index --unmerged --refresh &&
+ echo 2 >two &&
+ test_must_fail git update-index --unmerged --refresh >actual &&
+ grep two actual &&
+ ! grep one actual &&
+ ! grep three actual
+'
+
+test_expect_success '--ignore-submodules --refresh (1)' '
+ git reset --hard initial &&
+ rm -f two &&
+ test_must_fail git update-index --ignore-submodules --refresh
+'
+
+test_expect_success '--ignore-submodules --refresh (2)' '
+ git reset --hard initial &&
+ test_tick &&
+ (
+ cd xyzzy &&
+ git commit -m "sub second" --allow-empty
+ ) &&
+ test_must_fail git update-index --refresh &&
+ test_must_fail git update-index --ignore-missing --refresh &&
+ git update-index --ignore-submodules --refresh
+'
+
+test_done
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-20 6:52 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080720064137.GA9654@2ka.mipt.ru>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
> On Sat, Jul 19, 2008 at 03:00:20PM -0700, Junio C Hamano (gitster@pobox.com) wrote:
>> > I posted it so it would be stored in archive, that old enough git
>> > version does not work with recent trees, so one should upgrade if this
>> > error occures.
>>
>> Thanks, but you are about 5 days too late ;-)
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=88402
>
> Better late than never :)
You should have said "better redundant than never", though ;-)
^ permalink raw reply
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-20 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvxzg97.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 03:00:20PM -0700, Junio C Hamano (gitster@pobox.com) wrote:
> > I posted it so it would be stored in archive, that old enough git
> > version does not work with recent trees, so one should upgrade if this
> > error occures.
>
> Thanks, but you are about 5 days too late ;-)
>
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=88402
Better late than never :)
--
Evgeniy Polyakov
^ permalink raw reply
* [PATCH] refresh-index: fix bitmask assignment
From: Junio C Hamano @ 2008-07-20 6:31 UTC (permalink / raw)
To: git
5fdeacb (Teach update-index about --ignore-submodules, 2008-05-14) added a
new refresh option flag but did not assign a unique bit for it correctly,
and broke "update-index --ignore-missing".
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The fact that it took this long for anybody to notice the breakage
probably means that the "--ignore-missing" option in particular but the
ability for plumbing to allow scripting in general is not utilized by
as many people as the design initially envisioned.
cache.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index ca382d4..9735b66 100644
--- a/cache.h
+++ b/cache.h
@@ -396,7 +396,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_UNMERGED 0x0002 /* allow unmerged */
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
-#define REFRESH_IGNORE_SUBMODULES 0x0008 /* ignore submodules */
+#define REFRESH_IGNORE_SUBMODULES 0x0010 /* ignore submodules */
extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
struct lock_file {
--
1.5.6.4.570.g052e6
^ permalink raw reply related
* [PATCH v2 4/4] git-add --all: documentation
From: Junio C Hamano @ 2008-07-20 6:09 UTC (permalink / raw)
To: git
In-Reply-To: <1216534144-23826-3-git-send-email-gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-add.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 3558905..2b6d6c8 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
- [--update | -u] [--refresh] [--ignore-errors] [--]
+ [--all | [--update | -u]] [--refresh] [--ignore-errors] [--]
<filepattern>...
DESCRIPTION
@@ -86,6 +86,12 @@ OPTIONS
command line. If no paths are specified, all tracked files in the
current directory and its subdirectories are updated.
+-A::
+--all::
+ Update files that git already knows about (same as '\--update')
+ and add all untracked files that are not ignored by '.gitignore'
+ mechanism.
+
--refresh::
Don't add the file(s), but only refresh their stat()
information in the index.
--
1.5.6.4.570.g052e6
^ 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