$(git notes merge FETCH_HEAD) doesn't work
Hello,
I started playing around with sharing git notes and so was happy to see
that git-notes learned about merging since I last tried.
My first try looked as follows (using git 1:1.9.0-1 from Debian):
$ git fetch $someremote refs/notes/commits
...
$ git notes merge FETCH_HEAD
$ echo $?
0
$ git log --oneline refs/notes/commits..FETCH_HEAD | wc -l
2
Looking at the source I see:
/* argv[0] holds FETCH_HEAD here */
strbuf_addstr(remote_ref, argv[0]);
expand_notes_ref(remote_ref);
After the call to expand_notes_ref remote_ref contains
refs/notes/FETCH_HEAD which isn't what I intended and I'm quite
surprised by. The problem seems to be:
/* Dereference o-remote_ref into remote_sha1 */
if (get_sha1(o-remote_ref, remote_sha1)) {
/*
* Failed to get remote_sha1. If o-remote_ref looks like an
* unborn ref, perform the merge using an empty notes tree.
*/
if (!check_refname_format(o-remote_ref, 0)) {
hashclr(remote_sha1);
remote = NULL;
} else {
die(Failed to resolve remote notes ref '%s',
o-remote_ref);
}
} ...
The workaround is obvious (i.e. git update-ref refs/notes/somestring
FETCH_HEAD; git notes merge somestring), but still I think this
behaviour is not optimal. I don't know why one might want to treat a
broken remote side as empty but at least a diagnostic message would be
nice. The same happens if I pass an explicit sha1 instead of
FETCH_HEAD.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
feature-request: git notes copy --to ref
Hello,
I'm playing around with git-notes and want to share some of my notes
with my co-workers. We have a central repository for our various topic
branches and want to track upstream inclusion in git-notes. So we have
to share our notes branch somehow.
The workflow I think makes sense here is (untested):
### hack hack, add notes bla blub
### - nice topic branch with some notes
git fetch serverrepo refs/notes/commits:refs/notes/servercommits
git notes merge refs/notes/servercommits
git rev-list origin/master.. | awk '{print $1 $1}' | git notes copy
--to refs/notes/servercommits --stdin
git push serverrepo refs/notes/servercommits:refs/notes/commits
Then maybe:
git notes merge refs/notes/servercommits
again.
The idea here is to only include notes in refs/notes/servercommits that
are relevant for my coworkers and not all intermediate notes that were
created during development or while working on other branches.
Does this make sense? Do you have better ideas or suggestions how to
improve the workflow?
The only problem now is that git notes copy doesn't take a --to
parameter. Maybe there is a volunteer to implement it? Then I'd
volunteer to test it :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature-request: git notes copy --to ref
Hello again,
On Thu, Feb 20, 2014 at 10:03:34PM +0100, Uwe Kleine-König wrote:
I'm playing around with git-notes and want to share some of my notes
with my co-workers. We have a central repository for our various topic
branches and want to track upstream inclusion in git-notes. So we have
to share our notes branch somehow.
The workflow I think makes sense here is (untested):
### hack hack, add notes bla blub
### - nice topic branch with some notes
git fetch serverrepo refs/notes/commits:refs/notes/servercommits
git notes merge refs/notes/servercommits
git rev-list origin/master.. | awk '{print $1 $1}' | git notes copy
--to refs/notes/servercommits --stdin
git push serverrepo refs/notes/servercommits:refs/notes/commits
Then maybe:
git notes merge refs/notes/servercommits
again.
The idea here is to only include notes in refs/notes/servercommits that
are relevant for my coworkers and not all intermediate notes that were
created during development or while working on other branches.
Does this make sense? Do you have better ideas or suggestions how to
improve the workflow?
The only problem now is that git notes copy doesn't take a --to
parameter. Maybe there is a volunteer to implement it? Then I'd
volunteer to test it :-)
I have implemented something now to copy notes to another branch. Here
is it for reference:
---8---
#! /bin/sh
set -e
. git-sh-setup
# for now the remote notes rev must be a ref below refs/notes
# see id:20140220153045.gi6...@pengutronix.de for the respective plea.
remote_notes=refs/notes/servercommits
local_notes=$(git notes get-ref)
remote_notes_ref=$(git rev-parse --verify $remote_notes^{commit})
tmpfile=$(mktemp)
trap rm \$tmpfile\ EXIT
git rev-list $@ | sed 's/^/100644 blob [0-9a-f]{40}\t/' $tmpfile
GIT_DIR=$(git rev-parse --git-dir)
GIT_INDEX_FILE=$GIT_DIR/index-rnotes git read-tree $remote_notes
git ls-tree $local_notes | grep -E -f $tmpfile |
GIT_INDEX_FILE=$GIT_DIR/index-rnotes git update-index --index-info
tree=$(GIT_INDEX_FILE=$GIT_DIR/index-rnotes git write-tree)
if test x$tree = x$(git rev-parse $remote_notes_ref^{tree}); then
echo empty commit
exit 0
fi
commit=$(git commit-tree $tree -p $remote_notes_ref EOF
Notes added by 'git notes-copy'
source notes: $(git rev-parse $local_notes)
EOF
)
git update-ref $remote_notes $commit $remote_notes_ref
---8---
It still has some edges, but I think it will do for me. Enhancements
welcome.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG?: git-filter-branch removes mergetags
Hello, I just noticed that git-filter-branch doesn't preserve mergetag annotations in situations where it could. Here is an example (with linux.git): $ git checkout -b test 6cd2f85413eef8fe7bcd7c25bf55e7b055fa257c $ git cat-file commit HEAD | grep mergetag mergetag object 954263938706bf62d36e81b6b49f313390f2ed35 $ git filter-branch -f --msg-filter 'sed s/foo/bar/' HEAD^! Rewrite 6cd2f85413eef8fe7bcd7c25bf55e7b055fa257c (1/1) Ref 'refs/heads/test' was rewritten $ diff -u (git cat-file commit refs/original/refs/heads/test) (git cat-file commit HEAD) --- /dev/fd/63 2014-09-23 21:07:49.987065017 +0200 +++ /dev/fd/62 2014-09-23 21:07:49.991064988 +0200 @@ -3,32 +3,6 @@ parent 954263938706bf62d36e81b6b49f313390f2ed35 author Linus Torvalds torva...@linux-foundation.org 1411488823 -0700 committer Linus Torvalds torva...@linux-foundation.org 1411488823 -0700 -mergetag object 954263938706bf62d36e81b6b49f313390f2ed35 - type commit - tag for-linus - tagger Paolo Bonzini pbonz...@redhat.com 1411478481 +0200 - - Another fix for 3.17 arrived at just the wrong time, after I had sent - yesterday's pull request. Normally I would have waited for - some other patches to pile up, but since 3.17 might be short - here it is. - -BEGIN PGP SIGNATURE- - Version: GnuPG v2.0.22 (GNU/Linux) - - iQIcBAABAgAGBQJUIXPRAAoJEBvWZb6bTYbyySEP/AkPjfNGYqwBbM8GUJ4tt4gR - C+xbiO+xPr2qCwfi36DQtL0UPwJHWSq7SXaDMvSqMo22FjnFcVaGuQcGAPno/8ZA - tLBe1km9HIPlEIV3vpoe8PPpj9cuZ86+YOCuPIqK5fC7l6Ops0dhCOjf88tmPVQ4 - yhodpJ1Lt/sPBUWb6pNfk0iWD+qSbfUWtwzv89oudEvLcLiAcPSBdbvnxVS3bmGm - qbL8pvCOozK5GJbl0+cYWCoEPBP5ekqGvwvGdEBTx+4qv2S2htzUX30UA2VYy5IR - jMXVrJbvSW9FXQdBgr0Q4ql6evOVjL+5LpwgRUC6tuC6r1rMP+nXyHKS35HC1i8W - FYr62B/LZTm4vyDHsmsiEl43VLAcF7kmXufQT62vJg+ifeA1MAMIJra7ZDx8WbsD - HDqM+CeaZrF3p4okRrktbecQdeFFyg4wOasHRTO7SETkbP7i1cS0Mp8rRbX3CnJq - 0UM8STe+hViXR7uYZEbjlbGKkszDS49fstJIaNm9JPJm+S/V5/MZFelNWgPp/+kF - xpQUxtoSaFnqgBXpRZ7t2Y2zGeZkMWn/P84S23/7K1TfRPCsUpgFbiY26rGW9l4v - r8gz7v+V1gCzWYVRuEzolFrea6A1ik2sspzeDuZOrf+QYwMyyUdEQ/NfCm032wba - CYL0V2M/dJNmZnZRPP9/ - =ZkSE - -END PGP SIGNATURE- Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm I expected the signature to not disappear such that in the example above no change is introduced. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] log-tree: let format-patch not indent notes
Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't indented and also the Notes: header isn't really useful. So consequently don't indent and skip the header in this case. This also removes the empty line between the end-of-commit marker and the start of the notes. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- This commit changes the output of format-patch (applied on this commit) from: ... case. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Notes: This commit changes the output of format-patch (applied on this commit) from: to ... case. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- This commit changes the output of format-patch (applied on this commit) from: which I consider to be more useful. log-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/log-tree.c b/log-tree.c index bcee7c596696..c1d73d8fecdf 100644 --- a/log-tree.c +++ b/log-tree.c @@ -585,7 +585,8 @@ void show_log(struct rev_info *opt) int raw; struct strbuf notebuf = STRBUF_INIT; - raw = (opt-commit_format == CMIT_FMT_USERFORMAT); + raw = (opt-commit_format == CMIT_FMT_USERFORMAT) || + (opt-commit_format == CMIT_FMT_EMAIL); format_display_notes(commit-object.sha1, notebuf, get_log_output_encoding(), raw); ctx.notes_message = notebuf.len -- 2.1.1.274.gb3e1830.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] log-tree: let format-patch not indent notes
Hello Junio, On Thu, Sep 25, 2014 at 10:24:53AM -0700, Junio C Hamano wrote: Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't indented and also the Notes: header isn't really useful. So consequently don't indent and skip the header in this case. This also removes the empty line between the end-of-commit marker and the start of the notes. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- This commit changes the output of format-patch (applied on this commit) from: ... case. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Notes: This commit changes the output of format-patch (applied on this commit) from: to ... case. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- This commit changes the output of format-patch (applied on this commit) from: which I consider to be more useful. I suspect that is fairly subjective, as the current one is in that form because those who wrote this feature first, reviewed, applied would have considered it more useful, isn't it? Well, I thought when the feature to dump the notes into a patch was created there was exactly one way these notes were written. This was was designed for git-log and so intended and with Notes:. For git-format-patch it was good enough. Because I never send out a format-patch output without looking it over in an editor, I know I can easily remove it if I find the Notes: out of place in the output, but if the Notes: thing weren't there in the first place I may scratch my head trying to figure out where to update it if the information there were stale, so for that reason I'd find it more useful to have Notes: to remind me where that information comes from. As you must explicitly request notes to be included in patches (--notes) I think it's unusual to not know where the info comes from, doesn't it? I don't know how many people use git-notes to track their comments, but the first thing I do when editing patches is to remove the Notes: header and s/^// on the remaining lines. And most of the time this is the only thing I do and I need to touch every patch only because of that. But that is just my personal preference and I am willing to be persuaded either way with a better argument than to me it looks nicer. As to indenting, because the material after three-dashes is meant to be fed to git apply or patch, I'd prefer to keep it to avoid having to worry about a payload that may look like part of a patch. This preference is a bit stronger than the presence/absence of Notes:. Ok, that's a valid concern. If we want to assert that this doesn't look like a patch we need to at least parse the notes and quote it somehow. Hmm. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git log anomalities
Hello, today I looked at the changes to drivers/net/ethernet/freescale/fec.c in the kernel since v3.8 using git log --stat v3.8.. --full-diff -- drivers/net/ethernet/freescale/fec.c which looks as expected. But when I added --graph the diffstats change. E.g. for 793fc0964be1921f15a44be58b066f22b925d90b it changes from: drivers/net/ethernet/freescale/Makefile |3 +- drivers/net/ethernet/freescale/fec.c | 1966 - drivers/net/ethernet/freescale/fec_main.c | 1966 + drivers/net/ethernet/freescale/fec_ptp.c |3 - 4 files changed, 1968 insertions(+), 1970 deletions(-) to | Documentation/devicetree/bindings/net/dsa/dsa.txt | 91 + | .../bindings/net/marvell-orion-mdio.txt |3 + | Documentation/networking/ip-sysctl.txt| 35 +- | MAINTAINERS |2 +- | arch/arm/net/bpf_jit_32.c |5 +- | arch/arm/plat-orion/common.c | 54 +- | arch/powerpc/net/bpf_jit_comp.c | 12 +- | ... | 404 files changed, 15373 insertions(+), 8563 deletions(-) Is that a bug, or a feature I don't understand? (I'm using Debian's 1:1.8.3.2-1) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: use true parents for diff even when rewriting
Hello Thomas, On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote: Junio C Hamano gits...@pobox.com writes: Conceptually I can see how this will change the history simplification in the vertical direction (skipping the ancestry chain and jumping directly to the closest grandparent that touched the specified path), but I am not sure how well this interacts with history simplification in the horizontal direciton (culling irrelevant side branches from the merge). But isn't that similarly confusing for the user as Uwe's original problem? Suddenly we'd be showing a merge commit as an ordinary one, simply because the merged history did not affect the filtered pathspecs. Thus we would show everything that has been merged on the *other* files as a big diff. Would that be useful? It would certainly be a big difference in how the commit is shown. the merge is only included in the output if on both parent paths the file is touched. So this is a non-issue, isn't it? (Well, only if it has more than 2 parents and not all ancestor paths touch the file, the number of parents shown is changed.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
feature suggestion: improve rerere
Hello,
I think the following suggestion is sound. And it might even be easy to
implement but I don't know how rerere works, so I might be wrong here.
When applying a patch it's normal to hit a conflict. For me this just
happend:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,29 @@@
#include mtd/mtd-user.h
++ ours
+#include common.h
+
++||| base
++===
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
easy to resolve to:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,25 @@@
#include mtd/mtd-user.h
+#include common.h
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
Now if I shuffle patches and put the new patch before the conflicting
patch, I have to resolve first:
$ git diff
diff --cc flash_otp_write.c
index d407ebb,31b963e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,6 -15,25 +15,31 @@@
#include mtd/mtd-user.h
++ ours
++||| base
++#include common.h
++
++===
+ #include common.h
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
which is resolved to just adding the function and dropping the #include.
But then readding the 2nd patch it conflicts again:
$ git diff
diff --cc flash_otp_write.c
index 648e042,f360a3e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,23 -15,8 +15,29 @@@
#include mtd/mtd-user.h
++ ours
+ssize_t xread(int fd, void *buf, size_t count)
+{
+ ssize_t ret, done = 0;
+
+retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+}
+
++||| base
++===
+ #include common.h
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
This is the same conflict as the first one, just with ours and theirs
exchanged. So my suggestion is to make rerere use the resolution
recorded for the first conflict here.
Sounds sensible?
Best regards
Uwe
PS: I'm using Debian's git 1.8.2~rc2-1 and hope I didn't miss this
feature already implemented while looking through v1.8.2..junio/next.
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
feature suggestion: optimize common parts for checkout --conflict=diff3
Hello, Here comes another recipe for a different suggestion: git init echo 1 file git add file git commit -m 'base' git branch branch seq 1 30 | grep -v 15 file git commit -m 'add 2-30 without 15' file git checkout branch seq 1 30 | grep -v 16 file git commit -m 'add 2-30 without 16' file git merge master git diff This yields: diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,11 @@@ 12 13 14 ++ HEAD +15 ++=== + 16 ++ master 17 18 19 as expected; nice and sweet. After git checkout --conflict=diff3 file however the difference isn't that easy to spot any more. I expected diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,12 @@@ 12 13 14 ++ ours +15 ++||| base ++=== + 16 ++ theirs 17 18 19 But instead I get diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -1,29 -1,29 +1,61 @@@ 1 ++ ours +2 +3 +4 +5 +6 +7 +8 +9 +10 +11 +12 +13 +14 +15 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 ++||| base ++=== + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 ++ theirs Of course this is technically correct, just not maximally helpful. Is this a missing optimisation for the diff3 case or did I miss a detail that makes my expectation wrong? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xdiff: implement a zealous diff3
zdiff3 is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two near identical additions.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello,
this patch implements what I want. Thanks to Jeff for pointing me to the
right code to modify.
Best regards
Uwe
builtin/merge-file.c | 2 ++
contrib/completion/git-completion.bash | 2 +-
xdiff-interface.c | 2 ++
xdiff/xdiff.h | 1 +
xdiff/xmerge.c | 8 +++-
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index c0570f2..4ef86aa 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -32,6 +32,8 @@ int cmd_merge_file(int argc, const char **argv, const char
*prefix)
struct option options[] = {
OPT_BOOLEAN('p', stdout, to_stdout, N_(send results to
standard output)),
OPT_SET_INT(0, diff3, xmp.style, N_(use a diff3 based
merge), XDL_MERGE_DIFF3),
+ OPT_SET_INT(0, zdiff3, xmp.style, N_(use a zealous diff3
based merge),
+ XDL_MERGE_ZEALOUS_DIFF3),
OPT_SET_INT(0, ours, xmp.favor, N_(for conflicts, use our
version),
XDL_MERGE_FAVOR_OURS),
OPT_SET_INT(0, theirs, xmp.favor, N_(for conflicts, use
their version),
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b62bec0..a0d887e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1091,7 +1091,7 @@ _git_checkout ()
case $cur in
--conflict=*)
- __gitcomp diff3 merge ${cur##--conflict=}
+ __gitcomp diff3 merge zdiff3 ${cur##--conflict=}
;;
--*)
__gitcomp
diff --git a/xdiff-interface.c b/xdiff-interface.c
index ecfa05f..a911c25 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -308,6 +308,8 @@ int git_xmerge_config(const char *var, const char *value,
void *cb)
die('%s' is not a boolean, var);
if (!strcmp(value, diff3))
git_xmerge_style = XDL_MERGE_DIFF3;
+ else if (!strcmp(value, zdiff3))
+ git_xmerge_style = XDL_MERGE_ZEALOUS_DIFF3;
else if (!strcmp(value, merge))
git_xmerge_style = 0;
else
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 219a3bb..9730c63 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -64,6 +64,7 @@ extern C {
/* merge output styles */
#define XDL_MERGE_DIFF3 1
+#define XDL_MERGE_ZEALOUS_DIFF3 2
typedef struct s_mmfile {
char *ptr;
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9e13b25..4772707 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -177,7 +177,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
size += xdl_recs_copy(xe1, m-i1, m-chg1, 1,
dest ? dest + size : NULL);
- if (style == XDL_MERGE_DIFF3) {
+ if (style == XDL_MERGE_DIFF3 || style == XDL_MERGE_ZEALOUS_DIFF3) {
/* Shared preimage */
if (!dest) {
size += marker_size + 1 + marker3_size;
@@ -420,6 +420,12 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1,
int style = xmp-style;
int favor = xmp-favor;
+ /*
+* This is the only change between XDL_MERGE_DIFF3 and
+* XDL_MERGE_ZEALOUS_DIFF3. zdiff3 isn't 100% technically correct (as
+* the base might be considerably simplified), but still it might help
+* interpreting conflicts between two big and near identical additions.
+*/
if (style == XDL_MERGE_DIFF3) {
/*
* diff3 -m output does not make sense for anything
--
1.8.2.rc2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature suggestion: optimize common parts for checkout --conflict=diff3
Hello Junio, On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. Hmm, unless you mean by base something entirely different from what was in the common ancestor version, I do not think I can agree. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers. We show both sides added, either identically or differently as noteworthy events, but the patched code pushes both sides added identically case outside the conflicting hunk, as if what was added I didn't test, but both sides removed identically should be moved out, too, shouldn't it? relative to the common ancestor version (in Uwe's case, is it 1-14 that is common, or just 10-14?) is not worth looking at when considering what the right resolution is. If it is not worth looking at what was in the original for the conflicting part, why would we be even using diff3 mode in the first place? because even zdiff3 contains more information than merge. And compared to diff3 it's smaller sometimes and so easier to understand. Other than that I agree fully to the things Jeff said so far. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG gitk] notes not reloaded on Update/Reload
Hello, running gitk from Debian (1:1.8.2~rc3-1) I noticed that $ gitk ... $ git notes edit $some_ref_shown_by_gitk and then pressing F5 or Shift-F5 doesn't update the notes shown. Best regards Uwe PS: Please Cc: on replies as I'm not subscribed -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG gitk] strange scrolling behaviour if history canvas not completely filled
Hello, (running gitk from Debian's gitk 1:1.8.2~rc3-1 package) if only a few commits are shown in gitk such that the history canvas is too big, i.e. there is place for more commits to be shown, the scroll bar on the right hand side correctly is greyed out. Still I can scroll using the mouse moving the oldest shown to the bottom of the canvas (sometimes even half a line further). Not sure this qualifies as bug already. But when having scrolled down selecting commits with the mouse doesn't work as expected anymore: If I click on the topmost commit, not that one is selected but the one that would appear at the mouse tip if the history were not scrolled down. Best regards Uwe PS: I'm not subscribed, so please Cc: me on replies. -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
Hi Uwe,
This series was tested on a Phytec pcm038 (mc13783 on spi) using
traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
i2c) using dt boot.
Philippe's patches are already in next, they are just included here for
those who want to test the patches. The 'mfd/mc13xxx: drop modifying
driver's id_table in probe' was already sent out yesterday and is
included here because the last patch depends on it.
For all patches (that don't already have it):
Acked-by: Marc Reilly m...@cpdesign.com.au
Thanks.
If for some reason you do a V2:
- In patch 6 moves line #define MC13XXX_NUMREGS 0x3f around, is this
necessary?
It doesn't move it around, that's only how it looks. I removed enum
mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
(below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
mc13xxx_id and struct mc13xxx_variant respectively as context (together
with the following empty line).
(For the new readers, here is how git represented the relevant part:
#include linux/regmap.h
#include linux/mfd/mc13xxx.h
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
+#define MC13XXX_NUMREGS 0x3f
+
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
};
-#define MC13XXX_NUMREGS 0x3f
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
struct mc13xxx {
struct regmap *regmap;
...
)
The following would be an equivalent and (for humans) easier to review
patch:
#include linux/regmap.h
#include linux/mfd/mc13xxx.h
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
-};
-
#define MC13XXX_NUMREGS 0x3f
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
+};
+
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
+
struct mc13xxx {
struct regmap *regmap;
...
But as this touches 17 lines compared to only 15 using the way git
choosed to represent patch 6, git used the smaller representation. (I'm
not sure this is the correct reason, but at least it sounds sensible.)
Usually this metric is sane, but here it's not. I don't know if you can
do anything about it? E.g. take the number of +, - and context blocks
into account. Then it would be 5 for the patch above vs. 7 for the
way git did it.
Or weight a context line containing
#define MC13XXX_NUMREGS 0x3f
more than two lines one of which is empty and the other only contains a
}?
- Patch 4 should come last, ie after add support for mc34708
Yeah, but it doesn't break bisectibility, and as the rtc patches go in via a
different tree (in fact akpm already took them) it doesn't matter much.
Best regards and thanks for your feedback
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature suggestion: optimize common parts for checkout --conflict=diff3
Hi Jeff, On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote: [...] So I do think zdiff3 is useful, and I plan to continue using it. Thanks for your description. I'm using and liking zdiff3, too. So I'd really like seeing it in vanilla git. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG?] git checkout $commit -- somedir doesn't drop files
Hello, after these commands: $ git init $ mkdir subdir $ echo a subdir/a $ git add subdir/a $ git commit -m a $ echo more a subdir/a $ echo b subdir/b $ git add subdir/* $ git commit -m b $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: subdir/a # Is this intended? (I'm using git 1.8.4.rc3 as shipped by Debian (package version 1:1.8.4~rc3-1).) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: git request-pull broken for plain branches
Hello, I have git from Debian's 2.0.0-2 package: $ git version git version 2.0.0 git request-pull is broken for me: $ git rev-parse HEAD 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 refs/heads/ukl/for-mainline $ git request-pull origin/master origin HEAD /dev/null warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 found at origin warn: Are you sure you pushed 'HEAD' there? The same happens on 2.0.0.421.g786a89d. The problem is in git-request-pull.sh's find_matching_ref. This code has more than one problem (looking on 2.0.0.421.g786a89d): - find_matching_ref doesn't assign to $found if none of the if conditions in the loop match (this results in my problem); - find_matching_ref happily overwrites $found even if the previous ref was better according to the metric specified above the definition of find_matching_ref; and - the output generated uses $pretty_remote without asserting that it matches $ref. In my case this results in a branch specification of HEAD even if I fix find_matching_ref to return refs/heads/ukl/for-mainline. I tried to add this case to t/t5150-request-pull.sh, but didn't understand how after starring at it for half an hour. :-( Bisection points on 024d34cb0813 (request-pull: more strictly match local/remote branches) as first bad commit. Apart from introducing the warning, it also changes the branch spec from ukl/for-mainline (which is correct) to the name of the current branch (which is bogus). Also 024d34cb0813 makes 5 out of 7 tests in t/t5150-request-pull.sh fail. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: git request-pull broken for plain branches
Hello Linus, On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote: On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: $ git rev-parse HEAD 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 refs/heads/ukl/for-mainline $ git request-pull origin/master origin HEAD /dev/null warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 found at origin warn: Are you sure you pushed 'HEAD' there? Notice how HEAD does not match. The error message is perhaps misleading. It's not enough to match the commit. You need to match the branch name too. git used to guess the branch name (from the commit), and it often guessed wrongly. So now they need to match. So you should do git request-pull origin/master origin ukl/for-mainline to let request-pull know that you're requesting a pull for ukl/for-mainline. If you have another name for that branch locally (ie you did something like git push origin local:remote), then you can say git request-pull origin/master origin local-name:remote-name to specify what the branch to be pulled is called locally vs remotely. In other words, what used to be pick some branch randomly is now you need to _specify_ the branch. ah, got it. Still some of my concerns stay valid and I also have some new ones: - if there is a branch and a tag on the remote side that match what I specified the outcome depends on the order of git-ls-remote. (minor nit.) - if I have to specify the remote name now, why do I have to also specify my local ref? Isn't the respective $sha1 of the remote side enough to do what is needed? - Isn't $found = $sha1; silly because I cannot pull a rev, only a ref? (side note: git pull linus d91d66e88ea95b6dd21958834414009614385153 gives no error message, only returns 1 and does nothing else.) - Is the result of git request-pull $somecommit origin what is intended? For me it does ... are available in the git repository at: $repository for you to fetch changes ... if the remote HEAD matches the local one. I'd prefer to have an explicit branch name there, or at least HEAD. I liked git guessing the branch name, maybe we can teach it to guess a bit better than it did before 2.0? Something like: - if there is a unique match on the remote side, use it. - if there are = 1 match on the remote side and exactly one matches what I specified as end, use it. - if there are = 1 match on the remote side and exactly one of them is a tag, use the tag - if there are two matches on the remote side, and one is HEAD, pick the other one. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: git request-pull broken for plain branches
Hi Junio, On Wed, Jun 25, 2014 at 01:41:23PM -0700, Junio C Hamano wrote: Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote: On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: $ git rev-parse HEAD 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 refs/heads/ukl/for-mainline $ git request-pull origin/master origin HEAD /dev/null warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 found at origin warn: Are you sure you pushed 'HEAD' there? Notice how HEAD does not match. The error message is perhaps misleading. It's not enough to match the commit. You need to match the branch name too. git used to guess the branch name (from the commit), and it often guessed wrongly. So now they need to match. So you should do git request-pull origin/master origin ukl/for-mainline to let request-pull know that you're requesting a pull for ukl/for-mainline. Or git request-pull origin/master origin HEAD:ukl/for-mainline I am not Linus, and do not speak for him, but FWIW here are some comments on the ideas. I liked git guessing the branch name, maybe we can teach it to guess a bit better than it did before 2.0? Something like: - if there is a unique match on the remote side, use it. I am on the fence but slightly leaning to the negative side on this one. The branch/ref the object was took from when git pull is run does matter, because the name is recorded in the merge summary, so we cannot say There are refs that happen to point at the object you wanted to be pulled, so we'll pick one of them let the integrator pull from that ref we randomly chose is not something we would want. If there is a unique one, that must be the one the user has meant; there is nothing else possible feels like a strong argument, and I was actually contemplating about doing an enhancement on top of Linus's original myself along that line, back when we queued that patch exactly for that reason. But a counter-argument, in the context of Linus's change in question being primarily to avoid end-user mistakes resulting in a bogus request, is that the ref on the remote that happens to match the object but is different from what the user named may be a totally unrelated branch before the user actually has pushed the set of changes the request is going to ask to be pulled. The mistake that this extra strictness tries to avoid is to compose request-pull before pushing what to be pulled and then forgetting to push. Sounds sensible. Then the enhancements that come to my mind are: Change git-request-pull to explicitly take a remote ref as end. This makes sure that it is actually there and the right remote name is picked. Don't require to specify a local ref even if there is no local matching ref, just use the remote sha1 to generate the diffstat and summary. Another thing I'd like to have is to make git-request-pull not generate the usual output if there is no match. Optionally introduce a -f to get back the (maybe bogus) output; in this case a local rev would be needed. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git filter-branch and merging of signed tags
Hello,
Consider I want to rewrite a commit that is a merge of a signed tag. In
my case that's 064ca93f7ab927c2752d86fc5727716e340d737c that currently
sits in linux-next:
~/gsrc/linux$ git version
git version 2.6.1
~/gsrc/linux$ git checkout 064ca93f7ab927c2752d86fc5727716e340d737c
~/gsrc/linux$ git cat-file commit HEAD
tree 7086bbd51d06ebd0e3fcca70380d0a066efce6ef
parent e44a01fa0e0aec2f3a21dadb9c030d14831d4258
parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4
author Arnd Bergmann <a...@arndb.de> 1444139956 +0200
committer Arnd Bergmann <a...@arndb.de> 1444139956 +0200
mergetag object f719a0d6a8541b383c506aaa4b4fa6b4109669f4
type commit
tag efm32-for-4.4-rc1
tagger Uwe Kleine-König <u...@kleine-koenig.org> 1443549594 +0200
efm32 cleanups for 4.4-rc1
These are just two followup cleanups for commits that are in v3.17-rc1
and
waited in my private tree for application since that time.
-BEGIN PGP SIGNATURE-
iQEcBAABCgAGBQJWCtIwAAoJEMH8FHityuwJFPYH/2LJpi0yUhI01s0D9U5rZgjl
8mLP70utAMaqXiGqP/O0ndH+za5TrrUTwDJE5jhAHru1Q6q62Ld2BfOR5+K8zlrP
4UDGBDj3ePJgEtbSsJYJIRT+AKque2GONbeGpJh2arPrNamWChKIz8HoGSgwdRlx
TvQuVFEa6C3ujP0ATM8x54f0vR4bYm9WmBS522DwZQY4JpGZC005A3Quw6fmFxPJ
vJRo1fE1d2OZ3Cuxb15m8PLtZw6sbMdMwgyirAFGrJsN9u/V6BzsSzH0s8suT7IP
WIohnmYtFSUfkQjaGrMl2wIpJSsIzettiXf9GrQDXSGZsQ4k7sW3U+qrcZ7ZUR4=
=ngv1
-END PGP SIGNATURE-
Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux
into next/cleanup
Merge "efm32 cleanups for 4.4-rc1" from Uwe Kleine-Koenig:
These are just two followup cleanups for commits that are in v3.17-rc1
and
waited in my private tree for application since that time.
* tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux:
ARM: efm32: switch to vendor,device compatible strings
ARM: efm32: switch to properly namespaced location property
OK, to fix my name in the commit log I do:
git filter-branch -f --msg-filter "sed 's/Kleine-Koenig/$(echo
Kleine-K+APY-nig | iconv -f utf-7 -t utf-8)/'" HEAD ^HEAD^ ^HEAD^2
This destroys the mergetag, as now I have:
~/gsrc/linux$ git cat-file commit HEAD
tree 7086bbd51d06ebd0e3fcca70380d0a066efce6ef
parent e44a01fa0e0aec2f3a21dadb9c030d14831d4258
parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4
author Arnd Bergmann <a...@arndb.de> 1444139956 +0200
committer Arnd Bergmann <a...@arndb.de> 1444139956 +0200
efm32 cleanups for 4.4-rc1
These are just two followup cleanups for commits that are in v3.17-rc1
and
waited in my private tree for application since that time.
-BEGIN PGP SIGNATURE-
iQEcBAABCgAGBQJWCtIwAAoJEMH8FHityuwJFPYH/2LJpi0yUhI01s0D9U5rZgjl
8mLP70utAMaqXiGqP/O0ndH+za5TrrUTwDJE5jhAHru1Q6q62Ld2BfOR5+K8zlrP
4UDGBDj3ePJgEtbSsJYJIRT+AKque2GONbeGpJh2arPrNamWChKIz8HoGSgwdRlx
TvQuVFEa6C3ujP0ATM8x54f0vR4bYm9WmBS522DwZQY4JpGZC005A3Quw6fmFxPJ
vJRo1fE1d2OZ3Cuxb15m8PLtZw6sbMdMwgyirAFGrJsN9u/V6BzsSzH0s8suT7IP
WIohnmYtFSUfkQjaGrMl2wIpJSsIzettiXf9GrQDXSGZsQ4k7sW3U+qrcZ7ZUR4=
=ngv1
-END PGP SIGNATURE-
Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux
into next/cleanup
Merge "efm32 cleanups for 4.4-rc1" from Uwe Kleine-König:
These are just two followup cleanups for commits that are in v3.17-rc1
and
waited in my private tree for application since that time.
* tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux:
ARM: efm32: switch to vendor,device compatible strings
ARM: efm32: switch to properly namespaced location property
~/gsrc/linux$ diff -u <(git cat-file commit HEAD) <(git cat-file commit
064ca93f7ab927c2752d86fc5727716e340d737c)
--- /dev/fd/63 2015-11-02 09:02:17.310373539 +0100
+++ /dev/fd/62 2015-11-02 09:02:17.310373539 +0100
@@ -3,7 +3,11 @@
parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4
author Arnd Bergmann <a...@arndb.de> 1444139956 +0200
committer Arnd Bergmann <a...@arndb.de> 1444139956 +0200
-
+mergetag object f719a0d6a8541b383c506aaa4b4fa6b4109669f4
+ type commit
+ tag efm32-for-4.4-rc1
+ tagger Uwe Kleine-König <u...@kleine-koenig.org> 1443549594 +0200
+
efm32 cleanups for 4.4-rc1
These are just two followup cleanups for commits that are in
v3.17-rc1 and
@@ -21,7 +25,7 @@
Merge tag 'efm32-for-4.4-rc1' of
git://git.pengutronix.de/git/ukl/linux into next
Re: git filter-branch and merging of signed tags
Hello Michael, On Mon, Nov 02, 2015 at 05:21:03PM +0100, Michael J Gruber wrote: > Uwe Kleine-König venit, vidit, dixit 02.11.2015 09:04: > > ~/gsrc/linux$ git version > > git version 2.6.1 > > Does your git include > a5a4b3f (filter-branch: remove multi-line headers in msg filter, > 2015-10-08)? That takes care of the incomplete header tag parsing. No, it does not. Thanks for the hint. > Should be in master by now, I think. > > Keeping the mergetag signature would require some extra logic in > filter-branch. that I'd like to have :-). It seems I have to dig into that myself. (If someone is quicker than me, I promise not to be angry :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello,
when applying the mail below (without the '> ' prefix) using git am
--scissors the result looks like:
$ git show
commit 26ef0606927cc1979faa4166d7f9f3584b5cdc61
Author: Tony Lindgren <t...@atomide.com>
Date: Tue Oct 6 05:36:17 2015 -0700
memory: omap-gpmc: Fix unselectable debug option for GPMC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for
debug")
added a debug option for GPMC, but somehow managed to keep it
unselectable.
[...]
$ git version
git version 2.6.0
The obvious improvement is to strip all headers like git am does without
--scissors.
If someone wants a bounce of the original mail, just ask per PM.
Best regards
Uwe
On Wed, Oct 07, 2015 at 03:41:19AM -0700, Tony Lindgren wrote:
> * Uwe Kleine-König <u.kleine-koe...@pengutronix.de> [151007 00:57]:
> > On Wed, Oct 07, 2015 at 10:45:50AM +0300, Roger Quadros wrote:
> > >
> > > How about this instead?
> > >
> > > NOTE: Apart from matching the register setup with the bootloader you also
> > > need to
> > > match the GPMC FCLK frequency used by the bootloader else the GPMC timings
> > > won't be identical with the bootloader timings.
> > Yeah, sounds better, thanks.
> >
> > > Also you might need to build this patch on top of
> > > http://article.gmane.org/gmane.linux.kernel/2054796
> > I talked to Tony about this patch yesterday on irc, but I didn't find it
> > in the archives yet when I sent my mail.
>
> Yes sorry here's a repost with your and Roger's changes folded in and
> edited a bit. Probably best to keep them together with this patch.
>
> Does the following look OK to you guys?
>
> Regards,
>
> Tony
>
> 8<
> From: Tony Lindgren <t...@atomide.com>
> Date: Tue, 6 Oct 2015 05:36:17 -0700
> Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> This probably happened because I had some uncommitted changes and the
> GPMC option is selected in the platform specific Kconfig.
>
> Let's also update the description a bit, it does not mention that
> enabling the debug option also disables the reset of GPMC controller
> during the init as pointed out by Uwe Kleine-König
> <u.kleine-koe...@pengutronix.de> and Roger Quadros <rog...@ti.com>.
>
> Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> Reported-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
> Signed-off-by: Tony Lindgren <t...@atomide.com>
>
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -58,12 +58,18 @@ config OMAP_GPMC
> memory drives like NOR, NAND, OneNAND, SRAM.
>
> config OMAP_GPMC_DEBUG
> - bool
> + bool "Enable GPMC debug output and skip reset of GPMC during init"
> depends on OMAP_GPMC
> help
> Enables verbose debugging mostly to decode the bootloader provided
> - timings. Enable this during development to configure devices
> - connected to the GPMC bus.
> + timings. To preserve the bootloader provided timings, the reset
> + of GPMC is skipped during init. Enable this during development to
> + configure devices connected to the GPMC bus.
> +
> + NOTE: In addition to matching the register setup with the bootloader
> + you also need to match the GPMC FCLK frequency used by the
> + bootloader or else the GPMC timings won't be identical with the
> + bootloader timings.
>
> config MVEBU_DEVBUS
> bool "Marvell EBU Device Bus Controller"
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello Junio,
On Thu, Oct 08, 2015 at 01:04:01PM -0700, Junio C Hamano wrote:
> Uwe Kleine-König <u.kleine-koe...@pengutronix.de> writes:
>
> >> Does this have anything to do with scissors, though? If you remove
> >> everything before "8< ---" in the body of Tony's message (i.e. keep
> >> the in-body headers starting with "From:" and ending with CTE) and
> >> try again, I would suspect that you will get the same result.
> > No, you're wrong here:
> >
> > u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
> > From: Tony Lindgren <t...@atomide.com>
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> I think you are the one who misread my question. I said "keep the
> in-body headers", didn't I? If you did the "head", then you would
> see something like this:
Ah got it. Yes, you're right. (Subject and Date are actually different
between real and in-body headers, but that's not important. git am picks
up the in-body headers.)
> > u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
> > From: Tony Lindgren <t...@atomide.com>
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > ... probably Received: and all other junk from your mailbox ...
> >
> > From: Tony Lindgren <t...@atomide.com>
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> >> I also think that the "MIME-Version" thing is what gives this;
> >> mailinfo and am do not really use it, and consider that the in-body
> >> header ends there.
> >
> > I failed to follow you here.
>
> I think if you tried the example with in-body header, you will see
> what I meant.
>
> >
> >> The right approach to tweak mailinfo to cope with this better would
> >> be to keep a bit more state inside mailinfo.c::handle_commit_msg()
> >> so that if we are (1) using in-body headers, (2) have already seen
> >> _some_ valid in-body header like "Subject:" and "From: ", and (3)
> >> have not seen a blank line, discard lines that we do not care about
> >> (e.g. "MIME-VERSION: 1.0").
The right thing should also happen if MIME-Version comes above Subject
in the body but other than that I'm with you here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello Junio,
On Thu, Oct 08, 2015 at 12:28:46PM -0700, Junio C Hamano wrote:
> Uwe Kleine-König <u.kleine-koe...@pengutronix.de> writes:
>
> > Hello,
> >
> > when applying the mail below (without the '> ' prefix) using git am
> > --scissors the result looks like:
> >
> > $ git show
> > commit 26ef0606927cc1979faa4166d7f9f3584b5cdc61
> > Author: Tony Lindgren <t...@atomide.com>
> > Date: Tue Oct 6 05:36:17 2015 -0700
> >
> > memory: omap-gpmc: Fix unselectable debug option for GPMC
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for
> > debug")
> > added a debug option for GPMC, but somehow managed to keep it
> > unselectable.
> >
> > [...]
> >
> > $ git version
> > git version 2.6.0
> >
> > The obvious improvement is to strip all headers like git am does without
> > --scissors.
>
> Does this have anything to do with scissors, though? If you remove
> everything before "8< ---" in the body of Tony's message (i.e. keep
> the in-body headers starting with "From:" and ending with CTE) and
> try again, I would suspect that you will get the same result.
No, you're wrong here:
u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
From: Tony Lindgren <t...@atomide.com>
Date: Tue, 6 Oct 2015 05:36:17 -0700
Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.
u...@dude.ptx:~/gsrc/linux$ git am ~/tmp/1444332661.3982_89.ptx\:2\,RS
Applying: memory: omap-gpmc: Fix unselectable debug option for GPMC
u...@dude.ptx:~/gsrc/linux$ git cat-file commit HEAD
tree bab01e3e0d0bdd715b86cf7d5c9e8bb9768a30dc
parent c6fa8e6de3dc420cba092bf155b2ed25bcd537f7
author Tony Lindgren <t...@atomide.com> 1444134977 -0700
committer Uwe Kleine-König <u.kleine-koe...@pengutronix.de> 1444332782 +0200
memory: omap-gpmc: Fix unselectable debug option for GPMC
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.
This probably happened because I had some uncommitted changes and the
GPMC option is selected in the platform specific Kconfig.
Let's also update the description a bit, it does not mention that
enabling the debug option also disables the reset of GPMC controller
during the init as pointed out by Uwe Kleine-König
<u.kleine-koe...@pengutronix.de> and Roger Quadros <rog...@ti.com>.
Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
Reported-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
Signed-off-by: Tony Lindgren <t...@atomide.com>
> I also think that the "MIME-Version" thing is what gives this;
> mailinfo and am do not really use it, and consider that the in-body
> header ends there.
I failed to follow you here.
> The right approach to tweak mailinfo to cope with this better would
> be to keep a bit more state inside mailinfo.c::handle_commit_msg()
> so that if we are (1) using in-body headers, (2) have already seen
> _some_ valid in-body header like "Subject:" and "From: ", and (3)
> have not seen a blank line, discard lines that we do not care about
> (e.g. "MIME-VERSION: 1.0").
That sound's right.
> > If someone wants a bounce of the original mail, just ask per PM.
>
> I have no idea what you are talking about here...
The result would be that a copy of the original mail would hit your mailbox if
you asked per private mail (PM).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] howto/using-merge-subtree: mention --allow-unrelated-histories
Without passing --allow-unrelated-histories the command sequence
fails as intended since commit e379fdf34fee ("merge: refuse to create
too cool a merge by default"). To setup a subtree merging unrelated
histories is normal, so add the option to the howto document.
Signed-off-by: Uwe Kleine-König
---
Documentation/howto/using-merge-subtree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/howto/using-merge-subtree.txt
b/Documentation/howto/using-merge-subtree.txt
index 1ae8d1214ec0..a499a94ac228 100644
--- a/Documentation/howto/using-merge-subtree.txt
+++ b/Documentation/howto/using-merge-subtree.txt
@@ -33,7 +33,7 @@ Here is the command sequence you need:
$ git remote add -f Bproject /path/to/B <1>
-$ git merge -s ours --no-commit Bproject/master <2>
+$ git merge -s ours --no-commit --allow-unrelated-histories Bproject/master <2>
$ git read-tree --prefix=dir-B/ -u Bproject/master <3>
$ git commit -m "Merge B project as our subdirectory" <4>
--
2.19.1
