* Re: origin/branchname and tracking branch pointing to different commits?
From: Matthieu Moy @ 2010-01-07 17:06 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> gives me qa branch history advanced by 4 commits comparing to
> origin/qa
This means you have local commits which are not in the remote branch.
> $git pull origin qa
If you want to send your local commits, use "git push".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This is a hack, to scratch my itch. These patches add "git ls",
which is equivalent to "git ls-files --max-depth 1|column"
Anyone up for coloring? ;)
Nguyễn Thái Ngọc Duy (3):
ls-files: support --max-depth
ls-files: support -o --max-depth (more of a hack as fill_directory
should support this)
Add "ls", which is basically ls-files with user-friendly settings
builtin-ls-files.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
3 files changed, 74 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/3] ls-files: support --max-depth
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 7382157..2bb851a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -30,6 +30,7 @@ static int error_unmatch;
static char *ps_matched;
static const char *with_tree;
static int exc_given;
+static int max_depth = 0;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -232,6 +233,30 @@ static void prune_cache(const char *prefix)
active_nr = last;
}
+/*
+ * It is assumed that prune_cache() as been called before this
+ */
+static void prune_cache_by_depth(const char *prefix, int max_depth)
+{
+ int i = active_nr-1;
+
+ while (i >= 0) {
+ int slashes = 0;
+ const char *entry = active_cache[i]->name + prefix_len;
+ while ((entry = strchr(entry, '/')) != NULL) {
+ slashes++;
+ if (slashes >= max_depth) {
+ memmove(active_cache + i, active_cache + i + 1,
+ (active_nr - i - 1) * sizeof(struct cache_entry *));
+ active_nr--;
+ break;
+ }
+ entry++;
+ }
+ i--;
+ }
+}
+
static const char *verify_pathspec(const char *prefix)
{
const char **p, *n, *prev;
@@ -476,6 +501,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
"if any <file> is not in the index, treat this as an error"),
OPT_STRING(0, "with-tree", &with_tree, "tree-ish",
"pretend that paths removed since <tree-ish> are still present"),
+ OPT_INTEGER(0, "max-depth", &max_depth, "max recursive depth"),
OPT__ABBREV(&abbrev),
OPT_END()
};
@@ -541,6 +567,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
if (prefix)
prune_cache(prefix);
+
+ if (max_depth)
+ prune_cache_by_depth(prefix, max_depth);
+
if (with_tree) {
/*
* Basic sanity check; show-stages and show-unmerged
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 2/3] ls-files: support -o --max-depth (more of a hack as fill_directory should support this)
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2bb851a..e16638e 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -51,6 +51,17 @@ static void show_dir_entry(const char *tag, struct dir_entry *ent)
if (!match_pathspec(pathspec, ent->name, ent->len, len, ps_matched))
return;
+ if (max_depth) {
+ int slashes = 0;
+ const char *entry = ent->name + prefix_offset;
+ while ((entry = strchr(entry, '/')) != NULL) {
+ slashes++;
+ if (slashes >= max_depth)
+ return;
+ entry++;
+ }
+ }
+
fputs(tag, stdout);
write_name_quoted(ent->name + offset, stdout, line_terminator);
}
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Nguyễn Thái Ngọc Duy @ 2010-01-07 17:07 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 31 +++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index e16638e..f63b039 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -11,6 +11,7 @@
#include "builtin.h"
#include "tree.h"
#include "parse-options.h"
+#include "run-command.h"
static int abbrev;
static int show_deleted;
@@ -31,6 +32,7 @@ static char *ps_matched;
static const char *with_tree;
static int exc_given;
static int max_depth = 0;
+static int show_colums = 0;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -461,6 +463,7 @@ static int option_parse_exclude_standard(const struct option *opt,
int cmd_ls_files(int argc, const char **argv, const char *prefix)
{
+ struct child_process cp;
int require_work_tree = 0, show_tag = 0;
struct dir_struct dir;
struct option builtin_ls_files_options[] = {
@@ -513,6 +516,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "with-tree", &with_tree, "tree-ish",
"pretend that paths removed since <tree-ish> are still present"),
OPT_INTEGER(0, "max-depth", &max_depth, "max recursive depth"),
+ OPT_BOOLEAN(0, "columns", &show_colums, "show in columns"),
OPT__ABBREV(&abbrev),
OPT_END()
};
@@ -591,6 +595,20 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
die("ls-files --with-tree is incompatible with -s or -u");
overlay_tree_on_cache(with_tree, prefix);
}
+
+ if (show_colums) {
+ const char *argv[] = { "column", NULL };
+
+ memset(&cp, 0, sizeof(cp));
+ cp.in = -1;
+ cp.out = dup(1);
+ cp.argv = argv;
+ start_command(&cp);
+ close(1);
+ dup2(cp.in, 1);
+ close(cp.in);
+ }
+
show_files(&dir, prefix);
if (ps_matched) {
@@ -602,5 +620,18 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
return bad ? 1 : 0;
}
+ if (show_colums) {
+ fflush(stdout);
+ close(1);
+ finish_command(&cp);
+ }
+
return 0;
}
+
+int cmd_ls(int argc, const char **argv, const char *prefix)
+{
+ max_depth = 1;
+ show_colums = 1;
+ return cmd_ls_files(argc, argv, prefix);
+}
diff --git a/builtin.h b/builtin.h
index c3f83c0..d8980e5 100644
--- a/builtin.h
+++ b/builtin.h
@@ -61,6 +61,7 @@ extern int cmd_init_db(int argc, const char **argv, const char *prefix);
extern int cmd_log(int argc, const char **argv, const char *prefix);
extern int cmd_log_reflog(int argc, const char **argv, const char *prefix);
extern int cmd_ls_files(int argc, const char **argv, const char *prefix);
+extern int cmd_ls(int argc, const char **argv, const char *prefix);
extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_ls_remote(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 11544cd..4aff5ec 100644
--- a/git.c
+++ b/git.c
@@ -323,6 +323,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "init-db", cmd_init_db },
{ "log", cmd_log, RUN_SETUP | USE_PAGER },
{ "ls-files", cmd_ls_files, RUN_SETUP },
+ { "ls", cmd_ls, RUN_SETUP },
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
{ "ls-remote", cmd_ls_remote },
{ "mailinfo", cmd_mailinfo },
--
1.6.6.315.g1a406
^ permalink raw reply related
* Re: origin/branchname and tracking branch pointing to different commits?
From: Thomas Rast @ 2010-01-07 17:12 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com>
Eugene Sajine wrote:
> $git pull origin qa
[...]
> So, generally, speaking qa branch is fine and is in synch with the
> remote mainline, but the state of local origin/qa is not clear.
'git pull $remote $branch' does not update the $remote/$branch
remote-tracking branch; it stores in FETCH_HEAD and merges straight
from there.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: origin/branchname and tracking branch pointing to different commits?
From: Eugene Sajine @ 2010-01-07 17:25 UTC (permalink / raw)
To: Thomas Rast, git
In-Reply-To: <201001071813.01187.trast@student.ethz.ch>
On Thu, Jan 7, 2010 at 12:12 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Eugene Sajine wrote:
>> $git pull origin qa
> [...]
>> So, generally, speaking qa branch is fine and is in synch with the
>> remote mainline, but the state of local origin/qa is not clear.
>
> 'git pull $remote $branch' does not update the $remote/$branch
> remote-tracking branch; it stores in FETCH_HEAD and merges straight
> from there.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Yep. That's what i though it is. I.e. origin/branchname will point
always to the last pushed commit only. Isn't it a bit strange that git
fetch doesn't update origin/qa?
Probably the problem is that whenever I'm pulling or pushing to remote
repo i expect the last updated state of particular remote branch to be
reflected in origin/branchname, but IMHO it is correct expectation...
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Matthieu Moy @ 2010-01-07 17:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This is a hack, to scratch my itch. These patches add "git ls",
> which is equivalent to "git ls-files --max-depth 1|column"
You also want --exclude-standard to be the default in porcelain.
I've had "alias.ls = ls-files --exclude-standard" for a while in my
~/.gitconfig ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 0/3] Bringing git-ls-files to porcelain level
From: Nguyen Thai Ngoc Duy @ 2010-01-07 17:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq3a2hlsnx.fsf@bauges.imag.fr>
On 1/8/10, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > This is a hack, to scratch my itch. These patches add "git ls",
> > which is equivalent to "git ls-files --max-depth 1|column"
>
>
> You also want --exclude-standard to be the default in porcelain.
>
> I've had "alias.ls = ls-files --exclude-standard" for a while in my
> ~/.gitconfig ;-).
Yeah, just added that after realizing "git ls -o" is too annoying.
--
Duy
^ permalink raw reply
* Re: base85: Two tiny fixes
From: Nicolas Pitre @ 2010-01-07 17:58 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001071558.30065.agruen@suse.de>
On Thu, 7 Jan 2010, Andreas Gruenbacher wrote:
> While looking at the base85 code I found a bug in the debug code and an
> unnecessary call. You may want to have a look at the two fixes here:
>
> http://www.kernel.org/pub/scm/linux/kernel/git/agruen/git.git
ACK. Please post them to this list.
> There is another little oddity in the way the de85 table is set up: 0
> indicates an invalid entry; to avoid this from clashing with a valid entry,
> valid entries are incremented by one and decremented again while decoding.
> This leads to slightly worse code than using a negative number to indicate
> invalid values (and avoiding to increment/decrement).
You can make a patch to modify that as well if you wish. And in that
case don't forget to make de85 explicitly signed as a char is unsigned
by default on some platforms.
Nicolas
^ permalink raw reply
* Strange happening with 'git fetch'
From: David Kirk @ 2010-01-07 17:59 UTC (permalink / raw)
To: git
This is very strange, and defies the understanding of everyone in the
office familiar with git. Is it a bug, or some feature we don't
understand?
Basically, when I do a 'git fetch', it updates my local repository.
Now nobody else is doing anything, so the remote repository does not
change. Doing another 'git fetch' should report that nothing needs to
be done and nothing should change. But instead, it reports something
about the remote HEAD, and changes my local branch 'master' to some
strange location! Running 'git fetch' again restores it to the
correct state, reporting that it is updating 'master'. Repeated
invocations will toggle between these two results. Below is a
transcript from the bash shell.
Can someone please explain this?
---- bash console ----
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 03c60a4...209b0bc HEAD -> origin/HEAD (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 209b0bc...03c60a4 master -> origin/master (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 03c60a4...209b0bc HEAD -> origin/HEAD (forced update)
dkirk@RI-ENG-21 /c/Dev/TSWeb2 (master)
$ git fetch
From //10.18.0.53/git/repos/WebTrading
+ 209b0bc...03c60a4 master -> origin/master (forced update)
Thanks,
-David
^ permalink raw reply
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +
> + if (show_colums) {
> + const char *argv[] = { "column", NULL };
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.in = -1;
> + cp.out = dup(1);
> + cp.argv = argv;
> + start_command(&cp);
> + close(1);
> + dup2(cp.in, 1);
> + close(cp.in);
> + }
I think the code for columnar output used in producing "git help -a"
output should be reusable (if not, should be made reusable and reused
here).
^ permalink raw reply
* Re: [PATCH 2/3] ls-files: support -o --max-depth (more of a hack as fill_directory should support this)
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Subject: Re: [PATCH 2/3] ls-files: support -o --max-depth (more of a hack
as fill_directory should support this)
Perhaps you would want to look at how builtin_grep()'s walker and the
walker in dir.c can be consolidated? The former has support for
max_depth.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-merge: reword references to "remote" and "pull"
From: Junio C Hamano @ 2010-01-07 18:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <2e53c91e536e1ff585bc7464c1b8863e6cc45c45.1262883414.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The git-merge manpage was written in terms of merging a "remote",
> which is no longer the case: you merge local or remote-tracking
> branches; pull is for actual remotes.
>
> Adjust the manpage accordingly. We refer to the arguments as
> "commits", and change instances of "remote" to "other" (where branches
> are concerned) or "theirs" (where conflict sides are concerned).
> Remove the single reference to "pulling".
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
Looks sensible, modulo a few "'theirs' version" that I think should simply
be "their version".
> Out of sheer curiosity:
>
> The git-merge manpage was written in terms of merging a "remote",
> which is no longer the case
>
> Was this ever the case? Or is it just stale terminology?
Somewhere in between stale and lax. Originally we didn't even have
refs/remotes hierarchy and the distinction between what's local and what's
remote was only in the user's head, and "one branch per repository"
(i.e. you do local clone to work on multiple things, and pull between
them), where even a topic-branch merge is to merge a commit from a remote
(= neighbouring repository of your own), was a more widely practiced
workflow.
Saying <commit> is much more correct than <remote> (technically it can
even be a <committish>, i.e. a tag that peels to a commit).
However...
> @@ -33,10 +33,10 @@ include::merge-options.txt[]
> used to give a good default for automated 'git merge'
> invocations.
>
> -<remote>...::
> - Other branch heads to merge into our branch. You need at
> - least one <remote>. Specifying more than one <remote>
> - obviously means you are trying an Octopus.
> +<commit>...::
> + Commits, usually other branch heads, to merge into our branch.
> + You need at least one <commit>. Specifying more than one
> + <commit> obviously means you are trying an Octopus.
I am tempted to suggest describing the command in terms of more common use
pattern, describing the flexible and more general form as "an aside" for
more advanced users, perhaps like this.
<branch>...:
Other branch to merge into the current branch...trying an
Octopus merge.
+
Strictly speaking, these can name arbitrary commits, not necessarily
at the tip of branches. e.g. "git merge topic{tilde}4" lets you merge
the topic except for the last 4 commits.
I don't know if such an arrangement really makes the document more
approachable to new people, or it is making the description longer and
more complicated without helping new people, though (that is why this is
just "I am tempted to").
^ permalink raw reply
* Re: Strange happening with 'git fetch'
From: Ilari Liusvaara @ 2010-01-07 18:07 UTC (permalink / raw)
To: David Kirk; +Cc: git
In-Reply-To: <de73f1891001070959h30e4ecebw7c852f0417647419@mail.gmail.com>
On Thu, Jan 07, 2010 at 11:59:39AM -0600, David Kirk wrote:
> This is very strange, and defies the understanding of everyone in the
> office familiar with git. Is it a bug, or some feature we don't
> understand?
>
> Basically, when I do a 'git fetch', it updates my local repository.
> Now nobody else is doing anything, so the remote repository does not
> change. Doing another 'git fetch' should report that nothing needs to
> be done and nothing should change. But instead, it reports something
> about the remote HEAD, and changes my local branch 'master' to some
> strange location! Running 'git fetch' again restores it to the
> correct state, reporting that it is updating 'master'. Repeated
> invocations will toggle between these two results. Below is a
> transcript from the bash shell.
>
> Can someone please explain this?
I have seen that before. Looks like you have local branch 'HEAD' (_not_
the special ref HEAD) on remote side and that is messing it up.
ls-remote'ing the repository shows 'refs/heads/HEAD', right (there's
also HEAD, that's the required special ref)?
-Ilari
^ permalink raw reply
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Nguyen Thai Ngoc Duy @ 2010-01-07 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx6h4ww3.fsf@alter.siamese.dyndns.org>
On 1/8/10, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > +
> > + if (show_colums) {
> > + const char *argv[] = { "column", NULL };
> > +
> > + memset(&cp, 0, sizeof(cp));
> > + cp.in = -1;
> > + cp.out = dup(1);
> > + cp.argv = argv;
> > + start_command(&cp);
> > + close(1);
> > + dup2(cp.in, 1);
> > + close(cp.in);
> > + }
>
>
> I think the code for columnar output used in producing "git help -a"
> output should be reusable (if not, should be made reusable and reused
> here).
I saw that and even exported term_columns() but was too lazy to make
pretty_print_string_list() something reusable. Will think of it again
when I see this command is worth pushing forward.
--
Duy
^ permalink raw reply
* [PATCH v5] Be more user-friendly when refusing to do something because of conflict.
From: Matthieu Moy @ 2010-01-07 18:10 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1262878552-4775-1-git-send-email-Matthieu.Moy@imag.fr>
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Ahem. *This* one passes the test-suite :-\. Sorry for not having ran it earlier.
Since the test for git-merge is changed a bit, I added the last
paragraph of the commit message.
Documentation/config.txt | 4 ++++
advice.c | 16 ++++++++++++++++
advice.h | 5 +++++
builtin-commit.c | 14 ++++++++++++--
builtin-merge.c | 19 ++++++++++++++-----
builtin-revert.c | 15 ++++++++++++++-
git-pull.sh | 25 +++++++++++++++++++++++--
t/t3030-merge-recursive.sh | 6 ++++--
t/t3501-revert-cherry-pick.sh | 2 +-
9 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 304eabb..8761411 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -130,6 +130,10 @@ advice.*::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwritting local changes.
Default: true.
+ resolveConflict::
+ Advices shown by various commands when conflicts
+ prevent the operation from being performed.
+ Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index cb666ac..3309521 100644
--- a/advice.c
+++ b/advice.c
@@ -3,6 +3,7 @@
int advice_push_nonfastforward = 1;
int advice_status_hints = 1;
int advice_commit_before_merge = 1;
+int advice_resolve_conflict = 1;
static struct {
const char *name;
@@ -11,6 +12,7 @@ static struct {
{ "pushnonfastforward", &advice_push_nonfastforward },
{ "statushints", &advice_status_hints },
{ "commitbeforemerge", &advice_commit_before_merge },
+ { "resolveconflict", &advice_resolve_conflict },
};
int git_default_advice_config(const char *var, const char *value)
@@ -27,3 +29,17 @@ int git_default_advice_config(const char *var, const char *value)
return 0;
}
+
+void NORETURN die_resolve_conflict(const char *me)
+{
+ if (advice_resolve_conflict)
+ /*
+ * Message used both when 'git commit' fails and when
+ * other commands doing a merge do.
+ */
+ die("'%s' is not possible because you have unmerged files.\n"
+ "Please, fix them up in the work tree, and then use 'git add/rm <file>' as\n"
+ "appropriate to mark resolution and make a commit, or use 'git commit -a'.", me);
+ else
+ die("'%s' is not possible because you have unmerged files.", me);
+}
diff --git a/advice.h b/advice.h
index 3de5000..acd5fdd 100644
--- a/advice.h
+++ b/advice.h
@@ -1,10 +1,15 @@
#ifndef ADVICE_H
#define ADVICE_H
+#include "git-compat-util.h"
+
extern int advice_push_nonfastforward;
extern int advice_status_hints;
extern int advice_commit_before_merge;
+extern int advice_resolve_conflict;
int git_default_advice_config(const char *var, const char *value);
+extern void NORETURN die_resolve_conflict(const char *me);
+
#endif /* ADVICE_H */
diff --git a/builtin-commit.c b/builtin-commit.c
index 592b103..c56dca0 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -244,6 +244,16 @@ static void create_base_index(void)
exit(128); /* We've already reported the error, finish dying */
}
+static void refresh_cache_or_die(int refresh_flags)
+{
+ /*
+ * refresh_flags contains REFRESH_QUIET, so the only errors
+ * are for unmerged entries.
+ */
+ if (refresh_cache(refresh_flags | REFRESH_IN_PORCELAIN))
+ die_resolve_conflict("commit");
+}
+
static char *prepare_index(int argc, const char **argv, const char *prefix, int is_status)
{
int fd;
@@ -283,7 +293,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (all || (also && pathspec && *pathspec)) {
int fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die("unable to write new_index file");
@@ -302,7 +312,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
*/
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die("unable to write new_index file");
diff --git a/builtin-merge.c b/builtin-merge.c
index f1c84d7..79a35c3 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -847,11 +847,20 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
const char *best_strategy = NULL, *wt_strategy = NULL;
struct commit_list **remotes = &remoteheads;
- if (file_exists(git_path("MERGE_HEAD")))
- die("You have not concluded your merge. (MERGE_HEAD exists)");
- if (read_cache_unmerged())
- die("You are in the middle of a conflicted merge."
- " (index unmerged)");
+ if (read_cache_unmerged()) {
+ die_resolve_conflict("merge");
+ }
+ if (file_exists(git_path("MERGE_HEAD"))) {
+ /*
+ * There is no unmerged entry, don't advise 'git
+ * add/rm <file>', just 'git commit'.
+ */
+ if (advice_resolve_conflict)
+ die("You have not concluded your merge (MERGE_HEAD exists).\n"
+ "Please, commit your changes before you can merge.");
+ else
+ die("You have not concluded your merge (MERGE_HEAD exists).");
+ }
/*
* Check if we are _not_ on a detached HEAD, i.e. if there is a
diff --git a/builtin-revert.c b/builtin-revert.c
index 151aa6a..d14dde3 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -233,6 +233,19 @@ static struct tree *empty_tree(void)
return tree;
}
+static NORETURN void die_dirty_index(const char *me)
+{
+ if (read_cache_unmerged()) {
+ die_resolve_conflict(me);
+ } else {
+ if (advice_commit_before_merge)
+ die("Your local changes would be overwritten by %s.\n"
+ "Please, commit your changes or stash them to proceed.", me);
+ else
+ die("Your local changes would be overwritten by %s.\n", me);
+ }
+}
+
static int revert_or_cherry_pick(int argc, const char **argv)
{
unsigned char head[20];
@@ -269,7 +282,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (get_sha1("HEAD", head))
die ("You do not have a valid HEAD");
if (index_differs_from("HEAD", 0))
- die ("Dirty index: cannot %s", me);
+ die_dirty_index(me);
}
discard_cache();
diff --git a/git-pull.sh b/git-pull.sh
index 9e69ada..54ce0af 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -13,8 +13,29 @@ set_reflog_action "pull $*"
require_work_tree
cd_to_toplevel
-test -z "$(git ls-files -u)" ||
- die "You are in the middle of a conflicted merge."
+
+die_conflict () {
+ git diff-index --cached --name-status -r --ignore-submodules HEAD --
+ if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
+ die "Pull is not possible because you have unmerged files.
+Please, fix them up in the work tree, and then use 'git add/rm <file>'
+as appropriate to mark resolution, or use 'git commit -a'."
+ else
+ die "Pull is not possible because you have unmerged files."
+ fi
+}
+
+die_merge () {
+ if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
+ die "You have not concluded your merge (MERGE_HEAD exists).
+Please, commit your changes before you can merge."
+ else
+ die "You have not concluded your merge (MERGE_HEAD exists)."
+ fi
+}
+
+test -z "$(git ls-files -u)" || die_conflict
+test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity=
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 9b3fa2b..9929f82 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -276,11 +276,13 @@ test_expect_success 'fail if the index has unresolved entries' '
test_must_fail git merge "$c5" &&
test_must_fail git merge "$c5" 2> out &&
+ grep "not possible because you have unmerged files" out &&
+ git add -u &&
+ test_must_fail git merge "$c5" 2> out &&
grep "You have not concluded your merge" out &&
rm -f .git/MERGE_HEAD &&
test_must_fail git merge "$c5" 2> out &&
- grep "You are in the middle of a conflicted merge" out
-
+ grep "Your local changes to .* would be overwritten by merge." out
'
test_expect_success 'merge-recursive remove conflict' '
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index bb4cf00..7f85815 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -66,7 +66,7 @@ test_expect_success 'revert forbidden on dirty working tree' '
echo content >extra_file &&
git add extra_file &&
test_must_fail git revert HEAD 2>errors &&
- grep "Dirty index" errors
+ grep "Your local changes would be overwritten by " errors
'
--
1.6.6.198.g3c5474
^ permalink raw reply related
* Re: [PATCH 3/3] Add "ls", which is basically ls-files with user-friendly settings
From: Matthieu Moy @ 2010-01-07 18:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262884076-12293-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
You should put the "which is equivalent to "git ls-files --max-depth
1|column"" part of your cover letter here I think to make the patch
self-contained.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* merging two equivalent branches
From: David Reitter @ 2010-01-07 18:17 UTC (permalink / raw)
To: git
Hello,
I have a problem with my git project, resulting from an upstream branch beyond my control being rewritten.
Can I specify parents for a revision whose history is hidden from git-log?
Concretely, I need to merge two branches that represent different conversions of the same original CVS branch (with >100k revisions).
I've been working with converted branch B, but now we have a new branch A. Revisions A150 and B145 correspond to the same tree, but there is no common ancestor:
A1 -> A2 -> A3 -> .. -> A150 (A)
B1 -> B2 -> B3 -> .. -> B145 (B)
I have a published downstream branch C with my own changes that started somewhere from B and has occasionally merged new developments from B. I'd now like to switch it to A. Future development will show up on A and I'd like to be able to merge it into C when that happens.
Using "git-merge -s ours" does this job nicely so that I can pull further development from the remote branch into mine.
However, git-log follows both parents of the new merge commit and thus shows many redundant commits. This is OK from the logical perspective, but because I have used the "ours" merge strategy, we're guaranteed to have only one revisions in the final tree. Thus, I wouldn't want to see all these revisions in the resulting branch. Grafts/rewrites or git-replace would probably lead to the same issue, I reckon.
Thanks for your help.
^ permalink raw reply
* Re: merging two equivalent branches
From: Christian MICHON @ 2010-01-07 18:22 UTC (permalink / raw)
To: David Reitter; +Cc: git
In-Reply-To: <B0543B3C-C139-4BD3-B028-58B4DA132422@gmail.com>
On Thu, Jan 7, 2010 at 7:17 PM, David Reitter <david.reitter@gmail.com> wrote:
> Hello,
>
> I have a problem with my git project, resulting from an upstream branch beyond my control being rewritten.
>
> Can I specify parents for a revision whose history is hidden from git-log?
>
I recall asking a similar question in 2008, and the answer was to look
at "git graft" and use "git filter-branch" to recreate history.
My 2 cents
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] Documentation: do not advertise --all in git-pull(1)
From: Zing @ 2010-01-07 18:25 UTC (permalink / raw)
To: git
In-Reply-To: <a6112d286c5deeb4cc2ccfb1a90ff384440c1341.1262880109.git.trast@student.ethz.ch>
On Thu, 07 Jan 2010 17:09:33 +0100, Thomas Rast wrote:
> This one fixes the documentation problem, but I think there's a deeper
> misunderstanding. What did you hope to do with 'git pull --all'? I
> suspect most people on this list would take it to mean "fetch all
> branches from all remotes, and merge them into HEAD". I cannot imagine
> a use-case where that would make any sense. (And it wouldn't work,
> because the current implementation of 'git fetch --all' leaves only the
> last remote's branches in FETCH_HEAD.)
>
> From earlier discussions on the non-intuitiveness of git-pull, I kind of
> suspect you wanted to fetch all remotes, and then "update" all local
> branches that track some remote with their corresponding remote-tracking
> branches. In which case the question is: why do you use local branches
> if you have them "blindly" track the upstream?
Let me just state first that I'm a casual git user and I would have
missed those earlier discussions.... sorry if this old news:
I do basically just use git to just "blindly" track upstream repos/
projects using local branches. I realize this is "dumb" in a sense,
because it's basically just a copy of the remote branch that needs to be
fast-forwarded all the time; but it's just a handy lazy way for me to
remember which remote branches I want to "watch" with just a 'git branch'
command, plus it's easier and shorter to just type the local branch names
I specify than to type for example "origin/something" or "myotherremote/
something".
What I thought 'git pull --all' would do is just pass down the --all flag
to fetch and that's it:
1. do a 'git fetch --all'
2. then do a 'git merge <tracked remote branch of the current local
branch>', basically, in my case, just fast-forwarding my current local
branch if need be.
I didn't think that 'git pull --all' would "update" all local branches
that needed to be fast-forwarded. It would be too, how to say, "messy"
in the output, and not really what 'git pull' alone was doing before. I
did think it could be a possibility, so, really, I was trying it out to
see what would happen.
The other possibility you mentioned about fetching all branches and then
merging all of them to HEAD, didn't occur to me at all. I can see now
how it could make more intuitive sense from the perspective of a more
"experienced" git person. Personally, I don't think I'd ever need
something like that. HTH.
^ permalink raw reply
* Re: Difference between pull --rebase and fetch+rebase
From: martinvz @ 2010-01-07 18:44 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d1001070800k6fa501fej39b84f849b7e5b50@mail.gmail.com>
Thanks for your post, Santi. I can not share my repository since it is a
project at work. I was troubleshooting a bit myself and found the following
section in git-pull.sh:
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
for reflog in $(git rev-list -g $remoteref 2>/dev/null)
do
if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
then
oldremoteref="$reflog"
break
fi
done
Why is it that reflog entries are allowed to override the remote reference?
Thanks,
Martin
Santi Béjar-2 wrote:
>
> On Thu, Jan 7, 2010 at 1:23 PM, martinvz
> <martin.von.zweigbergk@gmail.com> wrote:
>>
>> I have a branch configured to track a remote branch by rebasing. I
>> excepted
>> that "git pull" would therefore be equivalent to fetching from the remote
>> repository followed by rebasing the remote branch, but it isn't. When
>> doing
>> "git rebase <remote>/<branch>", it applies only the commits after the
>> merge
>> base. When doing "git pull", it tries to apply two more commits (the two
>> commits preceding the merge base). Why is this?
>>
>> I get the same result even if I do "git pull --rebase <remote> <branch>",
>> it
>> doesn't seem to have anything to do with incorrect configuration of the
>> branch.
>
> Yes, both should do the same (at least when upstream is not rebased).
> Can you provide a test case or instructions to reproduce the behavior?
>
> Thanks,
> Santi
> --
> 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
>
>
--
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4268064.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Add quiet option to git-ls-files
From: Ramkumar Ramachandra @ 2010-01-07 19:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
Hi,
I just wrote a couple of patches. I'm sorry for having to attach the
files- I'm behind a HTTP proxy, and Gmail mangles patches.
Thanks and regards,
Ramkumar
[-- Attachment #2: 0001-Add-quiet-option-to-git-ls-files.patch --]
[-- Type: text/x-patch, Size: 2284 bytes --]
From f5f76190a833bf105483a7da9b4b61ab03e373ba Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Thu, 7 Jan 2010 23:58:08 +0530
Subject: [PATCH 1/2] Add quiet option to git-ls-files
--quiet option suppresses error output in --error-unmatch mode. Modify
documentation to reflect changes.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/git-ls-files.txt | 6 ++++++
builtin-ls-files.c | 12 +++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 625723e..0a1f94e 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -82,6 +82,12 @@ OPTIONS
Skips files matching pattern.
Note that pattern is a shell wildcard pattern.
+--q::
+--quiet::
+ Only meaningful in --error-unmatch mode. Do not output an
+ error message if <file> does not appear in the index. Instead
+ exit with non-zero status silently.
+
-X <file>::
--exclude-from=<file>::
exclude patterns are read from <file>; 1 per line.
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index c9a03e5..40560da 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -421,12 +421,13 @@ static int option_parse_exclude_standard(const struct option *opt,
int cmd_ls_files(int argc, const char **argv, const char *prefix)
{
- int require_work_tree = 0, show_tag = 0;
+ int require_work_tree = 0, show_tag = 0, quiet = 0;
struct dir_struct dir;
struct option builtin_ls_files_options[] = {
{ OPTION_CALLBACK, 'z', NULL, NULL, NULL,
"paths are separated with NUL character",
PARSE_OPT_NOARG, option_parse_z },
+ OPT__QUIET(&quiet),
OPT_BOOLEAN('t', NULL, &show_tag,
"identify the file status with tags"),
OPT_BOOLEAN('v', NULL, &show_valid_bit,
@@ -547,10 +548,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
if (ps_matched) {
int bad;
- bad = report_path_error(ps_matched, pathspec, prefix_offset);
- if (bad)
- fprintf(stderr, "Did you forget to 'git add'?\n");
-
+ if (!quiet) {
+ bad = report_path_error(ps_matched, pathspec, prefix_offset);
+ if (bad)
+ fprintf(stderr, "Did you forget to 'git add'?\n");
+ }
return bad ? 1 : 0;
}
--
1.6.5
[-- Attachment #3: 0002-Replace-redirect-to-dev-null-in-favor-of-quiet-optio.patch --]
[-- Type: text/x-patch, Size: 3664 bytes --]
From b5c7a0fb8d092aafcedcbd653f00dee564a0d953 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Fri, 8 Jan 2010 00:00:58 +0530
Subject: [PATCH 2/2] Replace redirect to /dev/null in favor of quiet option
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
git-mergetool.sh | 2 +-
git-pull.sh | 2 +-
git-rebase.sh | 2 +-
git-stash.sh | 12 ++++++------
git-submodule.sh | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index b52a741..1c902aa 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -101,7 +101,7 @@ resolve_deleted_merge () {
return 0
;;
[dD]*)
- git rm -- "$MERGED" > /dev/null
+ git rm --quiet -- "$MERGED"
cleanup_temp_files
return 0
;;
diff --git a/git-pull.sh b/git-pull.sh
index 9e69ada..336e91a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -170,7 +170,7 @@ test true = "$rebase" && {
. git-parse-remote &&
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
- for reflog in $(git rev-list -g $remoteref 2>/dev/null)
+ for reflog in $(git rev-list --quiet --walk-reflogs $remoteref)
do
if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
then
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..bfe0475 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -100,7 +100,7 @@ call_merge () {
cmt="$(cat "$dotest/cmt.$1")"
echo "$cmt" > "$dotest/current"
hd=$(git rev-parse --verify HEAD)
- cmt_name=$(git symbolic-ref HEAD 2> /dev/null || echo HEAD)
+ cmt_name=$(git symbolic-ref --quiet HEAD || echo HEAD)
msgnum=$(cat "$dotest/msgnum")
end=$(cat "$dotest/end")
eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
diff --git a/git-stash.sh b/git-stash.sh
index 3a0685f..5605d19 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -39,7 +39,7 @@ clear_stash () {
then
die "git stash clear with parameters is unimplemented"
fi
- if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
+ if current=$(git rev-parse --quiet --verify $ref_stash)
then
git update-ref -d $ref_stash $current
fi
@@ -200,7 +200,7 @@ save_stash () {
}
have_stash () {
- git rev-parse --verify $ref_stash >/dev/null 2>&1
+ git rev-parse --quiet --verify $ref_stash >/dev/null
}
list_stash () {
@@ -337,16 +337,16 @@ drop_stash () {
fi
# Verify supplied argument looks like a stash entry
s=$(git rev-parse --verify "$@") &&
- git rev-parse --verify "$s:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+ git rev-parse --quiet --verify "$s:" > /dev/null &&
+ git rev-parse --quiet --verify "$s^1:" > /dev/null &&
+ git rev-parse --quiet --verify "$s^2:" > /dev/null ||
die "$*: not a valid stashed state"
git reflog delete --updateref --rewrite "$@" &&
say "Dropped $* ($s)" || die "$*: Could not drop stash entry"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse --quiet --verify "$ref_stash@{0}" > /dev/null || clear_stash
}
apply_to_branch () {
diff --git a/git-submodule.sh b/git-submodule.sh
index 77d2232..2b6448f 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -196,7 +196,7 @@ cmd_add()
tstart
s|/*$||
')
- git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
+ git ls-files --quiet --error-unmatch "$path" > /dev/null &&
die "'$path' already exists in the index"
# perhaps the path exists and is already a git repo, else clone it
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] Add quiet option to git-ls-files
From: Junio C Hamano @ 2010-01-07 20:19 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <f3271551001071137u6158fa4fm1bf7a51a83354574@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index 625723e..0a1f94e 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -82,6 +82,12 @@ OPTIONS
> Skips files matching pattern.
> Note that pattern is a shell wildcard pattern.
>
> +--q::
> +--quiet::
> + Only meaningful in --error-unmatch mode. Do not output an
> + error message if <file> does not appear in the index. Instead
> + exit with non-zero status silently.
The code doesn't seem to match the claim.
> diff --git a/builtin-ls-files.c b/builtin-ls-files.c
> index c9a03e5..40560da 100644
> --- a/builtin-ls-files.c
> +++ b/builtin-ls-files.c
> @@ -547,10 +548,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
>
> if (ps_matched) {
> int bad;
> + if (!quiet) {
> + bad = report_path_error(ps_matched, pathspec, prefix_offset);
> + if (bad)
> + fprintf(stderr, "Did you forget to 'git add'?\n");
> + }
> return bad ? 1 : 0;
> }
You might have seen that the code returns 1 during your testing, but that
is not because ps_matched[] was inspected, but because you are checking an
uninitialized garbage on stack in "bad" that happened to be non-zero.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Junio C Hamano @ 2010-01-07 20:19 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Schindelin, git
In-Reply-To: <20100107200509.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> When rewriting commits on a topic branch, sometimes it is easier to
> compare the version of commits before and after the rewrite if they are
> based on the same commit that forked from the upstream. An earlier commit
> by Junio (fixed up by the previous commit) gives "--onto A...B" syntax to
> rebase command, and rebases on top of the merge base between A and B;
> teach the same to the interactive version, too.
>
> Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
> ---
> git-rebase--interactive.sh | 21 ++++++++++++++++++++-
> t/t3415-rebase-onto-threedots.sh | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 50 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 23ded48..f7ae02c 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -482,6 +482,25 @@ get_saved_options () {
> test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
> }
>
> +LF='
> +'
> +parse_onto () {
> + case "$1" in
> + *...*)
> + if left=${1%...*} right=${1#*...} &&
> + onto=$(git merge-base --all ${left:-HEAD} ${right:-HEAD})
> + then
> + case "$onto" in
> + ?*"$LF"?* | '')
> + exit 1 ;;
> + esac
> + echo "$onto"
> + exit 0
> + fi
> + esac
> + git rev-parse --verify "$1^0"
> +}
> +
> while test $# != 0
> do
> case "$1" in
I am a bit unhappy about the duplication. The text of this function is
different from the one in "rebase" proper, but they implement essentially
the same logic. I was tempted to suggest having a common helper function,
but as Dscho mentioned "rebase -i" implementation does not share much with
"rebase" (even though it shares the external command line interface from
the end user's point of view), and I don't see a readily available place
(other than in git-sh-setup) to do so.
Ideas?
^ 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