* Re: git apply --directory broken for new files
From: Jeff King @ 2008-09-27 1:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Johannes Schindelin, Junio C Hamano, Shawn O. Pearce,
Git Mailing List
In-Reply-To: <48DBF794.9030809@zytor.com>
On Thu, Sep 25, 2008 at 01:41:56PM -0700, H. Peter Anvin wrote:
> Trying with git 1.6.0.1:
>
> : tazenda 124 ; git apply --directory=gpxe/ < /tmp/diff
> fatal: git-apply: bad git-diff - inconsistent new filename on line 105
Hmm. It looks like this is broken for deletion, too. I believe the
problem is just that when sanity checking "diff --git" patches, we
weren't applying the --directory root consistently.
I think this fix is sane, but I would appreciate ACKs from Dscho and
Junio, who wrote the --directory code and the patch sanity checking
code, respectively.
-- >8 --
apply --directory: handle creation and deletion patches
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-apply.c | 7 +++++++
t/t4128-apply-root.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 2ab4aba..f9070d5 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -787,6 +787,13 @@ static char *git_header_name(char *line, int llen)
break;
}
if (second[len] == '\n' && !memcmp(name, second, len)) {
+ if (root) {
+ char *ret = xmalloc(root_len + len + 1);
+ strcpy(ret, root);
+ memcpy(ret + root_len, name, len);
+ ret[root_len + len] = '\0';
+ return ret;
+ }
return xmemdupz(name, len);
}
}
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index 2dd0c75..bd1bdf1 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -40,4 +40,39 @@ test_expect_success 'apply --directory -p (2) ' '
'
+cat > patch << EOF
+diff --git a/newfile b/newfile
+new file mode 100644
+index 0000000..d95f3ad
+--- /dev/null
++++ b/newfile
+@@ -0,0 +1 @@
++content
+EOF
+
+test_expect_success 'apply --directory (new file)' '
+ git reset --hard initial &&
+ git apply --directory=some/sub/dir/ --index patch &&
+ test content = $(git show :some/sub/dir/newfile) &&
+ test content = $(cat some/sub/dir/newfile)
+'
+
+cat > patch << EOF
+diff --git a/delfile b/delfile
+deleted file mode 100644
+index d95f3ad..0000000
+--- a/delfile
++++ /dev/null
+@@ -1 +0,0 @@
+-content
+EOF
+
+test_expect_success 'apply --directory (delete file)' '
+ git reset --hard initial &&
+ echo content >some/sub/dir/delfile &&
+ git add some/sub/dir/delfile &&
+ git apply --directory=some/sub/dir/ --index patch &&
+ ! git ls-files | grep delfile
+'
+
test_done
--
1.6.0.2.517.g8be702.dirty
^ permalink raw reply related
* Re: [PATCH RFC 4/6] Docs: send-email: Option order the same in man page and usage text
From: Michael Witten @ 2008-09-27 1:13 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20080926224032.GA24817@coredump.intra.peff.net>
On 26 Sep 2008, at 5:40 PM, Jeff King wrote:
> I think overall this serious is well-intentioned the results look sane
> to me (I diffed the manpage and usage text before and after).
>
> My only concerns are:
>
> 4/6: ...
> The manpage, on the other hand, is a comprehensive reference and
> so should probably be alphabetized for easy reading.
I can buy it. I'll change it back.
> ...
> That being said, I find the length of the current usage
> statement
> somewhat ridiculous.
I'll take care of it.
> 5/6: This isn't really a documentation patch, as it adds a new config
> option. I think the result is reasonable, but it was a surprise
> after reading the rest of the series.
I didn't mean to mark those as Docs. I'll fix that too.
> I was also going to complain that there was no entry in
> Documentation/config.txt for the new option, but I see that none
> of the sendemail options are there. Maybe while you are working
> on this, it is worth factoring them out to send-email-
> options.txt
> and including it in both git-send-email.txt and config.txt.
Grumble grumble grumble... erm.. hmm.. grrr.. ok.
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: SZEDER Gábor @ 2008-09-27 0:16 UTC (permalink / raw)
To: Jakub Narebski
Cc: Miklos Vajna, SZEDER Gábor, git, Shawn O. Pearce,
Johannes.Schindelin
In-Reply-To: <m37i8y3mqt.fsf@localhost.localdomain>
Hi all,
On Fri, Sep 26, 2008 at 09:17:39AM -0700, Jakub Narebski wrote:
> 3. Remove reduce_heads() from git-commit entirely, and record in
> MERGE_HEAD (or rather now MERGE_HEADS) _all_ _reduced_ heads.
> _All_ means that HEAD is included in MERGE_HEAD if it is not
> reduced, _reduced_ means that only non-dependent heads are in
> MERGE_HEAD. This for example means that for simple non-octopus
> merge case MERGE_HEAD/MERGE_HEADS now contain _all_ parents,
> and not only other side of merge.
>
> This solution has the advantage of being clear solution, clarifying
> semantic of MERGE_HEAD (currently HEAD is used both as target, i.e.
> where merge is to be recorded, and as one of heads to merge/to
> consider), and making it possible to separate layers: git-merge
> is about merging, git-commit doesn't need to know anything about
> merging.
Well, I'm just following this from the sidelines... but from design
point of view I would prefer #3 because of the clear separation of
the merge and commit steps.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Jakub Narebski @ 2008-09-26 23:51 UTC (permalink / raw)
To: Miklos Vajna; +Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <20080926193122.GW23137@genesis.frugalware.org>
On Fri, 26 Sep 2008, Miklos Vajna wrote:
> On Fri, Sep 26, 2008 at 09:17:39AM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > 1. As proposed above save git-merge options, for example in MERGE_MODE
> > or MERGE_OPTS file, so git-commit knows what options to use if it
> > was invoked to finish a merge.
>
> First, thank you for the detailed description, I'm really bad in them.
> :)
>
> ACK, that's why I implemented this one.
This is I think the fastest and seemingly simplest solution.
> > 2. git-merge saves _reduced_ heads in MERGE_HEAD, and git-commit
> > reduces only HEAD, unless it is in MERGE_HEAD. This means that
> > git-commit uses the following pseudo-code
> >
> > if (resolve_ref(HEAD) == MERGE_HEAD[0]) {
> > /* non fast-forward case */
> > merge HEAD + MERGE_HEAD
> > } else {
> > reduce_HEAD_maybe()
> > merge [HEAD] + MERGE_HEAD
> > }
> >
> > This has the advantage that it doesn't change MERGE_HEAD semantic
> > for simple merge which did not began as octopus
>
> This is wrong IMHO. You can write the reduced heads to MERGE_HEAD but
> you can't know if you can omit the HEAD in case it is reachable already
> from one of the heads or not. That depends on if the user used --no-ff
> or not.
I have tried to explain in above pseudocode git-commit is to use
additional hack to decide whether to try to reduce HEAD wrt MERGE_HEAD
heads (normal case), or not (--no-ff case), namely if resolved HEAD
is first head in MERGE_HEAD that means --no-ff case.
It is "halfway" solution and bit hacky (and ugly).
> > 3. Remove reduce_heads() from git-commit entirely, and record in
> > MERGE_HEAD (or rather now MERGE_HEADS) _all_ _reduced_ heads.
> > _All_ means that HEAD is included in MERGE_HEAD if it is not
> > reduced, _reduced_ means that only non-dependent heads are in
> > MERGE_HEAD. This for example means that for simple non-octopus
> > merge case MERGE_HEAD/MERGE_HEADS now contain _all_ parents,
> > and not only other side of merge.
> >
> > This solution has the advantage of being clear solution, clarifying
> > semantic of MERGE_HEAD (currently HEAD is used both as target, i.e.
> > where merge is to be recorded, and as one of heads to merge/to
> > consider), and making it possible to separate layers: git-merge
> > is about merging, git-commit doesn't need to know anything about
> > merging.
> >
> > The disadvantage is that it changes format (well, semantic) of
> > MERGE_HEAD, possibly breaking users' scripts; perhaps some of
> > git commands like "git log --merge" or "git diff --merge" should
> > be updated on such change.
>
> Actually I think this would be ugly. MERGE_HEAD is about you can see
> what will be merged once you commit the merge, but once you include HEAD
> there, you can't easily check that. Maybe it's just me who sometimes
> have a look at that file myself directly... :-)
The new semantic would be very simple. If there is no MERGE_HEAD, it
is an ordinary no-merge commit, and its only parent would be previous
(current) version of HEAD. If there is MERGE_HEAD it contains _all_
parents in a merge commit, and only those heads which will be parents
(_reduced_ heads); if HEAD is symref, we modify given branch so it
points to newly created merge commit.
Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
then we set this branch to new commit
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Use remove_path from dir.c instead of own implementation
From: Alex Riesen @ 2008-09-26 22:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20080926225645.GA13412@blimp.localhost>
Besides, it fixes a memleak (builtin-rm.c) and accidental change of
the input const argument (builtin-merge-recursive.c).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Sat, Sep 27, 2008 00:56:45 +0200:
> > remove_path is its long-lost soul mate. I'm not applying this
> > builtin-rm fix, and am hoping you'll rewrite it around a move
> > of remove_path to dir.c... ;-)
> >
>
> Okay :) The next one is on top of the previous fix in merge-recursive
> (removes ENOENT conditional)
>
This one.
builtin-apply.c | 11 ++---------
builtin-merge-recursive.c | 21 ++-------------------
builtin-rm.c | 22 +---------------------
3 files changed, 5 insertions(+), 49 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 20bef1f..70c9f93 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -13,6 +13,7 @@
#include "delta.h"
#include "builtin.h"
#include "string-list.h"
+#include "dir.h"
/*
* --check turns on checking that the working tree matches the
@@ -2735,15 +2736,7 @@ static void remove_file(struct patch *patch, int rmdir_empty)
warning("unable to remove submodule %s",
patch->old_name);
} else if (!unlink(patch->old_name) && rmdir_empty) {
- char *name = xstrdup(patch->old_name);
- char *end = strrchr(name, '/');
- while (end) {
- *end = 0;
- if (rmdir(name))
- break;
- end = strrchr(name, '/');
- }
- free(name);
+ remove_path(patch->old_name);
}
}
}
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index a29b47f..36aa798 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -18,6 +18,7 @@
#include "ll-merge.h"
#include "interpolate.h"
#include "attr.h"
+#include "dir.h"
#include "merge-recursive.h"
static int subtree_merge;
@@ -416,24 +417,6 @@ static int update_stages(const char *path, struct diff_filespec *o,
return 0;
}
-static int remove_path(const char *name)
-{
- int ret;
- char *slash, *dirs;
-
- ret = unlink(name);
- if (ret)
- return ret;
- dirs = xstrdup(name);
- while ((slash = strrchr(name, '/'))) {
- *slash = '\0';
- if (rmdir(name) != 0)
- break;
- }
- free(dirs);
- return ret;
-}
-
static int remove_file(int clean, const char *path, int no_wd)
{
int update_cache = index_only || clean;
@@ -444,7 +427,7 @@ static int remove_file(int clean, const char *path, int no_wd)
return -1;
}
if (update_working_directory) {
- if (remove_path(path) && errno != ENOENT)
+ if (remove_path(path))
return -1;
}
return 0;
diff --git a/builtin-rm.c b/builtin-rm.c
index fdac34f..50ae6d5 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -29,26 +29,6 @@ static void add_list(const char *name)
list.name[list.nr++] = name;
}
-static int remove_file(const char *name)
-{
- int ret;
- char *slash;
-
- ret = unlink(name);
- if (ret && errno == ENOENT)
- /* The user has removed it from the filesystem by hand */
- ret = errno = 0;
-
- if (!ret && (slash = strrchr(name, '/'))) {
- char *n = xstrdup(name);
- do {
- n[slash - name] = 0;
- name = n;
- } while (!rmdir(name) && (slash = strrchr(name, '/')));
- }
- return ret;
-}
-
static int check_local_mod(unsigned char *head, int index_only)
{
/* items in list are already sorted in the cache order,
@@ -239,7 +219,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
int removed = 0;
for (i = 0; i < list.nr; i++) {
const char *path = list.name[i];
- if (!remove_file(path)) {
+ if (!remove_path(path)) {
removed = 1;
continue;
}
--
1.6.0.2.328.g14651
^ permalink raw reply related
* [PATCH] Add remove_path: a function to remove as much as possible of a path
From: Alex Riesen @ 2008-09-26 22:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20080926152823.GA17470@spearce.org>
The function has two potential users which both managed to get wrong
their implementations (the one in builtin-rm.c one has a memleak, and
builtin-merge-recursive.c scribles over its const argument).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Shawn O. Pearce, Fri, Sep 26, 2008 17:28:23 +0200:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > It is the same as in merge-recursive, but they're so small so unless
> > we get a special file with such random routines there is no much point
> > exporting it. Actually, we do seem to have such a file: dir.c. It is
> > already plagued by file_exists kind of things, why not remove_path...
>
> Yea. I'm thinking remove_path should migrate to dir.c. Hell,
> we already have rm -rf as remove_dir_recursively() in dir.c.
> remove_path is its long-lost soul mate. I'm not applying this
> builtin-rm fix, and am hoping you'll rewrite it around a move
> of remove_path to dir.c... ;-)
>
Okay :) The next one is on top of the previous fix in merge-recursive
(removes ENOENT conditional)
dir.c | 20 ++++++++++++++++++++
dir.h | 3 +++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/dir.c b/dir.c
index acf1001..1c3c501 100644
--- a/dir.c
+++ b/dir.c
@@ -831,3 +831,23 @@ void setup_standard_excludes(struct dir_struct *dir)
if (excludes_file && !access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
+
+int remove_path(const char *name)
+{
+ char *slash;
+
+ if (unlink(name) && errno != ENOENT)
+ return -1;
+
+ slash = strrchr(name, '/');
+ if (slash) {
+ char *dirs = xstrdup(name);
+ slash = dirs + (slash - name);
+ do {
+ *slash = '\0';
+ } while (rmdir(dirs) && (slash = strrchr(dirs, '/')));
+ free(dirs);
+ }
+ return 0;
+}
+
diff --git a/dir.h b/dir.h
index 2df15de..278ee42 100644
--- a/dir.h
+++ b/dir.h
@@ -81,4 +81,7 @@ extern int is_inside_dir(const char *dir);
extern void setup_standard_excludes(struct dir_struct *dir);
extern int remove_dir_recursively(struct strbuf *path, int only_empty);
+/* tries to remove the path with empty directories along it, ignores ENOENT */
+extern int remove_path(const char *path);
+
#endif
--
1.6.0.2.328.g14651
^ permalink raw reply related
* Re: A note from the interim Git maintainer
From: Jeff King @ 2008-09-26 22:54 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Shawn O. Pearce, git
In-Reply-To: <e2b179460809260624n4b329345q3610069af5af75c2@mail.gmail.com>
On Fri, Sep 26, 2008 at 02:24:31PM +0100, Mike Ralphson wrote:
> Jeff, if you want to switch your BSD builds to Shawn's tree too, I
> made and pushed a tiny change to the gitbuild.sh script to allow for
> the spearce/{branch} format becoming spearce_{branch} in the tag
> names.
Thanks, that's a good idea. I'm building Shawn's master (on my todo is
adding the other branches, too, but I need to tweak my script or tweak
gitbuild.sh and switch to it).
-Peff
^ permalink raw reply
* Re: [BUG] git ls-files -m --with-tree does double output
From: Jeff King @ 2008-09-26 22:50 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <87od2dv7mz.fsf@cup.kalibalik.dk>
On Wed, Sep 24, 2008 at 06:19:32PM +0200, Anders Melchiorsen wrote:
> I think that this is wrong? The combination of -m and --with-tree
> shows duplicate entries. Git 1.6.0.2.
I have confirmed this, and it looks like it has always been that way. It
looks like overlay_tree_on_cache just does a read_tree to pull the tree
into the index, and then we end up with duplicate entries.
I'm not too familiar with the read_tree code, so I am cc'ing Junio (who
is out of touch for a little while) and Linus, who are much more clueful
in this area.
It isn't clear to me which code is _supposed_ to be pulling out such
duplicates here. That is, is read_tree broken, or is
overlay_tree_on_cache just calling it wrong?
-Peff
^ permalink raw reply
* Re: status letters consistency in log and ls-files
From: Jeff King @ 2008-09-26 22:45 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0809261128h4c50d27bq3942bd1b3b66d3ee@mail.gmail.com>
On Fri, Sep 26, 2008 at 02:28:50PM -0400, Leo Razoumov wrote:
> So, depending on which of the commands above are used status "R" could
> mean either Renamed or Removed, "M" is either Modified or unMerged,
> "C" is either Copied or Changed.
>
> Is it possible to make it consistent across related commands?
I think this is rooted in historical reasons. Unfortunately, I don't
think it is possible to reconcile the two outputs at this point, as we
would be breaking any scripts which use the tools.
Out of curiosity, is there a script you are writing or some workflow you
have where you see the output of both? Or did you just notice this while
exploring git?
I ask because there may be a way to alter your workflow to always use
one tool.
-Peff
^ permalink raw reply
* Re: [PATCH RFC 4/6] Docs: send-email: Option order the same in man page and usage text
From: Jeff King @ 2008-09-26 22:40 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <1222375476-32911-4-git-send-email-mfwitten@mit.edu>
On Thu, Sep 25, 2008 at 03:44:34PM -0500, Michael Witten wrote:
> The man page seems to have listed the options in alphabetical order,
> while the usage text used what I would consider an `intuitive' order
> that groups related items and presents them in the order peopl think
> when writing an email.
>
> The manual page has been updated to mirror this order.
I think overall this serious is well-intentioned the results look sane
to me (I diffed the manpage and usage text before and after).
My only concerns are:
4/6: I am not sure about making the order of options the same, as the
two formats serve different purposes. I think "git send-email
--foo" should present the options based on commonality of use.
You clearly got the usage wrong, so I think it is helping you to
figure out quickly what you probably meant.
The manpage, on the other hand, is a comprehensive reference and
so should probably be alphabetized for easy reading.
That being said, I find the length of the current usage statement
somewhat ridiculous. I wonder if it would be better still to just
mention in the usage the overall syntax (i.e., "send-email
[options] <file | directory>", the few most common options (with
minimal description), and then refer to the manpage for complete.
With the goal of taking no more than 10 or so lines (the current
output is 71 lines!).
5/6: This isn't really a documentation patch, as it adds a new config
option. I think the result is reasonable, but it was a surprise
after reading the rest of the series.
I was also going to complain that there was no entry in
Documentation/config.txt for the new option, but I see that none
of the sendemail options are there. Maybe while you are working
on this, it is worth factoring them out to send-email-options.txt
and including it in both git-send-email.txt and config.txt.
-Peff
^ permalink raw reply
* [PATCH] builtin-commit: avoid always using reduce_heads()
From: Miklos Vajna @ 2008-09-26 19:37 UTC (permalink / raw)
To: spearce; +Cc: SZEDER Gabor, jnareb, Johannes.Schindelin, git
In-Reply-To: <20080926155204.GD17584@spearce.org>
In case git merge --no-ff is used with --no-commit or we have a
conflict, write info about if fast forwards are allowed or not to
$GIT_DIR/MERGE_MODE.
Based on this info, don't run reduce_heads() in case fast-forwards are
denied, to avoid turning a 'merge --no-ff' to a non-merge commit.
Test case by SZEDER Gabor <szeder@ira.uka.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Sep 26, 2008 at 08:52:04AM -0700, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > + printf("debug, deny fast forward\n");
>
> Left over debugging.
Ugh. Removed.
> > + if (!allow_fast_forward)
> > + strbuf_addf(&buf, "deny_fast_forward");
>
> I wonder if the option in the file shouldn't be more related to
> the merge command line option. Its --no-ff to the user. Maybe we
> should call it "no-ff" here? Or "no-fast-forward" if we want to go
> with a longer name that is less likely to be ambiguous in the future?
I changed it to "no-ff" so that it's consistent with the option naming.
builtin-commit.c | 13 ++++++++++++-
builtin-merge.c | 9 +++++++++
t/t7600-merge.sh | 9 +++++++++
3 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 55e1087..f546cf7 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -937,6 +937,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char commit_sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
+ struct stat statbuf;
+ int allow_fast_forward = 1;
git_config(git_commit_config, NULL);
@@ -988,7 +990,15 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = "commit";
pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
}
- parents = reduce_heads(parents);
+ strbuf_reset(&sb);
+ if (!stat(git_path("MERGE_MODE"), &statbuf)) {
+ if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
+ die("could not read MERGE_MODE: %s", strerror(errno));
+ if (!strcmp(sb.buf, "no-ff"))
+ allow_fast_forward = 0;
+ }
+ if (allow_fast_forward)
+ parents = reduce_heads(parents);
/* Finally, get the commit message */
strbuf_init(&sb, 0);
@@ -1040,6 +1050,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unlink(git_path("MERGE_HEAD"));
unlink(git_path("MERGE_MSG"));
+ unlink(git_path("MERGE_MODE"));
unlink(git_path("SQUASH_MSG"));
if (commit_index_files())
diff --git a/builtin-merge.c b/builtin-merge.c
index 5c65a58..20102a0 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -1210,6 +1210,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
merge_msg.len)
die("Could not write to %s", git_path("MERGE_MSG"));
close(fd);
+ fd = open(git_path("MERGE_MODE"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could open %s for writing", git_path("MERGE_MODE"));
+ strbuf_reset(&buf);
+ if (!allow_fast_forward)
+ strbuf_addf(&buf, "no-ff");
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die("Could not write to %s", git_path("MERGE_MODE"));
+ close(fd);
}
if (merge_was_ok) {
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9516f54..98cfc53 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -511,4 +511,13 @@ test_expect_success 'in-index merge' '
test_debug 'gitk --all'
+test_expect_success 'merge --no-ff --no-commit && commit' '
+ git reset --hard c0 &&
+ git merge --no-ff --no-commit c1 &&
+ EDITOR=: git commit &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-26 19:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <m37i8y3mqt.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Fri, Sep 26, 2008 at 09:17:39AM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. As proposed above save git-merge options, for example in MERGE_MODE
> or MERGE_OPTS file, so git-commit knows what options to use if it
> was invoked to finish a merge.
First, thank you for the detailed description, I'm really bad in them.
:)
ACK, that's why I implemented this one.
> 2. git-merge saves _reduced_ heads in MERGE_HEAD, and git-commit
> reduces only HEAD, unless it is in MERGE_HEAD. This means that
> git-commit uses the following pseudo-code
>
> if (resolve_ref(HEAD) == MERGE_HEAD[0]) {
> /* non fast-forward case */
> merge HEAD + MERGE_HEAD
> } else {
> reduce_HEAD_maybe()
> merge [HEAD] + MERGE_HEAD
> }
>
> This has the advantage that it doesn't change MERGE_HEAD semantic
> for simple merge which did not began as octopus
This is wrong IMHO. You can write the reduced heads to MERGE_HEAD but
you can't know if you can omit the HEAD in case it is reachable already
from one of the heads or not. That depends on if the user used --no-ff
or not.
> 3. Remove reduce_heads() from git-commit entirely, and record in
> MERGE_HEAD (or rather now MERGE_HEADS) _all_ _reduced_ heads.
> _All_ means that HEAD is included in MERGE_HEAD if it is not
> reduced, _reduced_ means that only non-dependent heads are in
> MERGE_HEAD. This for example means that for simple non-octopus
> merge case MERGE_HEAD/MERGE_HEADS now contain _all_ parents,
> and not only other side of merge.
>
> This solution has the advantage of being clear solution, clarifying
> semantic of MERGE_HEAD (currently HEAD is used both as target, i.e.
> where merge is to be recorded, and as one of heads to merge/to
> consider), and making it possible to separate layers: git-merge
> is about merging, git-commit doesn't need to know anything about
> merging.
>
> The disadvantage is that it changes format (well, semantic) of
> MERGE_HEAD, possibly breaking users' scripts; perhaps some of
> git commands like "git log --merge" or "git diff --merge" should
> be updated on such change.
Actually I think this would be ugly. MERGE_HEAD is about you can see
what will be merged once you commit the merge, but once you include HEAD
there, you can't easily check that. Maybe it's just me who sometimes
have a look at that file myself directly... :-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Introduce patch factorization in diffcore.
From: Yann Dirson @ 2008-09-26 19:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48DC133A.7010805@op5.se>
On Fri, Sep 26, 2008 at 12:39:54AM +0200, Andreas Ericsson wrote:
> Yann Dirson wrote:
>> " try unchanged files as candidate for copy detection.\n" \
>> +" --factorize_renames\n" \
>> +" factorize renames of all files of a directory.\n" \
>
>
> Use dashes to separate words in arguments, please.
Fortunately, the typo only made it to the help string, thanks for
catching it :)
>> +#include <libgen.h>
>> +
>
> +#ifdef basename
> +# undef basename
> +#endif
>
> We might as well use the GNU version of basename() at least. Even if
> you don't use it, I'd rather not see this bite some unwary programmer
> coming along after you. Worst case scenario, sha1's won't add up if
> POSIX basename alters its argument, making for one fiendishly tricky
> bug to find.
I'll look into that, thanks
>> +/*
>> + * FIXME: we could optimize the 100%-rename case by preventing
>> + * recursion to unfold what we know we would refold here.
>> + * FIXME: do we want to replace linked list with sorted array ?
>
> Either that or a hash. Most of the time seems to be spent in lookups.
> With a hash you get quick lookups and reasonably quick inserts. With
> a sorted array you get lower memory footprint than anything else and
> can bisect your way to the right entry, which performs reasonably
> close to skiplists. The sort overhead might be a deterrant factor,
> but insofar as I understand it trees are always sorted in git anyway,
> so perhaps that'd be the best solution.
Thanks for this insight - I'll wait before changing the data structure,
since the current implementation may need to be able to recurse (consider
renamed subdirs as well as renamed files).
> Apart from that, I'd need to apply the patch to review it properly,
> and I'm far too tired for that now.
>
> I like the direction this is going though, so thanks a lot for doing
> it :)
Great :)
Best regards,
--
Yann
^ permalink raw reply
* Re: [RFC PATCH] detection of directory renames
From: Yann Dirson @ 2008-09-26 19:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bpyb3jci.fsf@localhost.localdomain>
On Thu, Sep 25, 2008 at 04:19:20PM -0700, Jakub Narebski wrote:
> Wonderfull!!!
Wow, I love this feedback :)
> I like it very much, and hope that it would get improved. And that you
> would be able to use it in merges too, to allow for example for new
> files to be created in renamed directory instead of old one which does
> not exist any longer (c.f. http://www.markshuttleworth.com/archives/123
> and following articles).
Yes, that's one of planned things. Along the same line (once renames
are stabilized), I think about extending things so that "split dirs"
are detected as well, so merge can flag a conflict when there is a
doubt that a file would really be added in a "split directory". The
situation may be obvious in my example (arm/ contents dispatched into
bar/ and moved/), but may also be useful when we can detect that a
significant number of files have been moved out of a directory.
> For the future, could you show examples with --abbrev option in use? TIA.
Good idea.
Best regards,
--
Yann
^ permalink raw reply
* status letters consistency in log and ls-files
From: Leo Razoumov @ 2008-09-26 18:28 UTC (permalink / raw)
To: Git Mailing List
Hi Everyone,
I am new yo git and there are few things I find quite odd. For example,
command "git log --name-status" uses the following letters to indicate
file's status
A -- Added
B -- have had their pairing Broken
C -- Copied
D -- Deleted
M -- Modified
R -- Renamed
T -- Type changed (mode, time stamp)
U -- Unmerged
X -- Unknown
At the same time command "git ls-files -v" use different letters to
indicate the same
H -- cached
M -- unmerged
R -- removed/deleted
C -- modified/changed
K -- to be killed
? -- other
So, depending on which of the commands above are used status "R" could
mean either Renamed or Removed, "M" is either Modified or unMerged,
"C" is either Copied or Changed.
Is it possible to make it consistent across related commands?
--Leo--
^ permalink raw reply
* Re: Internal, corporate, shared hosting solutions
From: Johan Herland @ 2008-09-26 18:17 UTC (permalink / raw)
To: git; +Cc: Tom Lanyon, pasky
In-Reply-To: <8B29890D-C03B-4ECE-9BEF-0A8E8EF7233E@netspot.com.au>
On Friday 26 September 2008, Tom Lanyon wrote:
> Hi list,
>
> I'm struggling. There's been a recent adoption of git here by our
> development staff, which is great. However, from an administrative
> point of view, I'm having trouble finding a solution to provide some
> kind of easy, shared, secure and accessible hosting solution to our
> developers.
>
> [...]
I'm pretty much in the exact same situation at $dayjob, and I'm
researching some alternatives as well. So far there seems to be a
couple of options:
1. Gitosis [1]. This is a fairly thin layer of Python scripts running as
a non-privileged "git" user on the server. All users authenticate by
registering their SSH key with Gitosis, and then access repos using
this one "git" user over SSH. Further access control (i.e. read/write
access to each repo) is done by Gitosis itself, and administered by
cloning a gitosis-admin repo, changing some configuration files and
pushing the result back to the server.
2. Gitorious [2]. Don't confuse this with the repo hosting service at
gitorious.org. You can clone the software that runs gitorious.org and
set it up on your own server. This is a much more heavy-weight
Ruby-on-Rails application that provides a nice web interface for
publishing and interacting with repositories. However, it is based on
the same underlying principle of registering your SSH-keys with
Gitorious, and running everything as a non-privileged "git" user.
3. repo.or.cz. I don't know much about how this work, and if it's easily
deployed on an in-house server. However, the repo.or.cz admin (Petr
Baudis, CCed) is active on this list, and can probably fill in the
details.
Feel free to keep me updated on your progress.
Have fun! :)
...Johan
[1]: Gitosis:
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Get it at http://eagain.net/gitweb/?p=gitosis.git;a=summary
[2]: Gitorious: http://gitorious.org/
Get it at http://gitorious.org/projects/gitorious
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Help with merge and git-svn
From: Craig Tataryn @ 2008-09-26 18:02 UTC (permalink / raw)
To: git
In-Reply-To: <20080926172331.GA7879@atjola.homenet>
On Fri, Sep 26, 2008 at 12:23 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.09.26 11:36:48 -0500, Craig Tataryn wrote:
>> Hi, first time poster to kernel.org mailing lists, so if I commit a
>> taboo, please be kind to me :)
>>
>> I have the following scenario:
>>
>> [remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]
>>
>> So my remote developer and I push and pull to/from the shared git
>> repo, and then I sync changes to and from the client's svn repo using
>> git-svn.
>>
>> My problem is, when I am ready to merge changes from my local master
>> branch to trunk-local, if I do a "git merge master" and then try to
>> issue any git-svn commands I get the following errors:
>> ======================
>> $ git merge master
>> Updating d88106e..77b86ae
>> Fast forward
>> community/pom.xml | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> $ git svn dcommit
>> Can't call method "full_url" on an undefined value at
>> /usr/local/git/libexec/git-core/git-svn line 425.
>>
>> $ git svn rebase
>> Unable to determine upstream SVN information from working tree history
>> ======================
>>
>> The only way I've seem to be able to remedy this is if I add the
>> "subtree" merge strategy to the merge command:
>>
>> git merge -s subtree master
>>
>> Then git-svn doesn't get confused about it's repo, but when you look
>> at the repo using gitk, you see something like:
>>
>> [trunk-local]--[remotes/trunk] Merge branch 'master' into trunk-local
>> | \
>> | \
>> | [master]--[remotes/origin/master] "Some commit message from the
>> last master commit"
>> | |
>> | |
>> | /
>> /
>>
>> When I use the normal merge strategy then gitk shows all branches at
>> the same level, but git-svn is of course b0rked.
>>
>> So I guess my question is, am I stuck using "-s subtree", is this the
>> right course of action?? Or can I get this to work with the default
>> strategy? Is this symptomatic of a messed up or disjoint history
>> (i.e. early on I did some --squash merges).
>>
>> I have full control over the shared repo and I don't mind blowing it
>> away and rebuilding it based on what's in SVN if that's what it takes.
>
> The original merge you did ended up as a fast-forward, ie. no merge
> commit was created. I guess that your history is so, that somehow the
> remotes/trunk stuff is reachable through the second parent of some merge
> commit that exists in your history. But git-svn uses --first-parent to
> find its upstream, so it cannot find that in your scenario. I guess it's
> best if you use "git merge --no-ff master" to force the creation of a
> merge commit. Subtree happens to work because it implies --no-ff, but
> I'm not sure whether there might be downsides to using the subtree
> strategy, so I'd rather go with the explicit --no-ff and the normal
> merge strategies.
>
> Björn
>
Thanks for this tip Bjorn, I'll give it a shot.
--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
im: craiger316@hotmail.com, skype: craig.tataryn
^ permalink raw reply
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-26 17:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <qzJgAPRiQZfGnPgFs3xqeXM_jkaODH54dU-hZgP_AftxmMjJxFOfyQ@cipher.nrlssc.navy.mil>
Shawn,
When you get around to merging this series into maint and master,
you'll probably want to redo the merge of Junio's
bc/maint-diff-hunk-header-fix into bc/master-diff-hunk-header-fix.
After applying 'diff hunkpattern: fix misconverted "\{" tex macro introducers'
to bc/maint-diff-hunk-header-fix, he made a mistake when merging
96d1a8e9 into his bc/master-diff-hunk-header-fix which was at 3d8dccd7 to
produce 92bb9785. (gitk fdac6692 makes this easier to see. fdac6692 should
be the current tip of bc/master-diff-hunk...)
The resulting diff.c in 92bb9785, contains _two_ bibtex patterns, one fixed
by the 'diff hunkpattern:...' patch, and one unfixed. The broken bibtex
pattern was eventually fixed, but the duplicate pattern is still there on
the tip of that branch and in next. It would be nice if the merge could be
redone.
Here are the commands, since sometimes it makes more sense this way:
git branch bc/maint-diff-hunk-header-fix 96d1a8e9
git checkout -b bc/master-diff-hunk-header-fix 3d8dccd7
git merge bc/maint-diff-hunk-header-fix
# fix conflict, make sure you choose the right bibtex pattern
# and delete the other. The builtin-funcname patterns were
# also alphabetized on the master branch, so the correct bibtex
# should be moved to the first entry.
# then reapply the other two patches
git checkout bc/maint-diff-hunk-header-fix
git cherry-pick e3bf5e43
git checkout bc/master-diff-hunk-header-fix
git merge bc/maint-diff-hunk-header-fix
git cherry-pick fdac6692
git commit --amend
# Remove Junio's comment about 'fixes bibtex pattern breakage exposed
# by this test'
-brandon
^ permalink raw reply
* Re: Help with merge and git-svn
From: Björn Steinbrink @ 2008-09-26 17:23 UTC (permalink / raw)
To: Craig Tataryn; +Cc: git
In-Reply-To: <8384c2b90809260936m21c14e0dve5b08b021da4a342@mail.gmail.com>
On 2008.09.26 11:36:48 -0500, Craig Tataryn wrote:
> Hi, first time poster to kernel.org mailing lists, so if I commit a
> taboo, please be kind to me :)
>
> I have the following scenario:
>
> [remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]
>
> So my remote developer and I push and pull to/from the shared git
> repo, and then I sync changes to and from the client's svn repo using
> git-svn.
>
> My problem is, when I am ready to merge changes from my local master
> branch to trunk-local, if I do a "git merge master" and then try to
> issue any git-svn commands I get the following errors:
> ======================
> $ git merge master
> Updating d88106e..77b86ae
> Fast forward
> community/pom.xml | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> $ git svn dcommit
> Can't call method "full_url" on an undefined value at
> /usr/local/git/libexec/git-core/git-svn line 425.
>
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history
> ======================
>
> The only way I've seem to be able to remedy this is if I add the
> "subtree" merge strategy to the merge command:
>
> git merge -s subtree master
>
> Then git-svn doesn't get confused about it's repo, but when you look
> at the repo using gitk, you see something like:
>
> [trunk-local]--[remotes/trunk] Merge branch 'master' into trunk-local
> | \
> | \
> | [master]--[remotes/origin/master] "Some commit message from the
> last master commit"
> | |
> | |
> | /
> /
>
> When I use the normal merge strategy then gitk shows all branches at
> the same level, but git-svn is of course b0rked.
>
> So I guess my question is, am I stuck using "-s subtree", is this the
> right course of action?? Or can I get this to work with the default
> strategy? Is this symptomatic of a messed up or disjoint history
> (i.e. early on I did some --squash merges).
>
> I have full control over the shared repo and I don't mind blowing it
> away and rebuilding it based on what's in SVN if that's what it takes.
The original merge you did ended up as a fast-forward, ie. no merge
commit was created. I guess that your history is so, that somehow the
remotes/trunk stuff is reachable through the second parent of some merge
commit that exists in your history. But git-svn uses --first-parent to
find its upstream, so it cannot find that in your scenario. I guess it's
best if you use "git merge --no-ff master" to force the creation of a
merge commit. Subtree happens to work because it implies --no-ff, but
I'm not sure whether there might be downsides to using the subtree
strategy, so I'd rather go with the explicit --no-ff and the normal
merge strategies.
Björn
^ permalink raw reply
* Help with merge and git-svn
From: Craig Tataryn @ 2008-09-26 16:36 UTC (permalink / raw)
To: git
Hi, first time poster to kernel.org mailing lists, so if I commit a
taboo, please be kind to me :)
I have the following scenario:
[remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]
So my remote developer and I push and pull to/from the shared git
repo, and then I sync changes to and from the client's svn repo using
git-svn.
My problem is, when I am ready to merge changes from my local master
branch to trunk-local, if I do a "git merge master" and then try to
issue any git-svn commands I get the following errors:
======================
$ git merge master
Updating d88106e..77b86ae
Fast forward
community/pom.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git svn dcommit
Can't call method "full_url" on an undefined value at
/usr/local/git/libexec/git-core/git-svn line 425.
$ git svn rebase
Unable to determine upstream SVN information from working tree history
======================
The only way I've seem to be able to remedy this is if I add the
"subtree" merge strategy to the merge command:
git merge -s subtree master
Then git-svn doesn't get confused about it's repo, but when you look
at the repo using gitk, you see something like:
[trunk-local]--[remotes/trunk] Merge branch 'master' into trunk-local
| \
| \
| [master]--[remotes/origin/master] "Some commit message from the
last master commit"
| |
| |
| /
/
When I use the normal merge strategy then gitk shows all branches at
the same level, but git-svn is of course b0rked.
So I guess my question is, am I stuck using "-s subtree", is this the
right course of action?? Or can I get this to work with the default
strategy? Is this symptomatic of a messed up or disjoint history
(i.e. early on I did some --squash merges).
I have full control over the shared repo and I don't mind blowing it
away and rebuilding it based on what's in SVN if that's what it takes.
Thanks!
Craig.
--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
im: craiger316@hotmail.com, skype: craig.tataryn
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Jakub Narebski @ 2008-09-26 16:17 UTC (permalink / raw)
To: Miklos Vajna; +Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <20080926151517.GV23137@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> OK, here is the scenario.
>
> The basic problemis that if it's git-commit that creates the merge
> commit and not git-merge, then git-commit does not "know" that git-merge
> was invoked using --no-ff.
>
> --no-ff means that if reduce_heads() removes a parent, that will be a
> problem, since the resulting commit will no longer be a merge commit.
>
> I think we can't avoid storing this info in a MERGE_MODE file, because
> we have to add HEAD to the list of parents in case --no-ff is used, but
> we should not do so in case it's reachable from existing heads and
> --no-ff is not used.
>
> I'll send a patch that does this in a bit.
The following is summary of short dicussion about this issue on #git
see: http://colabti.org/irclogger/irclogger_log/git?date=2008-09-26,Fri#l1176
The problem is that sometimes git-commit finishes doing the merge, be
it use of --no-commit option, or a conflict occurred; depending on
whether git-merge was invoked with or without --no-ff (--ff=never)
option it should recurd reduced or non-reduced heads.
The problem for example occurs in the following situation:
.---.---.---. <--- a <--- HEAD
|\
| \-1---2 <--- b
\
\--x---y <--- c
$ git merge b c
/------------- b
v
.---.---.---.---1---2---M <--- a <--- HEAD
\ /
\--x---y-/ <--- c
$ git merge --no-ff b c
.---.---.---.---------M <--- a <--- HEAD
|\ /|
| \-1---2 | <--- b
\ /
\--x---y/ <--- c
We can select one of the following solutions:
1. As proposed above save git-merge options, for example in MERGE_MODE
or MERGE_OPTS file, so git-commit knows what options to use if it
was invoked to finish a merge.
2. git-merge saves _reduced_ heads in MERGE_HEAD, and git-commit
reduces only HEAD, unless it is in MERGE_HEAD. This means that
git-commit uses the following pseudo-code
if (resolve_ref(HEAD) == MERGE_HEAD[0]) {
/* non fast-forward case */
merge HEAD + MERGE_HEAD
} else {
reduce_HEAD_maybe()
merge [HEAD] + MERGE_HEAD
}
This has the advantage that it doesn't change MERGE_HEAD semantic
for simple merge which did not began as octopus
3. Remove reduce_heads() from git-commit entirely, and record in
MERGE_HEAD (or rather now MERGE_HEADS) _all_ _reduced_ heads.
_All_ means that HEAD is included in MERGE_HEAD if it is not
reduced, _reduced_ means that only non-dependent heads are in
MERGE_HEAD. This for example means that for simple non-octopus
merge case MERGE_HEAD/MERGE_HEADS now contain _all_ parents,
and not only other side of merge.
This solution has the advantage of being clear solution, clarifying
semantic of MERGE_HEAD (currently HEAD is used both as target, i.e.
where merge is to be recorded, and as one of heads to merge/to
consider), and making it possible to separate layers: git-merge
is about merging, git-commit doesn't need to know anything about
merging.
The disadvantage is that it changes format (well, semantic) of
MERGE_HEAD, possibly breaking users' scripts; perhaps some of
git commands like "git log --merge" or "git diff --merge" should
be updated on such change.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [QGit] Some suggestion
From: Marco Costalba @ 2008-09-26 16:15 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE9607A1DA@zch01exm23.fsl.freescale.net>
On Fri, Sep 26, 2008 at 3:57 PM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
> Option 1:
> Telling user just filted is better than nothing. Is it possible
> add tool button tip.
> When mouse over 'Rev list [Felted]", show what filtering.
>
Ok! I agree.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-26 16:00 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <adf1fd3d0809230406r598f6d1l41cd860568de761f@mail.gmail.com>
On 9/23/08, Santi Béjar <santi@agolina.net> wrote:
> While I agree that the checkout attr looks like an attribute (so
> reusing attr.c is a good idea) and $GIT_DIR/info/gitattributes seems a
> good place to specify them, I think it will be better in the config
> $GIT_DIR/config. There it is clear that it is a local thing and you
> have "git config" to read and write them. Additionally you could have
> different patterns in the config (sparse.default, sparse.doc,
> sparse.src,...), although maybe it is not very useful.
>
> I think the main UI to sparse checkout should be a default sparse
> pattern that is used for "all" commands, like merge, reset, and
> checkout. Now it is too easy to escape from the sparse checkout, when
> you merge or checkout a branch with new files, when doing a "git reset
> --hard" (when you abort a failed merge), or when doing a diff
> (specially when you pull).
I have made a patch to save default sparse patterns, something to play
with so we can have better idea how to do it properly.
There is another option --default-sparse in "git clone" and "git
checkout". The option can be used to save default sparse patterns
(specified by --sparse-checkout in "git clone" or --reset-sparse in
"git checkout"). Something like this:
git clone --default-sparse --sparse-checkout=Documentation/ git.git
git checkout --default-sparse --reset-sparse=t/
Default sparse patterns will be used for other unpack_trees()-related
commands like reset, read-tree, merge, pull... For "git checkout" it
will only be used when neither --full, --reset-sparse,
--include-sparse nor --exclude-sparse is present. And it only applies
to newly-added files.
Patch series is in http://repo.or.cz/w/git/pclouds.git (branch
sparse-checkout). Note that it also incorporates fixes and some option
renames.
--
Duy
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid always using reduce_heads()
From: Shawn O. Pearce @ 2008-09-26 15:52 UTC (permalink / raw)
To: Miklos Vajna; +Cc: SZEDER Gabor, jnareb, Johannes.Schindelin, git
In-Reply-To: <1222442432-7430-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> In case git merge --no-ff is used with --no-commit or we have a
> conflict, write info about if fast forwards are allowed or not to
> $GIT_DIR/MERGE_MODE.
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 55e1087..aac5cb4 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -988,7 +990,18 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> reflog_msg = "commit";
> pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
> }
> - parents = reduce_heads(parents);
> + strbuf_reset(&sb);
> + if (!stat(git_path("MERGE_MODE"), &statbuf)) {
> + if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
> + die("could not read MERGE_MODE: %s", strerror(errno));
> + printf("debug, contents of buf: '%s'\n",sb.buf);
> + if (!strcmp(sb.buf, "deny_fast_forward")) {
> + printf("debug, deny fast forward\n");
Left over debugging.
> diff --git a/builtin-merge.c b/builtin-merge.c
> index 5c65a58..973b167 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -1210,6 +1210,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> merge_msg.len)
> die("Could not write to %s", git_path("MERGE_MSG"));
> close(fd);
> + fd = open(git_path("MERGE_MODE"), O_WRONLY | O_CREAT, 0666);
> + if (fd < 0)
> + die("Could open %s for writing", git_path("MERGE_MODE"));
> + strbuf_reset(&buf);
> + if (!allow_fast_forward)
> + strbuf_addf(&buf, "deny_fast_forward");
I wonder if the option in the file shouldn't be more related to
the merge command line option. Its --no-ff to the user. Maybe we
should call it "no-ff" here? Or "no-fast-forward" if we want to go
with a longer name that is less likely to be ambiguous in the future?
--
Shawn.
^ permalink raw reply
* git-stash.sh: don't default to refs/stash if invalid ref supplied
From: Brandon Casey @ 2008-09-26 15:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
commit da65e7c133cd316c9076fbb6b0aeee7bc42a6db8
Author: Brandon Casey <casey@nrlssc.navy.mil>
Date: Tue Sep 23 18:57:09 2008 -0500
git-stash.sh: don't default to refs/stash if invalid ref supplied
<snip>
e.g. 'git stash apply stash@{1}' would fall back to
'git stash apply stash@{0}'
heh, you fixed my spelling "mistake" :), but it wasn't a mistake. Originally
I had:
e.g. 'git stash apply stahs@{1}' would fall back to
'git stash apply stash@{0}'
intending to show that a simple spelling mistake could cause the wrong thing
to be done. The example in the commit message could actually still happen if
there was only a single stash entry. I guess I should have used 'foobar@{1}'. :)
-brandon
^ 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