Re: [PATCH] revision: avoid work after --max-count is reached
On Fri, Jul 13, 2012 at 03:12:47PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Yeah, this was my analysis, too. Though reading get_revision-1, it seems like we can actually set SHOWN, but I wasn't able to trigger any change of behavior in practice. I think it is because we must set both SHOWN and BOUNDARY to have an effect, and we do not do so. In principle, SHOWN is only given when get_revision_internal gives the commit back to be shown, and the parents of the returned commit are painted CHILD_SHOWN. This should be the only place to paint commit as CHILD_SHOWN. A handful of places set the bit to commits that would be shown if some options that further limit what is shown by topological property (e.g. --left-only, --cherry-pick), which may cause that a parent of a commit that was omitted due to these conditions may later be marked incorrectly as a boundary inside create_boundary_commit_list(). I think what confused me is that I thought I saw get_revision_1 setting SHOWN in the reflog case. But of course it is _clearing_ the flag, since the reflog walker may show the commit multiple times. And no other code paths in get_revision_1 set it (nor should they, since as you say, it is about us actually handing back the commit to be shown). BOUNDARY is only given in create_boundary_commit_list() using CHILD_SHOWN and SHOWN, and that should happen only once when get_revision_1() runs out of the commits. Yeah, agreed. By the way, cherry_pick_list() pays attention to BOUNDARY, but I think it is written overly defensively to protect itself from future callsites. With the current code structure, it is only called from limit_list() and get_revision_*() functions are never called until limit_list() returns (and again create_boundary_commit_list() that is called from get_revision_internal() is the only place that sets BOUNDARY, so the commits cherry_pick_list() sees would never have that bit set. I think we wouldn't be impacting it even so, because the commits that make it to create_boundary_commit_list (and therefore get marked with BOUNDARY) should be identical. We only put items into the boundary_commits list when we are about to return them from get_revision_internal, and with my patch that will not change (because prior to my patch, we would have thrown away the commit after checking max_count anyway). So I think after looking again that this change is the right thing to do, and there shouldn't be any side effects. Thanks for the careful review. -Peff -- 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: [RFC] Add a new email notification script to contrib
mhagger at alum.mit.edu writes: From: Michael Haggerty mhagger at alum.mit.edu Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. This script is derived from contrib/hooks/post-receive-mail, but has many differences, including: Looks interesting! Do you have a fork of git.git somewhere that contains the script? (I find it so much easier these days to simply fetch another repo instead of applying patches with 'git am'.) Thanks, Stefan -- 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: Support of '^' as alias for 'HEAD^'
Zeeshan Ali (Khattak zeeshanak at gnome.org writes: Hi, Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. Or even '~1', '~3'. Where's the '+1' button...? Stefan -- 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: [RFC] Add a new email notification script to contrib
On Sat, Jul 14, 2012 at 12:37 PM, Tay Ray Chuan rcta...@gmail.com wrote:
Hi Stefan,
On Sat, Jul 14, 2012 at 5:46 PM, Stefan Näwe stefan.na...@gmail.com wrote:
Do you have a fork of git.git somewhere that contains the script?
(I find it so much easier these days to simply fetch another repo instead
of applying patches with 'git am'.)
you can try Show Original in gmail's interface and saving the text file,
then running git am directly on it. Old gits used to have problems with the
leading newline, but I don't see this problem nowadays.
If I only would be subscribed to gitlist with my gmail account...
Anyways, there's a nice script in msysgit.git [1] that makes applying patches
from gmane pretty easy. Thanks Dscho!
Stefan
[1] https://github.com/msysgit/msysgit/blob/devel/bin/apply-from-gmane.sh
--
python -c print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')
--
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
t1450-fsck (sometimes/often) failes on Mac OS X
I saw the problem first on pu, some time ago, but it dissappeared after cloning git.git into another directory. Now it appeared on next as well, so it's time to look a little bit deeper. This test case of t1450 fails: test_expect_success 'tag pointing to something else than its type' ' To debug more, I added an exit 0 here to inspect the file named out: diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh index 5b79c51..f1f45c9 100755 --- a/t/t1450-fsck.sh +++ b/t/t1450-fsck.sh @@ -179,6 +179,7 @@ test_expect_success 'tag pointing to something else than its type' ' test_when_finished git update-ref -d refs/tags/wrong test_must_fail git fsck --tags 2out cat out + exit 0 grep error in tag.*broken links out ' Linux: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object Mac OS X: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help Looking into the trash directory and looking at the files, we can see that the .git/index is different between Linux and Mac OS X. Is there a good way to debug the index file? BTW: git bisect pointed out: [76759c7dff53e8c84e975b88cb8245587c14c7ba] git on Mac OS and precomposed unicode But re-running t1450 makes it pass, so that bisect went into the wrong direction somewhere. It seems that t1450 is timing depending, sometimes it passes, sometimes not. And once it went into the state non passed, it stays there. It feels that I got stuck, any hints how to debug this further, please ? /Torsten -- 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] status: default in-progress color to header color
On Sat, Jul 14, 2012 at 08:28:28AM -0400, Jeff King wrote:
My intent was that this would also let color.status.inprogress
override it, in case a user really wanted a green message or something.
However, I notice that the original series did not add such a config
option, so this color cannot be configured at all. Furthermore, I think
the color formatting for this message is somewhat buggy. Even if we set
it to green, you would end up with (imagine our header color is blue):
blue# On branch masterreset
green# You are in the middle of a rebase.reset
when what you would probably want is:
blue# On branch masterreset
blue# resetgreenYou are in the middle of a rebase.reset
I.e., the # bit should always be in the header color, and only the
message text should change colors. This is how the onbranch message is
handled.
But given that this is not even configurable in the current code, I
really wonder if it needs to have its own color at all. Do people really
want to set the color of this message separately? Maybe we should just
use WT_STATUS_HEADER instead.
And that patch would look like this (directly on top of
lk/more-helpful-status-hints):
-- 8 --
Subject: [PATCH] status: color in-progress message like other header messages
The status command recently learned to describe the
in-progress operation in its long output format (e.g.,
rebasing, am, etc). This message gets its own slot in the
color table, even though it is not configurable. As a
result, if the user has set color.status.header to a
non-default value, this message will not match (and cannot
be made to match, as there is no config option).
It is probably more sane to just color it like the rest of
the text (i.e., just use color.status.header). This would
not allow users to customize the color of this message
independently, but it is not likely that anyone will want to
(and they cannot with the current code, anyway).
Signed-off-by: Jeff King p...@peff.net
---
wt-status.c | 3 +--
wt-status.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index c749267..c110cbc 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -24,7 +24,6 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
GIT_COLOR_GREEN, /* WT_STATUS_LOCAL_BRANCH */
GIT_COLOR_RED,/* WT_STATUS_REMOTE_BRANCH */
GIT_COLOR_NIL,/* WT_STATUS_ONBRANCH */
- GIT_COLOR_NORMAL, /* WT_STATUS_IN_PROGRESS */
};
static const char *color(int slot, struct wt_status *s)
@@ -931,7 +930,7 @@ static void show_bisect_in_progress(struct wt_status *s,
static void wt_status_print_state(struct wt_status *s)
{
- const char *state_color = color(WT_STATUS_IN_PROGRESS, s);
+ const char *state_color = color(WT_STATUS_HEADER, s);
struct wt_status_state state;
struct stat st;
diff --git a/wt-status.h b/wt-status.h
index c1066a0..f8fc58c 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -15,7 +15,6 @@ enum color_wt_status {
WT_STATUS_LOCAL_BRANCH,
WT_STATUS_REMOTE_BRANCH,
WT_STATUS_ONBRANCH,
- WT_STATUS_IN_PROGRESS,
WT_STATUS_MAXSLOT
};
--
1.7.10.5.40.gbbc17de
--
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 1/3] git p4: remove unused P4Submit interactive setting
p...@padd.com wrote on Thu, 05 Jul 2012 08:30 -0400: l...@diamand.org wrote on Thu, 05 Jul 2012 08:20 +0100: On 04/07/12 14:34, Pete Wyckoff wrote: The code is unused. Delete. I've used that non-interactive code path in the past, in the very early days of using it (setting interactive to false manually). The nice thing about it is that if you're using git-p4 for the very first time it lets you do the final submission to p4 by hand, without having to trust the script to do the right thing. Once I convinced myself that git-p4 was doing the right thing, I then stopped using it. Is it worth retaining, perhaps fixed so that it can be set on the command line and documented? Or just discard? My biggest complaint is that there's no way to enable the option. You have to edit the code to change self.interactive to False, as you pointed out. Then it doesn't help you with the submit message, and doesn't do the little details of cleaning up pure-copied files or changing the username for preserveUser. What you're doing makes sense, though, but maybe there's a cleaner way to provide that functionality. We could build the change then say type p4 submit -c ... if it looks good. Still doesn't handle the little details. We could spawn a shell to let them go inspect. We could try to implement a --continue option, and give them a chance to edit. I've got an upcoming series that changes the interaction loop on conflict, and makes it easier to do some interaction at each patch, possibly before applying too. Might make things easier. I did code up two new options to git p4 submit: --dry-run : just show the commits that would be submitted --prepare-p4-only : open/add, apply patch, but do not submit The latter prints a rather lengthy message about how to submit or revert the changes. It fills the role of self.interactive, hopefully. I'll send the patches out for review once the other in-flight changes have settled. -- Pete -- 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: What's cooking in git.git (Jul 2012, #04; Fri, 13)
Hi, Junio C Hamano wrote: Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. [...] [New Topics] * as/t4012-style-updates (2012-07-12) 7 commits - t4012: use 'printf' instead of 'dd' to generate a binary file - t4012: Re-indent test snippets - t4012: Make --shortstat test more robust - t4012: Break up pipe into serial redirections - t4012: Actually quote the sed script - t4012: Unquote git command fragment in test title - t4012: modernize style for quoting Should I wait for a reroll??? I see you did rewrite to tail -n 1 already, updated the short log and added the proposed 7th patch to this series. Good work! This only leaves addressing Zbigniew's comments to me. I would like to do so. It will just take a few days though, until I find the time. As the whole series is not that important I think it should be OK to wait a little longer, isn't it? [...] Alexander -- 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: Export from bzr / Import to git results in a deleted file re-appearing
Andreas Schwab sch...@linux-m68k.org writes: Jeff King p...@peff.net writes: On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote: If you run only the bzr half of your command and inspect the output, you will see that the file in question is mentioned twice. Once in a commit on refs/heads/master that renames into it from another file: R freeplane_plugin_spreadsheet/src/org/freeplane/plugin/spreadsheet/SpreadSheetUtils.java freeplane_plugin_formula/src/org/freeplane/plugin/formula/SpreadSheetUtils.java That same revision also removes it, but is uses the original name for the deletion (the bzr revision actually renames the containing directory). That's probably what confuses git fast-import. [...] The output contains these lines: R a/b b/b D a/b Changing the second line to D b/b fixes the bug. Yeah, I agree that is problematic. But I do not think it is a fast-import bug, but rather bogus output generated by bzr fast-export (I am not clear from what you wrote above if you are considering it a bug that fast-import is confused). It seems nonsensical to mention a file both as a rename source and as deleted in the same revision, and certainly I would not expect an importer to deduce a link between the second line and b/b. IMHO fast-import should raise an error in this case, like it does when you switch the lines. +1. Thanks very much for fixing bzr-fastexport! Also many thanks to Jeff for the analysis! Best Regards, -- Felix Natter -- 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
bzr-git: keep empty directories
hello, when converting a repo from bzr to git: mkdir freeplane-git1 cd freeplane-git1 git init . bzr fast-export --plain --export-marks=../marks.bzr ../trunk/ | git fast-import --export-marks=../marks.git git checkout Empty directories are not contained in the git working index. This is because of the --plain option, which Excludes metadata to maximise interoperability and thus does not support empty directories (http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html). However, when I use --no-plain (which according to above documentation exports empty directories), git cannot handle it: $ ./freeplane2git.sh Initialized empty Git repository in /home/felix/git/freeplane-git1/.git/ 15:56:09 Calculating the revisions to include ... 15:56:09 Starting export of 4290 revisions ... fatal: This version of fast-import does not support feature commit-properties. fast-import: dumping crash report to .git/fast_import_crash_3915 bzr: broken pipe I already tried to hack bzr-fastimport's exporter.py so that it does not emit commit properties but emits empty directories but i was not successful. So is there another way to preserve empty directories or shall I report a bug on bzr fast-export? Many thanks in advance! -- Felix Natter -- 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] t3910: give reason for skipping the test
t3910 is skipped for most users because it requires a filesystem which does automatic conversion between different utf-8 types. Currently, this results in a skipped test with no reason given. Use the skip_all mechanism from our test suite so that a reason for skipping the test is given to the user. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Alternatively, we could set a prerequisite and mark all tests with that. Since it's either or for the whole test skip_all seems more appropriate. In that case, we can also flatten the else branch, of course. The current patch is minimally invasive, though. t/t3910-mac-os-precompose.sh | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh index 88b7a20..fb7c7ff 100755 --- a/t/t3910-mac-os-precompose.sh +++ b/t/t3910-mac-os-precompose.sh @@ -22,8 +22,11 @@ esac rm -rf junk -if test $test_nfd +if ! test $test_nfd then + skip_all=filesystem does not convert utf-8 nfd to nfc + test_done +else # create more utf-8 variables Odiarnfc=`printf '\303\226'` Odiarnfd=`printf 'O\314\210'` @@ -157,8 +160,6 @@ then precomposeunicode=`git config core.precomposeunicode` test $precomposeunicode = true ' -else -say Skipping nfc/nfd tests fi test_done -- 1.7.11.2.381.gb6e9843 -- 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] t3910: give reason for skipping the test
On 14.07.12 19:52, Michael J Gruber wrote: t3910 is skipped for most users because it requires a filesystem which does automatic conversion between different utf-8 types. Currently, this results in a skipped test with no reason given. Use the skip_all mechanism from our test suite so that a reason for skipping the test is given to the user. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Alternatively, we could set a prerequisite and mark all tests with that. Since it's either or for the whole test skip_all seems more appropriate. In that case, we can also flatten the else branch, of course. The current patch is minimally invasive, though. Good point, thanks. If we spin that idea further, we could move the whole t3910 into t0050. That would be nice for all non Mac OS X users in a way that we save CPU time. We already detect unicode corruption in t0050. -- 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 maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems
On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder jrnie...@gmail.com wrote: Unfortunately, on big-endian architectures, if p is a pointer to unsigned int then current gcc assumes it is properly aligned and converts this construct to a 32-bit load. This patch seems to entirely depend on the location of the cast. And as far as I can tell, that workaround will in turn depend on just what gets inlined. My gut feel is that this makes the code uglier (the manual multiply by four being a prime example) while not really even addressing the problem. I think a much better approach would be to just mark the unsigned int data pointer as being unaligned, or add a get_unaligned() helper function (you have to do a structure member and mark the structure packed, I think - I don't think you can just mark an int pointer packed). Sure, that's compiler-dependent, but if a compiler does something like gcc apparently does, it had better support the notion of unaligned pointers. And then gcc might actually do the unaligned word read *optimally* on big-endian architectures, instead of that idiotic byte-at-a-time crap with shifting. Anyway, the whole noticed on alpha makes no sense, since alpha isn't even big-endian. So the commit log is insane and misleading too. Alpha is very much little-endian, but maybe gcc turns the thing into an unaligned load followed by a bswap. Linus -- 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 maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems
Linus Torvalds wrote: On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder jrnie...@gmail.com wrote: Unfortunately, on big-endian architectures, if p is a pointer to unsigned int then current gcc assumes it is properly aligned and converts this construct to a 32-bit load. This patch seems to entirely depend on the location of the cast. And as far as I can tell, that workaround will in turn depend on just what gets inlined. After the patch, what reason does gcc have to expect that 'block' is 32-bit aligned except when it is? The code (including the code I didn't touch) never casts from char * to int * except in get/put_be32 on arches that don't mind unaligned accesses. [...] Anyway, the whole noticed on alpha makes no sense, since alpha isn't even big-endian. So the commit log is insane and misleading too. Yes, true. Thanks for catching it. Jonathan -- 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 maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems
On Sat, Jul 14, 2012 at 12:50 PM, Jonathan Nieder jrnie...@gmail.com wrote: After the patch, what reason does gcc have to expect that 'block' is 32-bit aligned except when it is? The code (including the code I didn't touch) never casts from char * to int * except in get/put_be32 on arches that don't mind unaligned accesses. Ahh. I was looking at the cast you added: blk_SHA1_Block(ctx, (const unsigned char *) ctx-W); but I guess that if gcc inlines that and sees the original int type, it doesn't matter, because that *is* aligned. So it's ok, but please just make blk_SHA1_Block() take a const void * instead and that cast can go away. Linus -- 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: What's cooking in git.git (Jul 2012, #04; Fri, 13)
Alexander Strasser eclip...@gmx.net writes: As the whole series is not that important I think it should be OK to wait a little longer, isn't it? I thought the series queued in 'pu' was more or less done from my point of view, but wanted to know if you wanted to polish it further, as I prefer waiting for perfection in such a case. At the same time I do not want to wear the contributors out by unnecessary rerolls, so I was asking how you and others feel about the doneness of the series. Will wait updated patches from you. Thanks. -- 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: Support of '^' as alias for 'HEAD^'
Stefan Näwe stefan.na...@gmail.com writes: Zeeshan Ali (Khattak zeeshanak at gnome.org writes: Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. Or even '~1', '~3'. ^ has a problem when used with other things (does log ^^2 origin mean log HEAD^2..origin? Or log HEAD^^2 origin), so I do not think it would never fly as an abbreviated syntax. While I see your ~N much distasteful compared to ^, you still need to be a bit more careful when analysing the benefit of such an abbreviation. To shells used by many people, these mean tilde expansion ~N to refer to elements on the dirstack and you need to quote, perhaps like \~3. -- 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] status: default in-progress color to header color
Jeff King p...@peff.net writes: But given that this is not even configurable in the current code, I really wonder if it needs to have its own color at all. Do people really want to set the color of this message separately? Maybe we should just use WT_STATUS_HEADER instead. I would prefer that myself, but let's see if Matthieu's folks have opinions on this or something you and I overlooked. Thanks. -- 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: Support of '^' as alias for 'HEAD^'
Junio C Hamano gits...@pobox.com writes: Stefan Näwe stefan.na...@gmail.com writes: Zeeshan Ali (Khattak zeeshanak at gnome.org writes: Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. Or even '~1', '~3'. ^ has a problem when used with other things (does log ^^2 origin mean log HEAD^2..origin? Or log HEAD^^2 origin), so I do not think it would never fly as an abbreviated syntax. While I see your ~N much distasteful compared to ^, you still s/dist/less dist/; sorry ;-) need to be a bit more careful when analysing the benefit of such an abbreviation. To shells used by many people, these mean tilde expansion ~N to refer to elements on the dirstack and you need to quote, perhaps like \~3. -- 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: Support of '^' as alias for 'HEAD^'
On Sat, Jul 14, 2012 at 11:34 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Stefan Näwe stefan.na...@gmail.com writes: Zeeshan Ali (Khattak zeeshanak at gnome.org writes: Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. Or even '~1', '~3'. ^ has a problem when used with other things (does log ^^2 origin mean log HEAD^2..origin? Or log HEAD^^2 origin), so I do not think it would never fly as an abbreviated syntax. What about '^' and '^^' that I suggested? While I see your ~N much distasteful compared to ^, you still s/dist/less dist/; sorry ;-) Why? need to be a bit more careful when analysing the benefit of such an abbreviation. To shells used by many people, these mean tilde expansion ~N to refer to elements on the dirstack and you need to quote, perhaps like \~3. That would kinda beat the purpose I think, would be nice to just type 1 key rather than 3 to refer to HEAD (2 keys would still be good enough IMHO). -- Regards, Zeeshan Ali (Khattak) FSF member#5124 -- 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 maint-1.6.5 v2] block-sha1: avoid pointer conversion that violates alignment constraints
With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
access 32-bit chunks of memory one byte at a time on arches that
prefer that:
#define get_be32(p)( \
(*((unsigned char *)(p) + 0) 24) | \
(*((unsigned char *)(p) + 1) 16) | \
(*((unsigned char *)(p) + 2) 8) | \
(*((unsigned char *)(p) + 3) 0) )
The code previously accessed these values by just using htonl(*p).
Unfortunately, Michael noticed on an Alpha machine that git was using
plain 32-bit reads anyway. As soon as we convert a pointer to int *,
the compiler can assume that the object pointed to is correctly
aligned as an int (C99 section 6.3.2.3 pointer conversions
paragraph 7), and gcc takes full advantage by converting the get_be32
calls back to a load and bswap and producing a whole bunch of
unaligned access traps.
So we need to obey the alignment constraints even when only dealing
with pointers instead of actual values. Do so by changing the type
of 'data' to void *. This patch renames 'data' to 'block' at the same
time to make sure all references are updated to reflect the new type.
Reported-and-tested-by: Michael Cree mc...@orcon.net.nz
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Linus Torvalds wrote:
Anyway, the whole noticed on alpha makes no sense, since alpha isn't
even big-endian.
Thanks again for catching that. Here's a reroll.
block-sha1/sha1.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index d8934757..10fd94d1 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -100,7 +100,7 @@
* Where do we get the source from? The first 16 iterations get it from
* the input data, the next mix it from the 512-bit array.
*/
-#define SHA_SRC(t) get_be32(data + t)
+#define SHA_SRC(t) get_be32((unsigned char *) block + t*4)
#define SHA_MIX(t) SHA_ROL(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
#define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
@@ -114,7 +114,7 @@
#define T_40_59(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((BC)+(D(B^C))) ,
0x8f1bbcdc, A, B, C, D, E )
#define T_60_79(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (B^C^D) , 0xca62c1d6,
A, B, C, D, E )
-static void blk_SHA1_Block(blk_SHA_CTX *ctx, const unsigned int *data)
+static void blk_SHA1_Block(blk_SHA_CTX *ctx, const void *block)
{
unsigned int A,B,C,D,E;
unsigned int array[16];
@@ -125,7 +125,7 @@ static void blk_SHA1_Block(blk_SHA_CTX *ctx, const unsigned
int *data)
D = ctx-H[3];
E = ctx-H[4];
- /* Round 1 - iterations 0-16 take their input from 'data' */
+ /* Round 1 - iterations 0-16 take their input from 'block' */
T_0_15( 0, A, B, C, D, E);
T_0_15( 1, E, A, B, C, D);
T_0_15( 2, D, E, A, B, C);
--
1.7.10.4
--
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 maint-1.6.5 v2] block-sha1: avoid pointer conversion that violates alignment constraints
Looks good to me. I'd suggest doing the macro argument expansion in #define SHA_SRC(t) get_be32((unsigned char *) block + t*4) with parenthesis around 't', but that's a fairly independent thing. The old code didn't do that either. Linus -- 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: Support of '^' as alias for 'HEAD^'
Zeeshan Ali (Khattak) zeesha...@gnome.org writes: What about '^' and '^^' that I suggested? While I see your ~N much distasteful compared to ^, you still s/dist/less dist/; sorry ;-) Why? That ^^ is the most important reason why your ^ is the same as HEAD^ is flawed, and goes against my taste. Think what log ^^ origin would mean. Is it log ^HEAD^ origin? Is it log HEAD^^ origin? They mean totally different things. Compared to that, at least ~n does not have such ambiguity within the context of Git (having to quote is an ambiguity within the context of using Git with shells that support dirstacks in their tilde expansion). -- 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] block-sha1: put macro arguments in parentheses
't' is currently always a numeric constant, but it can't hurt to
prepare for the day that it becomes useful for a caller to pass in a
more complex expression.
Suggested-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
block-sha1/sha1.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 10fd94d1..6f885c43 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -100,8 +100,8 @@
* Where do we get the source from? The first 16 iterations get it from
* the input data, the next mix it from the 512-bit array.
*/
-#define SHA_SRC(t) get_be32((unsigned char *) block + t*4)
-#define SHA_MIX(t) SHA_ROL(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
+#define SHA_SRC(t) get_be32((unsigned char *) block + (t)*4)
+#define SHA_MIX(t) SHA_ROL(W((t)+13) ^ W((t)+8) ^ W((t)+2) ^ W(t), 1);
#define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
unsigned int TEMP = input(t); setW(t, TEMP); \
--
1.7.10.4
--
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] doc: A few minor copy edits.
- (glossary) the quotes around the Wikipedia URL prevented its linkification in frontends that support it; remove them - (manual) newer version (SHA-1) == following, older == preceding, not the other way around - trivial typo and wording fixes Signed-off-by: Štěpán Němec step...@gmail.com --- Documentation/git-merge.txt|2 +- Documentation/git-rebase.txt |2 +- Documentation/glossary-content.txt |2 +- Documentation/rev-list-options.txt |2 +- Documentation/user-manual.txt | 12 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 3ceefb8..20f9228 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -181,7 +181,7 @@ final result verbatim. When both sides made changes to the same area, however, git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area. -By default, git uses the same style as that is used by merge program +By default, git uses the same style as the one used by the merge program from the RCS suite to present such a conflicted hunk, like this: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 2d71e4b..2cab7e2 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -273,7 +273,7 @@ which makes little sense. Pass the strategy-option through to the merge strategy. This implies `--merge` and, if no strategy has been specified, `-s recursive`. Note the reversal of 'ours' and - 'theirs' as noted in above for the `-m` option. + 'theirs' as noted above for the `-m` option. -q:: --quiet:: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 3595b58..f928b57 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -117,7 +117,7 @@ to point at the new commit. [[def_ent]]ent:: Favorite synonym to def_tree-ish,tree-ish by some total geeks. See - `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth + http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth explanation. Avoid this term, not to confuse people. [[def_evil_merge]]evil merge:: diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 84e34b1..d9b2b5b 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -760,7 +760,7 @@ options may be given. See linkgit:git-diff-files[1] for more options. --cc:: - This flag implies the '-c' options and further compresses the + This flag implies the '-c' option and further compresses the patch output by omitting uninteresting hunks whose contents in the parents have only two variants and the merge result picks one of them without modification. diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 02ed566..03d95dc 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2870,7 +2870,7 @@ $ git fetch example You can also add a + to force the update each time: - -$ git config remote.example.fetch +master:ref/remotes/example/master +$ git config remote.example.fetch +master:refs/remotes/example/master - Don't do this unless you're sure you won't mind git fetch possibly @@ -2966,7 +2966,7 @@ As you can see, a commit is defined by: - a tree: The SHA-1 name of a tree object (as defined below), representing the contents of a directory at a certain point in time. -- parent(s): The SHA-1 name of some number of commits which represent the +- parent(s): The SHA-1 name(s) of some number of commits which represent the immediately previous step(s) in the history of the project. The example above has one parent; merge commits may have more than one. A commit with no parents is called a root commit, and @@ -3363,8 +3363,8 @@ Date: :100644 100644 oldsha... 4b9458b... M somedirectory/myfile -This tells you that the immediately preceding version of the file was -newsha, and that the immediately following version was oldsha. +This tells you that the immediately following version of the file was +newsha, and that the immediately preceding version was oldsha. You also know the commit messages that went with the change from oldsha to 4b9458b and with the change from 4b9458b to newsha. @@ -4035,8 +4035,8 @@ $ git ls-files --unmerged Each line of the `git ls-files --unmerged` output begins with the blob mode bits, blob SHA-1, 'stage number', and the filename. The 'stage number' is git's way to say which tree it -came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` -tree, and stage3 `$target` tree. +came from: stage 1
Re: Support of '^' as alias for 'HEAD^'
On Sun, Jul 15, 2012 at 12:26 AM, Junio C Hamano gits...@pobox.com wrote: Zeeshan Ali (Khattak) zeesha...@gnome.org writes: What about '^' and '^^' that I suggested? While I see your ~N much distasteful compared to ^, you still s/dist/less dist/; sorry ;-) Why? That ^^ is the most important reason why your ^ is the same as HEAD^ is flawed, and goes against my taste. Think what log ^^ origin would mean. Is it log ^HEAD^ origin? Is it log HEAD^^ origin? They mean totally different things. Sorry for my ignorance here but what does ^ *before* HEAD even mean? I tried playing with different combinations of ^ and HEAD here (e.g ^HEAD^, ^HEAD^^, ^HEAD^^^) with both log and show commands but git just silently returns on them. Is this ^ before HEAD actually used cause I have never seen/heard of that before. Google isn't able to help either. Compared to that, at least ~n does not have such ambiguity within the context of Git (having to quote is an ambiguity within the context of using Git with shells that support dirstacks in their tilde expansion). Don't know whats dirstacks support either but that I guess just means that bash (the shell I have always used) doesn't do that. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 -- 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: bzr-git: keep empty directories
On Sat, Jul 14, 2012 at 7:41 AM, Felix Natter fnat...@gmx.net wrote: hello, when converting a repo from bzr to git: mkdir freeplane-git1 cd freeplane-git1 git init . bzr fast-export --plain --export-marks=../marks.bzr ../trunk/ | git fast-import --export-marks=../marks.git git checkout Empty directories are not contained in the git working index. This is because of the --plain option, which Excludes metadata to maximise interoperability and thus does not support empty directories (http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html). However, when I use --no-plain (which according to above documentation exports empty directories), git cannot handle it: $ ./freeplane2git.sh Initialized empty Git repository in /home/felix/git/freeplane-git1/.git/ 15:56:09 Calculating the revisions to include ... 15:56:09 Starting export of 4290 revisions ... fatal: This version of fast-import does not support feature commit-properties. fast-import: dumping crash report to .git/fast_import_crash_3915 bzr: broken pipe I already tried to hack bzr-fastimport's exporter.py so that it does not emit commit properties but emits empty directories but i was not successful. So is there another way to preserve empty directories or shall I report a bug on bzr fast-export? Many thanks in advance! I would suggest hacking it to optionally not emit commit properties as step one. A later enhancement would be to optionally create directories with empty .gitignore files, or something similar. git really doesn't care about empty directories. -- David -- 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: bzr-git: keep empty directories
Perhaps having a file named something like: .git_foreign_scm_empty_dir or some shorter name. With the contents of the fast importer empty directory info put in there; If any book keeping is needed. It also looks like you strip out meta-data. perhaps a file like: .git_foreign_scm_metadata We could use the .git/config file format for storing the bookkeeping data. Steve On Jul 14, 2012, at 3:46 PM, David Aguilar wrote: On Sat, Jul 14, 2012 at 7:41 AM, Felix Natter fnat...@gmx.net wrote: hello, when converting a repo from bzr to git: mkdir freeplane-git1 cd freeplane-git1 git init . bzr fast-export --plain --export-marks=../marks.bzr ../trunk/ | git fast-import --export-marks=../marks.git git checkout Empty directories are not contained in the git working index. This is because of the --plain option, which Excludes metadata to maximise interoperability and thus does not support empty directories (http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html). However, when I use --no-plain (which according to above documentation exports empty directories), git cannot handle it: $ ./freeplane2git.sh Initialized empty Git repository in /home/felix/git/freeplane-git1/.git/ 15:56:09 Calculating the revisions to include ... 15:56:09 Starting export of 4290 revisions ... fatal: This version of fast-import does not support feature commit-properties. fast-import: dumping crash report to .git/fast_import_crash_3915 bzr: broken pipe I already tried to hack bzr-fastimport's exporter.py so that it does not emit commit properties but emits empty directories but i was not successful. So is there another way to preserve empty directories or shall I report a bug on bzr fast-export? Many thanks in advance! I would suggest hacking it to optionally not emit commit properties as step one. A later enhancement would be to optionally create directories with empty .gitignore files, or something similar. git really doesn't care about empty directories. -- David -- 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 -- 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: [RFC] Add a new email notification script to contrib
On 07/14/2012 11:46 AM, Stefan Näwe wrote: From: Michael Haggerty mhagger at alum.mit.edu Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. This script is derived from contrib/hooks/post-receive-mail, but has many differences, including: Looks interesting! Do you have a fork of git.git somewhere that contains the script? (I find it so much easier these days to simply fetch another repo instead of applying patches with 'git am'.) You can get it at github git://github.com/mhagger/git.git branch git-multimail. If you try it out, please let me know how it works for you. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
