* Re: linux-next: Tree for Aug 18 (GNU patch and "git diffs: Support symlinks")
From: Sedat Dilek @ 2011-08-18 9:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, git, Jonathan Nieder, Christoph Berg
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On Thu, Aug 18, 2011 at 8:00 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
>
> Changes since 20110817:
>
> The sound-asoc tree lost its build failure.
>
> The tip tree gained a conflict against Linus' tree.
>
> The moduleh tree lost 2 of its merge fixups, but I added another.
>
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" as mentioned in the FAQ on the wiki
> (see below).
>
Just FYI:
Yesterday and today, I had the same problem when applying the
linux-next single patch (see attached ErrMsg text file).
I am using a slightly modified kernel-buildsystem from Debian Kernel
Team (so not building out of a GIT repository).
The GNU/patch I have installed from Debian/sid does not include
symlink-support for git-diff [1].
Jonathan gave me the pointer to install patch package from Debian/experimental.
After reading its Changelog [2] and Debian-bug #243309 [3] I installed
the recommended version.
Indeed, it fixes the issue.
Cristoph, can we have a backport of [1] to patch/sid?
Thanks Jonathan!
- Sedat -
[1] http://git.savannah.gnu.org/cgit/patch.git/commit/?id=f9db7450fa2788377c4567b5d0565b0ddfc1015c
[2] http://packages.debian.org/changelogs/pool/main/p/patch/patch_2.6.1.85-423d-3/changelog
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243309
[-- Attachment #2: ErrMsg_linux-next-patch-did-not-apply.txt --]
[-- Type: text/plain, Size: 4455 bytes --]
[ patch-v3.1-rc2-next-20110818 ]
...
diff --git a/tools/power/cpupower/debug/x86_64/Makefile b/tools/power/cpupower/debug/x86_64/Makefile
index dbf1399..3326217 100644
--- a/tools/power/cpupower/debug/x86_64/Makefile
+++ b/tools/power/cpupower/debug/x86_64/Makefile
@@ -1,10 +1,10 @@
default: all
-centrino-decode: centrino-decode.c
- $(CC) $(CFLAGS) -o centrino-decode centrino-decode.c
+centrino-decode: ../i386/centrino-decode.c
+ $(CC) $(CFLAGS) -o $@ $<
-powernow-k8-decode: powernow-k8-decode.c
- $(CC) $(CFLAGS) -o powernow-k8-decode powernow-k8-decode.c
+powernow-k8-decode: ../i386/powernow-k8-decode.c
+ $(CC) $(CFLAGS) -o $@ $<
all: centrino-decode powernow-k8-decode
diff --git a/tools/power/cpupower/debug/x86_64/centrino-decode.c b/tools/power/cpupower/debug/x86_64/centrino-decode.c
deleted file mode 120000
index 26fb3f1..0000000
--- a/tools/power/cpupower/debug/x86_64/centrino-decode.c
+++ /dev/null
@@ -1 +0,0 @@
-../i386/centrino-decode.c
\ No newline at end of file
diff --git a/tools/power/cpupower/debug/x86_64/powernow-k8-decode.c b/tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
deleted file mode 120000
index eb30c79..0000000
--- a/tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
+++ /dev/null
@@ -1 +0,0 @@
-../i386/powernow-k8-decode.c
\ No newline at end of file
...
$ LC_ALL=C fakeroot make -f debian/rules.gen setup_i386_none_686-small 2>&1 | tee ../setup.log
make -f debian/rules.real setup-flavour ABINAME='-next20110818.3' ARCH='i386' COMPILER='gcc-4.6' FEATURESET='none' FLAVOUR='686-small' KCONFIG='debian/config/config debian/config/kernelarch-x86/config debian/config/kernelarch-x86/config-arch-32 debian/config/i386/none/config.686-iniza debian/config/custom-x86/config-debug debian/config/custom-x86/config-fs debian/config/custom-x86/config-infiniband debian/config/custom-x86/config-isa debian/config/custom-x86/config-isdn debian/config/custom-x86/config-multimedia debian/config/custom-x86/config-pseudofs debian/config/custom-x86/config-staging debian/config/i386/none/config.686-small' KERNEL_ARCH='x86' LOCALVERSION='-686-small' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-686-small' MODULES='True' SOURCEVERSION='3.1.0~rc2-1~next20110818.dileks3' TYPE='plain' UPSTREAMVERSION='3.1.0-rc2' VERSION='3.1.0'
make[1]: Entering directory `/mnt/sdb3/linux-kernel/linux-3.1-rc2'
rm -rf 'debian/build/source'
mkdir -p 'debian/build/source'
cp -al COPYING CREDITS Documentation Kbuild Kconfig MAINTAINERS Makefile README REPORTING-BUGS arch block crypto drivers firmware fs include init ipc kernel lib mm net samples scripts security sound tools usr virt .gitignore .mailmap 'debian/build/source'
cd 'debian/build/source'; python '/mnt/sdb3/linux-kernel/linux-3.1-rc2/debian/bin/patch.apply' --overwrite-home='/mnt/sdb3/linux-kernel/linux-3.1-rc2/debian/patches'
Warning: No version.Debian file, assuming Debian Linux 3.1.0~rc2
1 out of 1 hunk FAILED -- saving rejects to file tools/power/cpupower/debug/x86_64/centrino-decode.c.rej
1 out of 1 hunk FAILED -- saving rejects to file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c.rej
Error: Patch failed
--> Try to apply base.
(+) FAIL linux-next/patch-v3.1-rc2-next-20110818
make[1]: *** [debian/stamps/source] Error 1
make[1]: Leaving directory `/mnt/sdb3/linux-kernel/linux-3.1-rc2'
make: *** [setup_i386_none_686-small_real] Error 2
-dileks // 18-Aug-2011
^ permalink raw reply related
* Re: Branches & directories
From: Michael J Gruber @ 2011-08-18 10:56 UTC (permalink / raw)
To: Michael Witten
Cc: Hilco Wijbenga, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com>
Michael Witten venit, vidit, dixit 18.08.2011 07:52:
> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> It would be really nice, though, if Git could somehow
>> "stash" such files when checking out a different branch. In general, I
>> would prefer if uncommitted changes and untracked and/or ignored files
>> stuck to the branch where they were created.
>
> As an aside, the problem here is likely a manifestation of the fact
> that nobody understands what a branch is; the word 'branch' is
I would reject "nobody"...
> TERRIBLE, as everyone has a different idea for what that should mean.
... and insist that this statement is true either trivially true for all
words, or for none, depending on your understanding of "everyone has a
different".
> In my opinion, `git branch' should become `git ref' or the like.
"branch" and "tag" are boths refs. Their only essential difference is
that one "moves" and the other doesn't.
> One of git's worst faults is that a complicated and imprecise
> interface has been draped over a very simple and precise underlying
> structure.
A name is a name and just that. The use of any existing word may clash
with someone's expectations.
I find the concepts "file created on a branch", "commit created on a
branch" silly, it's part of what drove me from hg to git early on. A git
"branch" is an hg "bookmark" these days (a named "head"), and if that
name triggers the right associations for some people, its best used in
explanations for those. git's branches do exactly what I (and many
others) expect branches to do and what I need daily, even coming from a
svn and hg background.
Michael
^ permalink raw reply
* [PATCH v2 0/5] Decorate grafts and replaces
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313593326-12077-1-git-send-email-pclouds@gmail.com>
I originally wanted to decorate shallow cut points. Now it decorates
all grafts (normal as well as shallow cuts) and replaced commits/tags.
The first patch is an independent fix. The last one, decorating
replaces, can also be considered a fix (decorating "refs/replace/SHA1"
on random commits does not sound right, but maybe it's just me).
Nguyễn Thái Ngọc Duy (5):
decoration: do not mis-decorate refs with same prefix
Add for_each_commit_graft() to iterate all grafts
Move write_shallow_commits to fetch-pack.c
log: decorate grafted commits with "grafted"
log: decorate "replaced" on to replaced commits
builtin/fetch-pack.c | 30 ++++++++++++++++++++++++++++++
commit.c | 20 +++++---------------
commit.h | 3 ++-
log-tree.c | 34 ++++++++++++++++++++++++++++++----
4 files changed, 67 insertions(+), 20 deletions(-)
--
1.7.4.74.g639db
^ permalink raw reply
* [PATCH 1/5] decoration: do not mis-decorate refs with same prefix
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313670578-2939-1-git-send-email-pclouds@gmail.com>
We definitely do not want to decorate refs/headsandtails the same as
refs/heads/*, for example.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
log-tree.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index e945701..344f734 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -95,11 +95,11 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
if (!obj)
return 0;
- if (!prefixcmp(refname, "refs/heads"))
+ if (!prefixcmp(refname, "refs/heads/"))
type = DECORATION_REF_LOCAL;
- else if (!prefixcmp(refname, "refs/remotes"))
+ else if (!prefixcmp(refname, "refs/remotes/"))
type = DECORATION_REF_REMOTE;
- else if (!prefixcmp(refname, "refs/tags"))
+ else if (!prefixcmp(refname, "refs/tags/"))
type = DECORATION_REF_TAG;
else if (!prefixcmp(refname, "refs/stash"))
type = DECORATION_REF_STASH;
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH 2/5] Add for_each_commit_graft() to iterate all grafts
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313670578-2939-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
commit.c | 8 ++++++++
commit.h | 2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/commit.c b/commit.c
index dc22695..efd647d 100644
--- a/commit.c
+++ b/commit.c
@@ -226,6 +226,14 @@ struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
return commit_graft[pos];
}
+int for_each_commit_graft(each_commit_graft_fn fn, void *cb_data)
+{
+ int i, ret;
+ for (i = ret = 0; i < commit_graft_nr && !ret; i++)
+ ret = fn(commit_graft[i], cb_data);
+ return ret;
+}
+
int write_shallow_commits(struct strbuf *out, int use_pack_protocol)
{
int i, count = 0;
diff --git a/commit.h b/commit.h
index 0e36fd0..9030d42 100644
--- a/commit.h
+++ b/commit.h
@@ -143,6 +143,7 @@ struct commit_graft {
int nr_parent; /* < 0 if shallow commit */
unsigned char parent[FLEX_ARRAY][20]; /* more */
};
+typedef int (*each_commit_graft_fn)(const struct commit_graft *, void *);
struct commit_graft *read_graft_line(char *buf, int len);
int register_commit_graft(struct commit_graft *, int);
@@ -155,6 +156,7 @@ extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
extern int unregister_shallow(const unsigned char *sha1);
extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol);
+extern int for_each_commit_graft(each_commit_graft_fn, void *);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH 3/5] Move write_shallow_commits to fetch-pack.c
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313670578-2939-1-git-send-email-pclouds@gmail.com>
This function produces network traffic and should be in fetch-pack. It
has been in commit.c because it needs to iterate (private) graft
list. It can now do so using for_each_commit_graft().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/fetch-pack.c | 30 ++++++++++++++++++++++++++++++
commit.c | 18 ------------------
commit.h | 1 -
3 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 4367984..cb5b20a 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -185,6 +185,36 @@ static void consume_shallow_list(int fd)
}
}
+struct write_shallow_data {
+ struct strbuf *out;
+ int use_pack_protocol;
+ int count;
+};
+
+static int write_one_shallow(const struct commit_graft *graft, void *cb_data)
+{
+ struct write_shallow_data *data = cb_data;
+ const char *hex = sha1_to_hex(graft->sha1);
+ data->count++;
+ if (data->use_pack_protocol)
+ packet_buf_write(data->out, "shallow %s", hex);
+ else {
+ strbuf_addstr(data->out, hex);
+ strbuf_addch(data->out, '\n');
+ }
+ return 0;
+}
+
+static int write_shallow_commits(struct strbuf *out, int use_pack_protocol)
+{
+ struct write_shallow_data data;
+ data.out = out;
+ data.use_pack_protocol = use_pack_protocol;
+ data.count = 0;
+ for_each_commit_graft(write_one_shallow, &data);
+ return data.count;
+}
+
static enum ack_type get_ack(int fd, unsigned char *result_sha1)
{
static char line[1000];
diff --git a/commit.c b/commit.c
index efd647d..661ff0d 100644
--- a/commit.c
+++ b/commit.c
@@ -234,24 +234,6 @@ int for_each_commit_graft(each_commit_graft_fn fn, void *cb_data)
return ret;
}
-int write_shallow_commits(struct strbuf *out, int use_pack_protocol)
-{
- int i, count = 0;
- for (i = 0; i < commit_graft_nr; i++)
- if (commit_graft[i]->nr_parent < 0) {
- const char *hex =
- sha1_to_hex(commit_graft[i]->sha1);
- count++;
- if (use_pack_protocol)
- packet_buf_write(out, "shallow %s", hex);
- else {
- strbuf_addstr(out, hex);
- strbuf_addch(out, '\n');
- }
- }
- return count;
-}
-
int unregister_shallow(const unsigned char *sha1)
{
int pos = commit_graft_pos(sha1);
diff --git a/commit.h b/commit.h
index 9030d42..82d5aeb 100644
--- a/commit.h
+++ b/commit.h
@@ -155,7 +155,6 @@ extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
extern int unregister_shallow(const unsigned char *sha1);
-extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol);
extern int for_each_commit_graft(each_commit_graft_fn, void *);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH 4/5] log: decorate grafted commits with "grafted"
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313670578-2939-1-git-send-email-pclouds@gmail.com>
In shallow repositories, this may help detect whether a branch ends,
or it is deeper than current depth.
It also show graft points that extend a branch.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
log-tree.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 344f734..5605244 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -18,6 +18,7 @@ enum decoration_type {
DECORATION_REF_TAG,
DECORATION_REF_STASH,
DECORATION_REF_HEAD,
+ DECORATION_GRAFTED,
};
static char decoration_colors[][COLOR_MAXLEN] = {
@@ -27,6 +28,7 @@ static char decoration_colors[][COLOR_MAXLEN] = {
GIT_COLOR_BOLD_YELLOW, /* REF_TAG */
GIT_COLOR_BOLD_MAGENTA, /* REF_STASH */
GIT_COLOR_BOLD_CYAN, /* REF_HEAD */
+ GIT_COLOR_BOLD_BLUE, /* GRAFTED */
};
static const char *decorate_get_color(int decorate_use_color, enum decoration_type ix)
@@ -118,6 +120,15 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
return 0;
}
+static int add_graft_decoration(const struct commit_graft *graft, void *cb_data)
+{
+ struct commit *commit = lookup_commit(graft->sha1);
+ if (!commit)
+ return 0;
+ add_name_decoration(DECORATION_GRAFTED, "grafted", &commit->object);
+ return 0;
+}
+
void load_ref_decorations(int flags)
{
static int loaded;
@@ -125,6 +136,7 @@ void load_ref_decorations(int flags)
loaded = 1;
for_each_ref(add_ref_decoration, &flags);
head_ref(add_ref_decoration, &flags);
+ for_each_commit_graft(add_graft_decoration, NULL);
}
}
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH 5/5] log: decorate "replaced" on to replaced commits
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 12:29 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313670578-2939-1-git-send-email-pclouds@gmail.com>
Old code also decorates "new" commits with "refs/replace/SHA1". This
is now gone, but I guess no one will miss it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
log-tree.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 5605244..b982b9f 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -92,8 +92,22 @@ static void add_name_decoration(enum decoration_type type, const char *name, str
static int add_ref_decoration(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
- struct object *obj = parse_object(sha1);
+ struct object *obj;
enum decoration_type type = DECORATION_NONE;
+
+ if (!prefixcmp(refname, "refs/replace/")) {
+ unsigned char original_sha1[20];
+ if (get_sha1_hex(refname + 13, original_sha1)) {
+ warning("invalid replace ref %s", refname);
+ return 0;
+ }
+ obj = parse_object(original_sha1);
+ if (obj && (obj->type == OBJ_COMMIT || obj->type == OBJ_TAG))
+ add_name_decoration(DECORATION_GRAFTED, "replaced", obj);
+ return 0;
+ }
+
+ obj = parse_object(sha1);
if (!obj)
return 0;
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: git-svn bug: Could not unmemoize function `lookup_svn_merge' ...
From: sother @ 2011-08-18 13:23 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikW2jgPfO_tsdzuD6pZJAJMQPezMr7ZQvgWtkFY@mail.gmail.com>
I've got the same problem using Git for Windows version 1.7.4. I´ve
downgraded to version 1.6.1 and it worked.
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-bug-Could-not-unmemoize-function-lookup-svn-merge-tp5871159p6699369.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] fetch-pack: check for valid commit from server
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 13:36 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
A malicious server can return ACK with non-existent SHA-1 or not a
commit. lookup_commit() in this case may return NULL. Do not let
fetch-pack crash by accessing NULL address in this case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
However it raises another question, what if the other end returns a
valid commit, but not the one in "have" line fetch-pack sent? Are we
OK with that?
builtin/fetch-pack.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 4367984..3c871c2 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -395,6 +395,8 @@ static int find_common(int fd[2], unsigned char *result_sha1,
case ACK_continue: {
struct commit *commit =
lookup_commit(result_sha1);
+ if (!commit)
+ die("invalid commit %s", sha1_to_hex(result_sha1));
if (args.stateless_rpc
&& ack == ACK_common
&& !(commit->object.flags & COMMON)) {
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH v3] Accept tags in HEAD or MERGE_HEAD
From: Nguyễn Thái Ngọc Duy @ 2011-08-18 13:43 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313545369-7096-1-git-send-email-pclouds@gmail.com>
HEAD and MERGE_HEAD (among other branch tips) should never hold a
tag. That can only be caused by broken tools and is cumbersome to fix
by an end user with:
$ git update-ref HEAD $(git rev-parse HEAD^{commit})
which may look like a magic to a new person.
Be easy, warn users (so broken tools can be fixed) and move on.
Be robust, if the given SHA-1 cannot be resolved to a commit object,
die (therefore return value is always valid).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/commit.c | 25 ++++++++++++-------------
builtin/fmt-merge-msg.c | 2 +-
builtin/merge.c | 19 +++++++++++--------
commit.c | 12 ++++++++++++
commit.h | 1 +
http-push.c | 8 ++++----
revision.c | 6 ++++--
7 files changed, 45 insertions(+), 28 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index cb73857..f78b449 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -63,6 +63,7 @@ N_("The previous cherry-pick is now empty, possibly due to conflict resolution.\
"Otherwise, please use 'git reset'\n");
static unsigned char head_sha1[20];
+static struct commit *head_commit;
static const char *use_message_buffer;
static const char commit_editmsg[] = "COMMIT_EDITMSG";
@@ -518,11 +519,8 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
return s->commitable;
}
-static int is_a_merge(const unsigned char *sha1)
+static int is_a_merge(struct commit *commit)
{
- struct commit *commit = lookup_commit(sha1);
- if (!commit || parse_commit(commit))
- die(_("could not parse HEAD commit"));
return !!(commit->parents && commit->parents->next);
}
@@ -848,7 +846,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
* empty due to conflict resolution, which the user should okay.
*/
if (!commitable && whence != FROM_MERGE && !allow_empty &&
- !(amend && is_a_merge(head_sha1))) {
+ !(amend && is_a_merge(head_commit))) {
run_status(stdout, index_file, prefix, 0, s);
if (amend)
fputs(_(empty_amend_advice), stderr);
@@ -1028,6 +1026,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (get_sha1("HEAD", head_sha1))
initial_commit = 1;
+ else
+ head_commit = lookup_expect_commit(head_sha1, "HEAD");
+
/* Sanity check options */
if (amend && initial_commit)
@@ -1421,23 +1422,20 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = "commit (initial)";
} else if (amend) {
struct commit_list *c;
- struct commit *commit;
if (!reflog_msg)
reflog_msg = "commit (amend)";
- commit = lookup_commit(head_sha1);
- if (!commit || parse_commit(commit))
- die(_("could not parse HEAD commit"));
- for (c = commit->parents; c; c = c->next)
+ for (c = head_commit->parents; c; c = c->next)
pptr = &commit_list_insert(c->item, pptr)->next;
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
+ struct commit *commit;
FILE *fp;
if (!reflog_msg)
reflog_msg = "commit (merge)";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ pptr = &commit_list_insert(head_commit, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1446,7 +1444,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
if (get_sha1_hex(m.buf, sha1) < 0)
die(_("Corrupt MERGE_HEAD file (%s)"), m.buf);
- pptr = &commit_list_insert(lookup_commit(sha1), pptr)->next;
+ commit = lookup_expect_commit(sha1, "MERGE_HEAD");
+ pptr = &commit_list_insert(commit, pptr)->next;
}
fclose(fp);
strbuf_release(&m);
@@ -1463,7 +1462,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = (whence == FROM_CHERRY_PICK)
? "commit (cherry-pick)"
: "commit";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ pptr = &commit_list_insert(head_commit, pptr)->next;
}
/* Finally, get the commit message */
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 7581632..1a31b64 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -293,7 +293,7 @@ static int do_fmt_merge_msg(int merge_title, struct strbuf *in,
struct commit *head;
struct rev_info rev;
- head = lookup_commit(head_sha1);
+ head = lookup_expect_commit(head_sha1, "HEAD");
init_revisions(&rev, NULL);
rev.commit_format = CMIT_FMT_ONELINE;
rev.ignore_merges = 1;
diff --git a/builtin/merge.c b/builtin/merge.c
index 325891e..22e98e8 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -51,6 +51,7 @@ static int allow_trivial = 1, have_message;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
static unsigned char head[20], stash[20];
+static struct commit* head_commit;
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char **xopts;
@@ -326,7 +327,7 @@ static void squash_message(void)
rev.ignore_merges = 1;
rev.commit_format = CMIT_FMT_MEDIUM;
- commit = lookup_commit(head);
+ commit = head_commit;
commit->object.flags |= UNINTERESTING;
add_pending_object(&rev, &commit->object, NULL);
@@ -709,7 +710,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
commit_list_insert(j->item, &reversed);
index_fd = hold_locked_index(lock, 1);
- clean = merge_recursive(&o, lookup_commit(head),
+ clean = merge_recursive(&o, head_commit,
remoteheads->item, reversed, &result);
if (active_cache_changed &&
(write_cache(index_fd, active_cache, active_nr) ||
@@ -867,7 +868,7 @@ static int merge_trivial(void)
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
- parent->item = lookup_commit(head);
+ parent->item = head_commit;
parent->next = xmalloc(sizeof(*parent->next));
parent->next->item = remoteheads->item;
parent->next->next = NULL;
@@ -889,12 +890,12 @@ static int finish_automerge(struct commit_list *common,
free_commit_list(common);
if (allow_fast_forward) {
parents = remoteheads;
- commit_list_insert(lookup_commit(head), &parents);
+ commit_list_insert(head_commit, &parents);
parents = reduce_heads(parents);
} else {
struct commit_list **pptr = &parents;
- pptr = &commit_list_insert(lookup_commit(head),
+ pptr = &commit_list_insert(head_commit,
pptr)->next;
for (j = remoteheads; j; j = j->next)
pptr = &commit_list_insert(j->item, pptr)->next;
@@ -1030,6 +1031,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
branch += 11;
if (is_null_sha1(head))
head_invalid = 1;
+ else
+ head_commit = lookup_expect_commit(head, "HEAD");
git_config(git_merge_config, NULL);
@@ -1203,11 +1206,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
if (!remoteheads->next)
- common = get_merge_bases(lookup_commit(head),
+ common = get_merge_bases(head_commit,
remoteheads->item, 1);
else {
struct commit_list *list = remoteheads;
- commit_list_insert(lookup_commit(head), &list);
+ commit_list_insert(head_commit, &list);
common = get_octopus_merge_bases(list);
free(list);
}
@@ -1292,7 +1295,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* merge_bases again, otherwise "git merge HEAD^
* HEAD^^" would be missed.
*/
- common_one = get_merge_bases(lookup_commit(head),
+ common_one = get_merge_bases(head_commit,
j->item, 1);
if (hashcmp(common_one->item->object.sha1,
j->item->object.sha1)) {
diff --git a/commit.c b/commit.c
index ac337c7..dc22695 100644
--- a/commit.c
+++ b/commit.c
@@ -39,6 +39,18 @@ struct commit *lookup_commit_reference(const unsigned char *sha1)
return lookup_commit_reference_gently(sha1, 0);
}
+struct commit *lookup_expect_commit(const unsigned char *sha1,
+ const char *ref_name)
+{
+ struct commit *c = lookup_commit_reference(sha1);
+ if (!c)
+ die(_("could not parse %s"), ref_name);
+ if (hashcmp(sha1, c->object.sha1))
+ warning(_("%s %s is not a commit!"),
+ ref_name, sha1_to_hex(sha1));
+ return c;
+}
+
struct commit *lookup_commit(const unsigned char *sha1)
{
struct object *obj = lookup_object(sha1);
diff --git a/commit.h b/commit.h
index a2d571b..f36c913 100644
--- a/commit.h
+++ b/commit.h
@@ -37,6 +37,7 @@ struct commit *lookup_commit_reference(const unsigned char *sha1);
struct commit *lookup_commit_reference_gently(const unsigned char *sha1,
int quiet);
struct commit *lookup_commit_reference_by_name(const char *name);
+struct commit *lookup_expect_commit(const unsigned char *sha1, const char *ref_name);
int parse_commit_buffer(struct commit *item, const void *buffer, unsigned long size);
int parse_commit(struct commit *item);
diff --git a/http-push.c b/http-push.c
index 6e8f6d0..31297af 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1606,10 +1606,10 @@ static void fetch_symref(const char *path, char **symref, unsigned char *sha1)
strbuf_release(&buffer);
}
-static int verify_merge_base(unsigned char *head_sha1, unsigned char *branch_sha1)
+static int verify_merge_base(unsigned char *head_sha1, struct ref *remote)
{
- struct commit *head = lookup_commit(head_sha1);
- struct commit *branch = lookup_commit(branch_sha1);
+ struct commit *head = lookup_expect_commit(head_sha1, "HEAD");
+ struct commit *branch = lookup_expect_commit(remote->old_sha1, remote->name);
struct commit_list *merge_bases = get_merge_bases(head, branch, 1);
return (merge_bases && !merge_bases->next && merge_bases->item == branch);
@@ -1680,7 +1680,7 @@ static int delete_remote_branch(const char *pattern, int force)
return error("Remote branch %s resolves to object %s\nwhich does not exist locally, perhaps you need to fetch?", remote_ref->name, sha1_to_hex(remote_ref->old_sha1));
/* Remote branch must be an ancestor of remote HEAD */
- if (!verify_merge_base(head_sha1, remote_ref->old_sha1)) {
+ if (!verify_merge_base(head_sha1, remote_ref)) {
return error("The branch '%s' is not an ancestor "
"of your current HEAD.\n"
"If you are sure you want to delete it,"
diff --git a/revision.c b/revision.c
index c46cfaa..f926412 100644
--- a/revision.c
+++ b/revision.c
@@ -986,10 +986,12 @@ static void prepare_show_merge(struct rev_info *revs)
const char **prune = NULL;
int i, prune_num = 1; /* counting terminating NULL */
- if (get_sha1("HEAD", sha1) || !(head = lookup_commit(sha1)))
+ if (get_sha1("HEAD", sha1))
die("--merge without HEAD?");
- if (get_sha1("MERGE_HEAD", sha1) || !(other = lookup_commit(sha1)))
+ head = lookup_expect_commit(sha1, "HEAD");
+ if (get_sha1("MERGE_HEAD", sha1))
die("--merge without MERGE_HEAD?");
+ other = lookup_expect_commit(sha1, "MERGE_HEAD");
add_pending_object(revs, &head->object, "HEAD");
add_pending_object(revs, &other->object, "MERGE_HEAD");
bases = get_merge_bases(head, other, 1);
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: [PATCH v2] git svn : hook before 'git svn dcommit'
From: Frédéric Heitzmann @ 2011-08-18 13:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Junio C Hamano
In-Reply-To: <20110817203701.GB24581@dcvr.yhbt.net>
2011/8/17 Eric Wong <normalperson@yhbt.net>:
>> 2011/8/17 Eric Wong <normalperson@yhbt.net> wrote:
>> > Perhaps an interactive option for dcommit would be just as useful?
>
> 1 and 3 can both implemented, but I think 3 would be easier to
> use/setup/standardize. I suspect it's also easier to train oneself to
> always use "dcommit -i". Perhaps even default to interactive mode
> like git-send-email does nowadays.
>
> Unfortunately interactive dcommit requires more effort to implement.
>
> --
> Eric Wong
It seems that proposal 3 is somehow equivalent to
$ git rebase -i --onto remotes/trunk remotes/trunk
... check commits, maybe remove some of them, ...
$ git svn dcommit
note : is the SVN remote branch always named "remote/trunk" ? If not,
is there a way to guess its name ?
--
Fred
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Stephen Bash @ 2011-08-18 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Conrad Irwin
In-Reply-To: <7vhb5fev8a.fsf@alter.siamese.dyndns.org>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> To: "Conrad Irwin" <conrad.irwin@gmail.com>
> Sent: Wednesday, August 17, 2011 2:41:41 PM
> Subject: Re: [PATCH] Disallow creating ambiguous branch names by default
>
> We should be giving these warning messages immediately after creating
> potentially problematic refs, i.e. just after "git branch v1.0.0" and
> "git checkout -b v1.0.0". The user experience should look like this
> instead:
>
> $ git branch v1.0.0
> warning: refname 'v1.0.0' is ambiguous.
> advice: you may want to rename it to an unambigous name with
> advice: git branch -m v1.0.0 v1.0.0-branch
> $ git branch -m v1.0.0 v1.0.0-branch ;# thanks for an advice
>
> $ git checkout -b v1.0.0
> warning: refname 'v1.0.0' is ambiguous.
> advice: you may want to rename it to an unambigous name with
> advice: git branch -m v1.0.0-branch-2
> $ git branch -m v1.0.0-branch-2 ;# thanks for an advice
Should case insensitive matches be added to the tests? This morning I discovered coworkers working on branches foo and Foo thinking they were on the same branch... Rather trivial to clean up, but certainly caused some confusion in the office.
Thanks,
Stephen
^ permalink raw reply
* git-svn repo in weird state
From: Dave Zarzycki @ 2011-08-18 14:14 UTC (permalink / raw)
To: git
I have a local git-svn repository that is now in a weird state and would any tips for how to debug this. Thanks!
davez
$ git --version
git version 1.7.6
$ git checkout master
warning: refname 'master' is ambiguous.
Already on 'master'
$ git show-ref | grep master
d510ee7a969c908a20ab8abab08dd3ad09870508 refs/heads/master
$ git svn rebase
warning: refname 'master' is ambiguous.
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/svn/trunk.
error: Ref refs/heads/master is at d510ee7a969c908a20ab8abab08dd3ad09870508 but expected 014cd21f9f6e88e4515ed99c632308a954085a34
fatal: Cannot lock the ref 'refs/heads/master'.
Could not move back to refs/heads/master
rebase refs/remotes/svn/trunk: command returned error: 1
$
^ permalink raw reply
* Re: git-svn repo in weird state
From: Dave Zarzycki @ 2011-08-18 14:22 UTC (permalink / raw)
To: git
In-Reply-To: <85C67F68-AEF7-4E98-9388-C16BD04A68F8@apple.com>
After introspecting the .git directory, it seems like a stale .git/master was created somehow. Why does git-show-ref not show .git/master as a ref?
On Aug 18, 2011, at 10:14 AM, Dave Zarzycki wrote:
> I have a local git-svn repository that is now in a weird state and would any tips for how to debug this. Thanks!
>
> davez
>
>
>
> $ git --version
> git version 1.7.6
> $ git checkout master
> warning: refname 'master' is ambiguous.
> Already on 'master'
> $ git show-ref | grep master
> d510ee7a969c908a20ab8abab08dd3ad09870508 refs/heads/master
> $ git svn rebase
> warning: refname 'master' is ambiguous.
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to refs/remotes/svn/trunk.
> error: Ref refs/heads/master is at d510ee7a969c908a20ab8abab08dd3ad09870508 but expected 014cd21f9f6e88e4515ed99c632308a954085a34
> fatal: Cannot lock the ref 'refs/heads/master'.
> Could not move back to refs/heads/master
> rebase refs/remotes/svn/trunk: command returned error: 1
>
> $
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RFC: repository of handy git aliases?
From: Jon Seymour @ 2011-08-18 14:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narębski, Git Mailing List
In-Reply-To: <4E4A76E7.2090100@drmicha.warpmail.net>
On Tue, Aug 16, 2011 at 11:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
>> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
>>
>> I've also added this...
>>
>> Listing the tips of branches in pu that are not in master
>> ===========================================
>>
>> Suppose you have two aliases defined like so:
>>
>> [alias]
>> oneline = !/usr/bin/xargs -L1 git log --decorate --max-count=1 --oneline
>
> How about
>
> oneline = git log --no-walk --decorate --oneline
I still need to !/usr/bin/xargs -L1m, don't I? The point is to
transform a list of SHA1s into a decorated list. But point taken about
--no-walk being an alternative to --max-count=1.
> git branch --merged origin/pu --contains origin/next
>
> (or with --no-merged, but put it first.)
>
So, the idea with tips is that it will show you the tips of
independent lines of development that have diverged from origin/next
(or before) that have been merged back into origin/pu. This works,
even if you don't have branches assigned to these tips.
In this example:
A-----B---E---F---G---H
\-----C--/ /
\ ----D----/
git tips F will show B, C, D as the tips of branches that have
diverged from the mainline but have merged back in.
If I want to rebuild F' which does not include C, then git tips F
tells me that I have to merge B and D.
The git tips alias abstracts the function of 'git work list
dependency' which is a function of git extension (git work) that I
have been playing around with for a while.
I use git work to manage a private integration branch which includes
all my current published but unintegrated-upstream topics. If I decide
I want to unmerge one of these topics from my integration branch, I'd
do something like:
git work unmerge C
Which does the equivalent of:
git checkout B
git merge D
git rebase --onto HEAD F H
>>
>> which is a list of the tips of branches that are in pu, but not in next.
>
> That's not quite the standard --decorate, is it? ;)
>
Not sure what you mean by not being standard? The main idea about
using --decorate here is to get a dump of any refs that might describe
the identified tips.
jon.
^ permalink raw reply
* Re: [PATCH 1/4] git-p4: Allow setting rename/copy detection threshold.
From: Pete Wyckoff @ 2011-08-18 15:18 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Tor Arvid Lund
In-Reply-To: <1313629459-22937-2-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Thu, 18 Aug 2011 02:04 +0100:
> Copy and rename detection arguments (-C and -M) allow setting a threshold value
> for the similarity ratio. If the similarity is below this threshold the rename
> or copy is ignored and the file is added as new.
> This patch allows setting git-p4.detectRenames and git-p4.detectCopies options
> to an integer value to set the respective threshold.
[..]
> - if self.detectRenames:
> + diffOpts = ""
> + if self.detectRenames.lower() == "true":
> diffOpts = "-M"
> - else:
> - diffOpts = ""
> + elif self.detectRenames != "":
> + self.detectRenames = int(self.detectRenames)
> + if self.detectRenames >= 0 and self.detectRenames <= 100:
> + diffOpts = "-M%d" % self.detectRenames
>
This is a good idea. But I notice that -M, -C, -B can take
a diverse set of option forms, including floating point and
optional "%". "-B" can take two args, separated by a "/".
See diff_scoreopt_parse(). It would be weird for git-p4 to limit
that set to integers like you do here.
Would you be willing to change it to pass the string blindly?
Just filter out the special values, and pass everything else
unchanged.
"true" -> "-M"
"false" -> ""
"" -> ""
".*" -> "\1"
Dunno if you care about --break-rewrites. Just pointing to it
as a similar option to -M and -C in case you missed it.
-- Pete
^ permalink raw reply
* Re: RFC: repository of handy git aliases?
From: Michael J Gruber @ 2011-08-18 15:40 UTC (permalink / raw)
To: Jon Seymour; +Cc: Jakub Narębski, Git Mailing List
In-Reply-To: <CAH3AnrpahkHtnu5QTRns-vVcCoj3Q8JM-mzytYF2ZC_EXjU7Xw@mail.gmail.com>
Jon Seymour venit, vidit, dixit 18.08.2011 16:52:
> On Tue, Aug 16, 2011 at 11:55 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
>>> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>>>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
>>>
>>> I've also added this...
>>>
>>> Listing the tips of branches in pu that are not in master
>>> ===========================================
>>>
>>> Suppose you have two aliases defined like so:
>>>
>>> [alias]
>>> oneline = !/usr/bin/xargs -L1 git log --decorate --max-count=1 --oneline
>>
>> How about
>>
>> oneline = git log --no-walk --decorate --oneline
>
> I still need to !/usr/bin/xargs -L1m, don't I? The point is to
> transform a list of SHA1s into a decorated list. But point taken about
> --no-walk being an alternative to --max-count=1.
Is this a typo or do you have an xargs which understands "1m"? My point
was that you can feed all tips to "log" at once, as long as you don't
exceed the argument list limits, of course.
>> git branch --merged origin/pu --contains origin/next
>>
>> (or with --no-merged, but put it first.)
>>
>
> So, the idea with tips is that it will show you the tips of
> independent lines of development that have diverged from origin/next
> (or before) that have been merged back into origin/pu. This works,
> even if you don't have branches assigned to these tips.
OK, that is different then.
[snipped discription]
>
>
[readding relevant part:]
>>> b166408 mergetool: Don't assume paths are unmerged
>>> b29d76f merge: mark the final "Merge made by..." message for l10n
>>>942cf39 receive-pack: Allow server to refuse pushes with too many objects
>>>
>>> which is a list of the tips of branches that are in pu, but not in next.
>>
>> That's not quite the standard --decorate, is it? ;)
>>
>
> Not sure what you mean by not being standard? The main idea about
> using --decorate here is to get a dump of any refs that might describe
> the identified tips.
Just compare your output with this:
git log --decorate --no-walk --oneline origin/{master,next,pu}
a46e511 (origin/pu) Merge branch 'fg/submodule-git-file-git-dir' into pu
0e3f8f0 (origin/next) Merge branch 'master' into next
4bfe7cb (origin/master, origin/HEAD) Sync with "maint"
That is, I get the branch decorations there; you use the same format but
don't get any. But I may be misunderstanding completely what you are
trying to achieve. I guess I have to reread your extended use case
description...
Cheers,
Michael
^ permalink raw reply
* Re: Good Morning Restaurant Owners
From: Randal L. Schwartz @ 2011-08-18 16:54 UTC (permalink / raw)
To: admin; +Cc: git
In-Reply-To: <4d1888b6706a87585cfb242d367cd5d5@southlakeweb.biz>
>>>>> "admin" == admin <admin@southlakeweb.biz> writes:
admin> ALPINE RESTAURANT EQUIPMENT IS HERE TO HELP
AND PROVIDE YOU WITH WORKING CAPITAL. LETTERS, THAT IS.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Ramkumar Ramachandra @ 2011-08-18 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
In-Reply-To: <7vwredi9uu.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
>>> [...]
>>> Will merge to "next".
>>
>> If this won't graduate to 'next' before the 24th, I have plenty of
>> time to re-roll fixing all the issues that I've addressed in the
>> beginning of the new series.
>
> I take it that you mean by "the new series" the 6-patch "Towards a
> generalized sequencer" topic?
Yes.
> It is ultimately up-to-you. If you feel the fix-up is against glaring
> errors in the earlier round that you would prefer not to see in the
> history cast-in-stone, I am perfectly Ok to wait for a re-roll. On the
> other hand, if they are mostly cosmetic fixes without major semantic
> changes, it may be easier for everybody to see them fixed in-tree.
Hm, I didn't think they were glaring errors. After reading your
latest review about my '--continue' patch in the generalized
sequencer, I've decided not to re-roll. Please merge
'rr/revert-cherry-pick-continue' into 'next' as usual. It'll take me
some more time to think about my "generalized sequencer" series.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 1/4] difftool--helper: Make style consistent with git
From: Junio C Hamano @ 2011-08-18 17:31 UTC (permalink / raw)
To: David Aguilar
Cc: Sebastian Schuberth, git, Jonathan Nieder, Tanguy Ortolo,
Charles Bailey
In-Reply-To: <20110818090810.GA15416@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> I am fine reworking it either way.
> There's not a specific note about it in
> Documentation/CodingStyle.
>
> If someone wants to make the final call I can patch the docs
> and rework these patches as needed.
Please stick to (and document if not):
if test ...
then
action
elif condition that can become looong so more &&
condition needs to be split to next line &&
even more condition
then
action
else
action
fi
Thanks.
You can think of it as "war against semicolon" if you want.
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-18 17:49 UTC (permalink / raw)
To: Michael J Gruber
Cc: Hilco Wijbenga, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <4E4CEFDA.9000703@drmicha.warpmail.net>
On Thu, Aug 18, 2011 at 10:56, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael Witten venit, vidit, dixit 18.08.2011 07:52:
>> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> It would be really nice, though, if Git could somehow
>>> "stash" such files when checking out a different branch. In general, I
>>> would prefer if uncommitted changes and untracked and/or ignored files
>>> stuck to the branch where they were created.
>>
>> As an aside, the problem here is likely a manifestation of the fact
>> that nobody understands what a branch is; the word 'branch' is
>
> I would reject "nobody"...
Is it really necessary to attack something that is obviously
hyperbolic rhetoric? The point is that a lot of people struggle with
git's concepts, and I think that the reason is largely two fold:
* Terminology that is inaccurate by virtue of terminological baggage.
* Terminology that is imprecisely used across the documentation.
>> TERRIBLE, as everyone has a different idea for what that should mean.
>
> ... and insist that this statement is true either trivially true for all
> words, or for none, depending on your understanding of "everyone has a
> different".
So, precision is impossible?
The word 'branch' is clearly a sticking point, and you know it. You
can't deny that people have a hard time with what a branch really is
in git.
>> In my opinion, `git branch' should become `git ref' or the like.
>
> "branch" and "tag" are boths refs. Their only essential difference is
> that one "moves" and the other doesn't.
Indeed, and it seems like there's room for abstraction; a tool like
`git ref' or `git pointer' or `git ptr' could probably handle both
quite well.
Terminology for references is a problem that was solved by the
Ancients, so it's a wonder we didn't use their work (pointers,
constant pointers, dereferencing, etc.).
>> One of git's worst faults is that a complicated and imprecise
>> interface has been draped over a very simple and precise underlying
>> structure.
>
> A name is a name and just that. The use of any existing word may clash
> with someone's expectations.
Yeah? So why wasn't the term 'foobar' used instead of 'branch'? Most
terms are chosen for their associations (and only really novel
concepts receive an entirely new label), and I proffer that 'branch'
has too many associations to be considered accurate enough.
The idea was that one line of development can 'branch' off from
another, so it was called a 'branch'. But what is a line of
development? (merges certainly make the concept fuzzy; tree branches
usually don't join with the tree trunk again). The thing is, though,
when you're working with what git calls a 'branch', you're really just
working with a pointer to a commit object; the term 'pointer' would
have been much more accurate.
Now, I'm not saying we should be using 'pointer', but what I am saying
is that it's necessary to choose words carefully, preferably in a way
that carries just enough associations to aid the user in remembering
what a term describes.
> I find the concepts "file created on a branch", "commit created on a
> branch" silly, it's part of what drove me from hg to git early on.
There's no shortage of that kind of thinking in the git community,
which is my point. The reason is a failure of both accurate
terminology and precise usage.
> git's branches do exactly what I (and many others) expect branches
> to do and what I need daily, even coming from a svn and hg background.
Yes, well, many figure it out EVENTUALLY; it just requires them to
ignore most of the associations of 'branch', thereby tacitly
translating the word 'branch' into 'pointer'.
^ permalink raw reply
* Re: [PATCH resend] Makefile: Use computed header dependencies if the compiler supports it
From: Fredrik Kuivinen @ 2011-08-18 18:34 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20110814200255.GC16819@elie.gateway.2wire.net>
On Sun, Aug 14, 2011 at 03:02:55PM -0500, Jonathan Nieder wrote:
> Fredrik Kuivinen wrote:
> > On Sun, Aug 14, 2011 at 21:00, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> >> I wonder if we can make do with a faster check, like
> >>
> >> $(CC) -c -MF /dev/null -MMD -MP git.c --help >/dev/null 2>&1
> >>
> >> What do you think?
> [...]
> > Without patch (with COMPUTE_HEADER_DEPENDENCIES=Yes):
>
> The case to compare against is when COMPUTE_HEADER_DEPENDENCIES is not
> set, I'd think, since that is the status quo. And I was talking about
> commands like "make clean" that do not care about that feature, not
> "make all".
There is no measurable difference between setting and unsetting
COMPUTE_HEADER_DEPENDENCIES for me (not surprising as nothing is
actually built). "make clean" (in a clean tree) takes more time than
"make" (in a fully built tree), so the relative overhead in the make
clean case is even smaller. The absolute overhead is, of course, the
same.
> [...]
> > With patch, but changed to use git.c instead of ++empty.c:
>
> Did you try with "--help"?
Oh, I missed "--help". But for me gcc always exits with status code 0
when I give it "--help", regardless of what other flags I
provide. Therefore, I don't see how "--help" can be used to test for
support of -MMD.
Here is an updated patch. It avoids the ++empty.c file by giving "-x
c" to the compiler. It also avoids the auto-detection when
COMPUTE_HEADER_DEPENDENCIES is set, so if you want to avoid the
overhead you can set that in you config.mak.
-- 8< --
Subject: [PATCH] Makefile: Use computed header dependencies if the compiler supports it
Previously you had to manually define COMPUTE_HEADER_DEPENDENCIES to
enable this feature. It seemed a bit sad that such a useful feature
had to be enabled manually.
To avoid the small overhead we don't do the auto-detection if
COMPUTE_HEADER_DEPENDENCIES is already set.
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
---
Makefile | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 89cc624..c131439 100644
--- a/Makefile
+++ b/Makefile
@@ -250,10 +250,6 @@ all::
# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
#
-# Define COMPUTE_HEADER_DEPENDENCIES if your compiler supports the -MMD option
-# and you want to avoid rebuilding objects when an unrelated header file
-# changes.
-#
# Define CHECK_HEADER_DEPENDENCIES to check for problems in the hard-coded
# dependency rules.
#
@@ -1236,6 +1232,15 @@ endif
ifdef CHECK_HEADER_DEPENDENCIES
COMPUTE_HEADER_DEPENDENCIES =
USE_COMPUTED_HEADER_DEPENDENCIES =
+else
+ifndef COMPUTE_HEADER_DEPENDENCIES
+dep_check = $(shell sh -c \
+ '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ echo $$?')
+ifeq ($(dep_check),0)
+COMPUTE_HEADER_DEPENDENCIES=YesPlease
+endif
+endif
endif
ifdef COMPUTE_HEADER_DEPENDENCIES
--
1.7.5.3.368.g8b1b7.dirty
^ permalink raw reply related
* Re: [PATCH resend] Makefile: Use computed header dependencies if the compiler supports it
From: Jonathan Nieder @ 2011-08-18 18:41 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Junio C Hamano
In-Reply-To: <20110818183439.GA21560@fredrik-Q430-Q530>
Fredrik Kuivinen wrote:
> Oh, I missed "--help". But for me gcc always exits with status code 0
> when I give it "--help", regardless of what other flags I
> provide. Therefore, I don't see how "--help" can be used to test for
> support of -MMD.
Ah, my mistake. Good catch.
> Here is an updated patch. It avoids the ++empty.c file by giving "-x
> c" to the compiler.
Much nicer, thanks!
> It also avoids the auto-detection when
> COMPUTE_HEADER_DEPENDENCIES is set
Unfortunately "ifdef" in Makefiles means "if nonempty", so the
overhead of detection is still there if I want to explicitly disable
COMPUTE_HEADER_DEPENDENCIES. That's okay, since that overhead is
small. So for what it's worth,
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH 7/7] sequencer: Remove sequencer state after final commit
From: Ramkumar Ramachandra @ 2011-08-18 18:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Git List, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <7v7h6eld2c.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> [...]
Here are some comments from my end after extensive thought. Instead
of responding to your comments directly, I've sprinkled bits of it
here and there, reordering it as I see fit. Thanks for detailing out
your thoughts so well :)
0. Before getting into historical mistakes and evaluating existing
workflows, let's first try to detail the problem the sequencer is
trying to solve: pick/ revert aren't the only operations we want to
support. Let's imagine some hypothetical "foo" operation that does
something incredibly complex in the instruction sheet:
pick b38bcc
foo
pick 49ab7c
Now, let's imagine that the "foo" command failed. What is the
strategy we will employ to handle his? I think the question boils
down to: should we teach '--continue' the prerequisite for executing a
"pick" command (clean worktree etc), or how to finish a "foo" command?
What will this answer depend upon?
1. Now, let's discuss the motivation for d3f4628e. I didn't want to
create a separate workflow for pick-one-commit versus
pick-many-commits. It would have to go something like:
parse_arguments(whatever tree'ishes specified on argc)
setup_revision_walker
n = count_revisions
if (n == 1)
do foo; // Don't create sequencer state
else
create sequencer state; do foo; cleanup sequencer state;
Ugly. Wouldn't you agree? So, what choice did I have? I can't
conditionally create sequencer state. So, an idea struck me: if I
clean it up before someone notices, I'm safe. So, I decided to remove
it before the last commit -- when there's only one commit, it'll be
removed immediately. So far so good: no regressions introduced.
2. Okay, now let's try to touch upon the issue of marking something as "done":
> - The case to resume an unexpected stop (i.e. "pick" that causes conflict
> or "rebase" without "-i") also feels right. The user fixes up and marks
> things as "done" with "add/rm", and tell the stopped command that it can
> now continue with "rebase --continue". The same comment applies for
> "am".
I could argue that "add/rm" need not be the only way to specify "done"
in the general case. We needn't be consistent about that- we can
print hints about what "done" would mean, and not invent a new
"--mark-as-done" command. What varies here is the definition of
"done": does it mean that the user has "done" what the instruction
sheet operation was supposed to do (including the committing), or has
simply done a part of the job and passed on the baton?
3. How tight do we want the sequencer to be? Should we allow
executing other commands during the operation of the sequencer, or
should we simply expect the user to "--continue" the operation first
and take care of everything else later?
> - The sequencing flow the current "rebase -i" implements when resuming a
> controlled stop (i.e. "edit" or "reword"), even as the last step of the
> insn sheet, feels like the right thing. The actual tweaking of the
> commit done by "commit --amend" is oblivious to the sequencing state,
> and resuming is controlled by "rebase --continue".
I often "git commit -m temp" in the middle of a "rebase -i", and I'm
strongly in favor of allowing this somehow.
> There is a (complicated) workflow to split an commit during
> "rebase -i" that does _not_ want an auto-resume by a commit.
Exactly! :)
Auto-resuming after a "commit" is fundamentally wrong.
> Also not
> all conflicted/stopped state can be concluded with "commit" (think:
> "rebase/am --skip").
A good point on consistency.
4. Let's correct the historical mistakes and get our act together.
The final pending question is: how many historical mistakes are we
willing to stomp now?
> I personally am leaning towards teaching "--continue" to "merge" and
> "cherry-pick", while keeping only existing awareness of these two commands
> in "commit" as historical mistakes (look for 'unlink(git_path("[A-Z_]*"))'
> in builtin/commit.c). That would mean that in the long run, new users need
> to learn only one thing: when "git Foo" stops because it needs help from
> you resolving conflicts, after you help it by editing the files in your
> working tree and making that with add/rm, you say "git Foo --continue" to
> signal that you are done helping it.
Okay, stomp nothing. Under this constraint, the best we can do is:
1. Introduce a 'merge --continue' to invoke 'git commit'. MERGE_HEAD
helps 'git commit' finish. Modify tests to use '--continue' instead
of the earlier commit-to-finish workflow, and advertise this feature
everywhere.
2. Make 'cherry-pick --continue' invoke 'git commit' as well.
CHERRY_PICK_HEAD helps 'git commit' finish. If the commit finishes
successfully: (if there is one commit left, remove the sequencer
state; otherwise, drop the first insn on top of the list and execute
the next insn). Modify tests to use '--continue' instead of the
earlier commit-to-finish workflow, and advertise this feature
everywhere. Unfortunately, if the user executes 'git commit' instead
of the newer '--continue', we're screwed: a stray sequencer state will
be left behind.
Does the above seem sensible, or should we do something about the
historical mistakes?
Thanks.
-- Ram
^ 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