* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Shawn O. Pearce @ 2007-12-31 22:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550712301106l133dd38btd2cc4be02159387d@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> Just for document the profiling I have uploaded a snapshot of
> KCachegrind profiling data on a run of git-log on the git tree:
>
> http://digilander.libero.it/mcostalba/callgrind_git_log1.png
>
> From there you can see that pretty.c and strbuf.c, after all the
> optimizations, account for less then 8% of total time.
> The biggest part is that 86.64% that is due almost entirely to zlib.
>
> In particular
>
> st = inflate(&stream, Z_FINISH);
>
> called from unpack_compressed_entry() in sha1_file.c accounts for 72%
> of total time.
That's one of the areas where packv4 was actually a reasonably
good gain. It was faster for packv4 to convert a dict based commit
or tree into the canonical raw format used by git than it was for
zlib inflate to decompress the very same data.
It wasn't a huge gain, but if I recall we were saving a good half
second on a 4 second "git log --raw >/dev/null" time. And that
was before we even tried to improve the tree walking APIs to
take advantage of the smaller (and easier to read) dict based
tree objects.
Linus already mentioned in another reply on this thread that the
inflate time may be all page faults. The savings we were seeing
from the dict based format may have simply been due to less page
faults; the dict based format was slightly smaller so we probably
got a lot more in disk cache at once.
--
Shawn.
^ permalink raw reply
* observing changes to a git repository
From: Brian Swetland @ 2007-12-31 22:28 UTC (permalink / raw)
To: git
Assuming I wanted to use a script (possibly run from cron) to observe
and report changes to a git repository (instead of running something
from the various hooks), does the following strategy seem workable:
- for each branch to observe, record the initial position of that
branch (sha1 commit id) -- call this Last
- periodically:
- grab the current head (call this Current)
- if it's the same as Last stop
- do a git log Current ^Last to observe what has happened since
we last noticed a change. report on these commits.
- Last = Current
If these branches can be updated such that history is rewritten (not
a concern in my particular case), I assume that for correctness you'd
have to make Last and Current actual branches (perhaps under
refs/heads/observer/... or whatever) to ensure that they don't get gc'd
out from under you.
Am I correct in believing that the above strategy will (if history
is not rewritten) correctly report all the commits between the last-
observed and current state of the branch? Even if history *is*
rewritten, I think (assuming I ensure things aren't gc'd) I'd get
still get it right.
If I'm tracking several branches which can be merged between, I might
want to keep track of which commits I've sent reports about if I don't
want to re-report commits when they're merged into another branch.
Brian
^ permalink raw reply
* Re: [PATCH] Fix race condition in t9119-git-svn-info.sh
From: Junio C Hamano @ 2007-12-31 22:29 UTC (permalink / raw)
To: David D. Kilzer; +Cc: Eric Wong, git
In-Reply-To: <1199131665-1633-1-git-send-email-ddkilzer@kilzer.net>
"David D. Kilzer" <ddkilzer@kilzer.net> writes:
> Changed the ptouch bash function to use the "Text Last Updated"
> date reported by 'svn info' when changing the modified time
> (mtime) of the file/symlink/directory in the git working
> directory. Previously it used the mtime of the item in the
> svn working directory, which caused the race condition.
>
> Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
> @@ -350,8 +355,8 @@ test_expect_success 'info unknown-symlink-directory' "
> cd svnwc &&
> ln -s unknown-directory unknown-symlink-directory &&
> cd .. &&
> - ptouch gitwc/unknown-symlink-directory \
> - svnwc/unknown-symlink-directory &&
> + ptouch svnwc/unknown-symlink-directory \
> + gitwc/unknown-symlink-directory &&
Hmph. Am I the only one who finds this repetition somewhat
disturbing?
^ permalink raw reply
* How to structure a project distributed with varyingly interdependent feature branches?
From: Matt McCutchen @ 2007-12-31 22:20 UTC (permalink / raw)
To: git
Dear git people,
The rsync source repository has recently been migrated from CVS to git
at my encouragement ( http://git.samba.org/rsync.git/ ), and I am trying
to figure out a better way to structure the repository (to propose to
the maintainer, Wayne Davison, or to use myself).
Rsync presents a unique challenge because it has a number of long-term
feature patches that are maintained and distributed with the main source
code. Furthermore, some of the patches depend on other patches. With
CVS, the patch files were just stored in the repository; this worked,
but browsing and developing the branched versions represented by the
patches required a lot of extra work. My hope now is to represent these
branches and their dependencies properly in git so that the git tools
handle them with the same elegance with which they handle everything
else.
The feature branches seem to present two fundamental problems:
1. How to properly represent the history of an individual branch and
update it when the trunk (or the branch on which it depends) changes.
Right now, Wayne updates the branch by rebasing; unfortunately, if the
trunk changes in such a way that one of the intermediate commits no
longer makes sense, it is impossible to update the branch while
preserving a record that the intermediate commit once existed. Merging
gives the right history and is very well-supported by the git tools, but
it has one fatal flaw: when a dependency on another branch is removed,
there is no way to undo the merge of the other branch. One can revert
the tree changes, but the other branch is still present in the ancestry,
which causes problems if the dependency is added again. It seems to me
that overcoming this flaw would require significant changes to git. Is
there some other workflow that does what is needed? Ideally "git blame"
would work correctly.
2. How to manage the large number of branches in a practical way. The
branch dependency information should be pullable from the main
repository to minimize the need for each developer to configure his/her
repository manually on initial cloning and when dependencies change.
Also, for an rsync release, it should be possible to tag the trunk and
all branches as a unit so that developers can ask questions like "which
branches changed between these two pre-releases?". My feeling is that
the solution will involve a taggable, pullable master tree object that
contains the trunk and branches as submodules and also some
metainformation (including the dependencies). However, special scripts
will then be needed to conveniently check out and update the submodules
using a single rsync source/build tree.
I'm sure the rsync project could make do without a fully general
solution for the feature branches, but it would be awesome (and a
testament to git's flexibility) if one existed. Also, Linux
distributions maintain packages with evolving and potentially
interdependent packages, and a good solution would make it possible for
them to do all their package maintenance and patching with git. Ubuntu
[1] and Fedora [2] are thinking about this. From my perspective, such a
setup would make modifying distribution packages much less painful.
[1] https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl
[2] http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=38716&start=0#forumpost175743
I would appreciate any ideas toward a solution.
I am not subscribed to the list (I once was but the traffic overwhelmed
me), so please be sure to CC me in replies.
Matt
^ permalink raw reply
* Re: On the many files problem
From: Linus Torvalds @ 2007-12-31 20:45 UTC (permalink / raw)
To: Yannick Gingras; +Cc: git
In-Reply-To: <873atjtbmu.fsf@enceladus.ygingras.net>
On Mon, 31 Dec 2007, Yannick Gingras wrote:
>
> This is really interesting and I would not have suspected it. But it
> begs the question: why does Git use the base-16 hash instead of the
> base-64 hash?
Because I was stupid, and I'ma lot more used to hex numbers than to
base-64.
Also, the way the original encoding worked, the SHA1 of the object was
actually the SHA1 of the *compressed* object, so you could verify the
integrity of the object writing by just doing a
sha1sum .git/objects/4f/a7491b073032b57c7fcf28c9222a5fa7b3a6b9
and it would return 4fa7491b073032b57c7fcf28c9222a5fa7b3a6b9 if everything
was good. That was a nice bonus in the first few days of git development,
when it all was a set of very low-level object routines hung together with
prayers and duct-tape.
So consider it historical. It wasn't worth fixing, since it became obvious
that the real fix would never be to try to make the individual files or
filenames smaller.
> > (Also, a "readdir() + stat()" loop will often get *much* worse access
> > patterns if you've mixed deletions and creations)
>
> This is something that will be interesting to benchmark later on. So,
> an application with a lot of turnaround, say a mail server, should
> delete and re-create the directories from time to time? I assume this
> is specific to some file system types.
This is an issue only for certain filesystems, and it's also an issue only
for certain access patterns.
A mail server, for example, will seldom *scan* the directory. It will just
open individual files by name. So it won't be hit by the "readdir+stat"
issue, unless you actually do a "ls -l".
(There are exceptions. Some mailbox formats use a file per email in a
directory. And yes, they tend to suck from a performance angle).
And you can avoid it. For example, on most unixish filesystems, you can
get better IO access patterns by doing the readdir() into an array, then
sorting it by inode number, and then doing the stat() in that order: that
*often* (but not always - there's no guarantee what the inode number
actually means) gives you better disk access patterns.
Linus
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Linus Torvalds @ 2007-12-31 20:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550712301404g273dd092w9b36b48d94ed1e70@mail.gmail.com>
On Sun, 30 Dec 2007, Marco Costalba wrote:
>
> Sorry to ask, but just out of curiosity, what were the reasons to
> choose zlib compression algorithm among the possible ones?
It's out there, it's common, it's stable, and it's very good "on average".
In other words, other compression methods tend to be worse. No, zlib isn't
perfect, but it was the obvious default choice for me (I've used it
before, we use it in the kernel, it's usually good enough), and I actually
expected the SHA1 to be the bigger expense.
Even today, I don't really know of a better compression choice, despite
now being more aware of how critical uncompression performance is.
And quite honestly I'm not really even sure that the performance downside
is entirely about zlib itself: I suspect a lot of the reason zlib shows up
in the profiles is that the source data is usually cold in the cache, so
it probably takes a lot of cache misses (it also will take all the page
faults!).
Quite possibly, the cache miss costs dominate over any algorithmic costs.
Linus
^ permalink raw reply
* [PATCH] Fix race condition in t9119-git-svn-info.sh
From: David D. Kilzer @ 2007-12-31 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git, David D. Kilzer
In-Reply-To: <377939.62541.qm@web52402.mail.re2.yahoo.com>
Changed the ptouch bash function to use the "Text Last Updated"
date reported by 'svn info' when changing the modified time
(mtime) of the file/symlink/directory in the git working
directory. Previously it used the mtime of the item in the
svn working directory, which caused the race condition.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
---
Ran a "burn-in" test by applying the "make test" patch in
<http://marc.info/?l=git&m=119452148511531&w=2> for over an hour
with no test failures:
$ set -e
$ while /usr/bin/true; do (make t/t9119-git-svn-info.sh); done
Also ran "make -C t full-svn-test" to verify the fix.
t/t9119-git-svn-info.sh | 35 ++++++++++++++++++++---------------
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/t/t9119-git-svn-info.sh b/t/t9119-git-svn-info.sh
index cc61911..6d9bec9 100755
--- a/t/t9119-git-svn-info.sh
+++ b/t/t9119-git-svn-info.sh
@@ -5,17 +5,22 @@
test_description='git-svn info'
. ./lib-git-svn.sh
-say 'skipping svn-info test (has a race undiagnosed yet)'
-test_done
ptouch() {
perl -w -e '
use strict;
+ use POSIX qw(mktime);
die "ptouch requires exactly 2 arguments" if @ARGV != 2;
- die "$ARGV[0] does not exist" if ! -e $ARGV[0];
- my @s = stat $ARGV[0];
- utime $s[8], $s[9], $ARGV[1];
- ' "$1" "$2"
+ my $text_last_updated = shift @ARGV;
+ my $git_file = shift @ARGV;
+ die "\"$git_file\" does not exist" if ! -e $git_file;
+ if ($text_last_updated
+ =~ /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/) {
+ my $mtime = mktime($6, $5, $4, $3, $2 - 1, $1 - 1900);
+ my $atime = $mtime;
+ utime $atime, $mtime, $git_file;
+ }
+ ' "`svn info $1 | grep '^Text Last Updated:'`" "$2"
}
test_expect_success 'setup repository and import' "
@@ -111,7 +116,7 @@ test_expect_success 'info added-file' "
git add added-file &&
cd .. &&
cp gitwc/added-file svnwc/added-file &&
- ptouch gitwc/added-file svnwc/added-file &&
+ ptouch svnwc/added-file gitwc/added-file &&
cd svnwc &&
svn add added-file > /dev/null &&
cd .. &&
@@ -127,7 +132,7 @@ test_expect_success 'info --url added-file' '
test_expect_success 'info added-directory' "
mkdir gitwc/added-directory svnwc/added-directory &&
- ptouch gitwc/added-directory svnwc/added-directory &&
+ ptouch svnwc/added-directory gitwc/added-directory &&
touch gitwc/added-directory/.placeholder &&
cd svnwc &&
svn add added-directory > /dev/null &&
@@ -156,7 +161,7 @@ test_expect_success 'info added-symlink-file' "
ln -s added-file added-symlink-file &&
svn add added-symlink-file > /dev/null &&
cd .. &&
- ptouch gitwc/added-symlink-file svnwc/added-symlink-file &&
+ ptouch svnwc/added-symlink-file gitwc/added-symlink-file &&
(cd svnwc; svn info added-symlink-file) \
> expected.info-added-symlink-file &&
(cd gitwc; git-svn info added-symlink-file) \
@@ -179,7 +184,7 @@ test_expect_success 'info added-symlink-directory' "
ln -s added-directory added-symlink-directory &&
svn add added-symlink-directory > /dev/null &&
cd .. &&
- ptouch gitwc/added-symlink-directory svnwc/added-symlink-directory &&
+ ptouch svnwc/added-symlink-directory gitwc/added-symlink-directory &&
(cd svnwc; svn info added-symlink-directory) \
> expected.info-added-symlink-directory &&
(cd gitwc; git-svn info added-symlink-directory) \
@@ -290,7 +295,7 @@ test_expect_success 'info --url symlink-directory (deleted)' '
test_expect_success 'info unknown-file' "
echo two > gitwc/unknown-file &&
cp gitwc/unknown-file svnwc/unknown-file &&
- ptouch gitwc/unknown-file svnwc/unknown-file &&
+ ptouch svnwc/unknown-file gitwc/unknown-file &&
(cd svnwc; svn info unknown-file) 2> expected.info-unknown-file &&
(cd gitwc; git-svn info unknown-file) 2> actual.info-unknown-file &&
git-diff expected.info-unknown-file actual.info-unknown-file
@@ -304,7 +309,7 @@ test_expect_success 'info --url unknown-file' '
test_expect_success 'info unknown-directory' "
mkdir gitwc/unknown-directory svnwc/unknown-directory &&
- ptouch gitwc/unknown-directory svnwc/unknown-directory &&
+ ptouch svnwc/unknown-directory gitwc/unknown-directory &&
touch gitwc/unknown-directory/.placeholder &&
(cd svnwc; svn info unknown-directory) \
2> expected.info-unknown-directory &&
@@ -327,7 +332,7 @@ test_expect_success 'info unknown-symlink-file' "
cd svnwc &&
ln -s unknown-file unknown-symlink-file &&
cd .. &&
- ptouch gitwc/unknown-symlink-file svnwc/unknown-symlink-file &&
+ ptouch svnwc/unknown-symlink-file gitwc/unknown-symlink-file &&
(cd svnwc; svn info unknown-symlink-file) \
2> expected.info-unknown-symlink-file &&
(cd gitwc; git-svn info unknown-symlink-file) \
@@ -350,8 +355,8 @@ test_expect_success 'info unknown-symlink-directory' "
cd svnwc &&
ln -s unknown-directory unknown-symlink-directory &&
cd .. &&
- ptouch gitwc/unknown-symlink-directory \
- svnwc/unknown-symlink-directory &&
+ ptouch svnwc/unknown-symlink-directory \
+ gitwc/unknown-symlink-directory &&
(cd svnwc; svn info unknown-symlink-directory) \
2> expected.info-unknown-symlink-directory &&
(cd gitwc; git-svn info unknown-symlink-directory) \
--
1.5.3.7
^ permalink raw reply related
* [PATCH] git-submodule: New subcommand 'summary' (1) - code framework
From: Ping Yin @ 2007-12-31 17:35 UTC (permalink / raw)
To: git; +Cc: Ping Yin
In-Reply-To: <1199122505-27478-1-git-send-email-pkufranky@gmail.com>
Following patches teach git-submodule a new subcommand 'summary' to show
commit summary of user-cared (i.e. checked out) submodules since a given
commit (default HEAD) of super project.
For a submodule in question, a series of commits will be shown as the path
from the src commit to the dst commit, where the src commit is from the given
super project commit, and the dst commit is from the index or working tree
(switched by --cached).
Following is an example of the output
# Submodules modifiled: sm1 sm2 sm3
#
# * sm1 354cd45...3f751e5:
# <one line message for C
# <one line message for B
# >one line message for D
# >one line message for E
#
# * sm2 5c8bfb5...000000:
# <one line message for F
#
# * sm3 354cd45...3f751e5:
# Warn: sm3 doesn't contain commit 354cd45
#
This superproject shown above has modified/deleted submodules sm1 to sm3.
sm1 has commit C as src (given commit or HEAD) and commit E as dst (index
or working tree) as following picture shows.
--A-->B-->C (in src:354cd45)
\
-->D-->E (in dst:3f751e5)
The 'Submodules modified' section for sm1 shows how to change sm1 from
src commit C to dst commit E: firstly backward (<) to commit A from
commit C via commit B, and then forward (>) to commit E via commit D.
Illustration for output of deleted sm2 is similar.
If the src/dst commit for a submodule is not found in the work tree (say
the submodule respository in the work tree), a warning will be issued.
sm3 falls into this case.
This patch just gives the framework. It just finds the submodules to be
shown as follows.
# Submodules modifiled: sm1 sm2 sm3
#
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
git-submodule.sh | 57 ++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..0e81484 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -4,7 +4,7 @@
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
+USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update|summary <commit>] [--] [<path>...]'
OPTIONS_SPEC=
. git-sh-setup
require_work_tree
@@ -255,7 +255,46 @@ set_name_rev () {
) )
test -z "$revname" || revname=" ($revname)"
}
+#
+# Show commit summary for submodules in index or working tree relative to the given commit
+#
+# If '--cached' is given, show summary between index and given commit,
+# or between working tree and given commit
+#
+# @ = [head counting commits from (default 'HEAD'),] requested paths (default to all)
+#
+modules_summary()
+{
+ cache_option=${cached:+--cached}
+
+ if rev=$(git rev-parse --verify "$1^0" 2>/dev/null)
+ then
+ head=$rev
+ shift
+ else
+ head=HEAD
+ fi
+ cwd=$(pwd)
+ cd_to_toplevel
+
+ # get modified modules which have been checked out (i.e. cared by user)
+ modules=$(git diff $cache_option --raw $head -- "$@" |
+ grep '^:160000\|:000000 160000' |
+ while read mod_src mod_dst sha1_src sha1_dst status name
+ do
+ test $status=D && echo "$name" && continue
+ GIT_DIR="$name/.git" git-rev-parse --git-dir >/dev/null 2>&1 &&
+ echo "$name"
+ done
+ )
+
+ # TODO: quote module names containing space or tab
+ test -n "$modules" &&
+ echo "# Submodules modified: "$modules &&
+ echo "#"
+ cd "$cwd"
+}
#
# List all submodules, prefixed with:
# - submodule not initialized
@@ -305,6 +344,9 @@ do
update)
update=1
;;
+ summary)
+ summary=1
+ ;;
status)
status=1
;;
@@ -345,17 +387,20 @@ case "$add,$branch" in
;;
esac
-case "$add,$init,$update,$status,$cached" in
-1,,,,)
+case "$add,$init,$update,$summary,$status,$cached" in
+1,,,,,)
module_add "$@"
;;
-,1,,,)
+,1,,,,)
modules_init "$@"
;;
-,,1,,)
+,,1,,,)
modules_update "$@"
;;
-,,,*,*)
+,,,1,,*)
+ modules_summary "$@"
+ ;;
+,,,,*,*)
modules_list "$@"
;;
*)
--
1.5.4.rc2.9.gf5146-dirty
^ permalink raw reply related
* [PATCH] git-submodule: New subcommand 'summary' (2) - hard work
From: Ping Yin @ 2007-12-31 17:35 UTC (permalink / raw)
To: git; +Cc: Ping Yin
In-Reply-To: <1199122505-27478-1-git-send-email-pkufranky@gmail.com>
This patch does the hard work of submodule summary and finally gives
output shown in last patch.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
git-submodule.sh | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0e81484..cccb539 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -292,7 +292,73 @@ modules_summary()
# TODO: quote module names containing space or tab
test -n "$modules" &&
echo "# Submodules modified: "$modules &&
- echo "#"
+ echo "#" &&
+ git diff $cache_option --raw $head -- $modules |
+ grep '^:160000\|:000000 160000' |
+ cut -c2- |
+ while read mod_src mod_dst sha1_src sha1_dst status name
+ do
+ sha1_dst=$(echo $sha1_dst | cut -c1-7)
+ sha1_src=$(echo $sha1_src | cut -c1-7)
+ check_dst=t
+ check_src=t
+ case $status in
+ D)
+ check_dst=
+ ;;
+ A)
+ check_src=
+ ;;
+ esac
+
+ (
+ errmsg=
+ unfound_src=
+ unfound_dst=
+
+ test -z "$check_src" ||
+ GIT_DIR="$name/.git" git-rev-parse $sha1_src >&/dev/null ||
+ unfound_src=t
+
+ test -z "$check_dst" ||
+ GIT_DIR="$name/.git" git-rev-parse $sha1_dst >&/dev/null ||
+ unfound_dst=t
+
+ case "$unfound_src,$unfound_dst" in
+ t,)
+ errmsg=" Warn: $name doesn't contain commit $sha1_src"
+ ;;
+ ,t)
+ errmsg=" Warn: $name doesn't contain commit $sha1_dst"
+ ;;
+ t,t)
+ errmsg=" Warn: $name doesn't contain commits $sha1_src and $sha1_dst"
+ ;;
+ *)
+ left=
+ right=
+ test -n "$check_src" &&
+ left=$(GIT_DIR="$name/.git" git log --pretty=format:" <%s" \
+ ${check_dst:+$sha1_dst..}$sha1_src 2>/dev/null)
+
+ test -n "$check_dst" &&
+ right=$(GIT_DIR="$name/.git" git log --reverse --pretty=format:" >%s" \
+ ${check_src:+$sha1_src..}$sha1_dst 2>/dev/null)
+ ;;
+ esac
+
+ echo "* $name $sha1_src...$sha1_dst:"
+ if test -n "$errmsg"
+ then
+ echo "$errmsg"
+ else
+ test -n "$left" && echo "$left"
+ test -n "$right" && echo "$right"
+ fi
+ echo
+ ) | sed 's/^/# /'
+ done
+
cd "$cwd"
}
#
--
1.5.4.rc2.9.gf5146-dirty
^ permalink raw reply related
* [PATCH] git-submodule: New subcommand 'summary' (3) - limit summary size
From: Ping Yin @ 2007-12-31 17:35 UTC (permalink / raw)
To: git; +Cc: Ping Yin
In-Reply-To: <1199122505-27478-1-git-send-email-pkufranky@gmail.com>
This patches teaches git-submodule an option '--summary-limit|-n <number>'
to limit number of commits for the summary. Number 0 will disable summary
and minus number will not limit the summary size.
For beauty and clarification, the last commit for each section (backward
and forward) will always be shown disregarding the given limit. So actual
summary size may be greater than the given limit.
In the same super project of these patch series, 'git submodule -n 2' and
'git submodule -n 3' will both show
# Submodules modifiled: sm1 sm2 sm3
#
# * sm1 354cd45...3f751e5:
# <one line message for C
# <one line message for B
# >... (1 more)
# >one line message for E
#
# * sm2 5c8bfb5...000000:
# <one line message for F
#
# * sm3 354cd45...3f751e5:
# Warn: sm3 doesn't contain commit 354cd45
#
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
git-submodule.sh | 40 +++++++++++++++++++++++++++++++++++++---
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index cccb539..58d0243 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -4,7 +4,8 @@
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update|summary <commit>] [--] [<path>...]'
+USAGE="[--quiet] [--cached] [-n|--summary-limit <number>] \
+[add <repo> [-b branch]|status|init|update|summary <commit>] [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
require_work_tree
@@ -16,6 +17,7 @@ update=
status=
quiet=
cached=
+summary_limit=
#
# print stuff on stdout unless -q was specified
@@ -265,6 +267,10 @@ set_name_rev () {
#
modules_summary()
{
+ summary_limit=${summary_limit:-1000000}
+ summary_limit=$((summary_limit<0?1000000:summary_limit))
+ test $summary_limit = 0 && return
+
cache_option=${cached:+--cached}
if rev=$(git rev-parse --verify "$1^0" 2>/dev/null)
@@ -352,8 +358,29 @@ modules_summary()
then
echo "$errmsg"
else
- test -n "$left" && echo "$left"
- test -n "$right" && echo "$right"
+ lc0=0
+ rc0=0
+ test -n "$left" && lc0=$(echo "$left" | wc -l)
+ test -n "$right" && rc0=$(echo "$right" | wc -l)
+ lc=$((lc0<summary_limit?lc0:summary_limit))
+ rc=$((summary_limit>lc?summary_limit-lc:1))
+ rc=$((rc<rc0?rc:rc0))
+
+ if test -n "$left"
+ then
+ skip=$((lc0-lc))
+ echo "$left" | head -$((lc-1))
+ test $skip != 0 && echo " <... ($skip more)"
+ echo "$left" | tail -1
+ fi
+
+ if test -n "$right"
+ then
+ skip=$((rc0-rc))
+ echo "$right" | head -$((rc-1))
+ test $skip != 0 && echo " >... ($skip more)"
+ echo "$right" | tail -1
+ fi
fi
echo
) | sed 's/^/# /'
@@ -430,6 +457,13 @@ do
--cached)
cached=1
;;
+ -n|--summary-limit)
+ if [ -z "$2" ]; then
+ usage
+ fi
+ summary_limit="$2"
+ shift
+ ;;
--)
break
;;
--
1.5.4.rc2.9.gf5146-dirty
^ permalink raw reply related
* [PATCH] git-submodule: New subcommand 'summary'
From: Ping Yin @ 2007-12-31 17:35 UTC (permalink / raw)
To: git
The patch series ( 3 in total) teach git-submodule a new subcommand 'summary'.
PATCH 1 introduces the code framework.
PATCH 2 does the real work for summary.
PATCH 3 teaches a new option '--summary-limit|-n'.
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Marco Costalba @ 2007-12-31 18:07 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Filippo Zangheri, Linux Kernel Development, Git Mailing List
In-Reply-To: <47792B3E.60509@panasas.com>
On Dec 31, 2007 6:47 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On Mon, Dec 31 2007 at 13:58 +0200, "Marco Costalba" <mcostalba@gmail.com> wrote:
> > On Dec 31, 2007 11:59 AM, Filippo Zangheri <filippo.zangheri@yahoo.it> wrote:
> >> Hi,
> >>
> >> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but `make` gave me errors.
> >
> > Yes, you need qmake of Qt4 not the Qt3 one.
> >
> <snip>
>
> A Theoretical question.
> Is it possible to compile Qt4 app all statically linked and run it on a Qt3 based KDE
> machine. Some thing like the windows installation, where every thing is self-contained?
>
It's also very practical...I have _only_ KDE 3 installed, not KDE 4 ;-)
I have both Qt4 and Qt3 development (shared) libraries installed and
there is absolutely no compatibility problem, the only thing you have
to remember is when running
qmake qgit.pro
the first time, you need to be sure is the Qt4 qmake, not the Qt3.
Because I have Qt3 qmake in path, not the Qt4 one, I need to
explicitly give the whole path the first time I configure the sources,
something like
/usr/lib/qt4/bin/qmake qgit.pro
Then no other settings are needed, when you call make, the Makefiles
are already built by qmake to search for the correct libraries.
Hope this helps...
Marco
^ permalink raw reply
* Re: How to bypass the post-commit hook?
From: Ping Yin @ 2007-12-31 17:53 UTC (permalink / raw)
To: Jan Hudec; +Cc: Git Mailing List
In-Reply-To: <20071231170532.GB9214@efreet.light.src>
On Jan 1, 2008 1:05 AM, Jan Hudec <bulb@ucw.cz> wrote:
> On Mon, Dec 31, 2007 at 21:26:21 +0800, Ping Yin wrote:
> > On Dec 31, 2007 6:55 PM, Jan Hudec <bulb@ucw.cz> wrote:
> > > Note, that you can -- and should -- add the foo.css to the commit. But the
> > > file might contain other changes in tree, that are not about to be commited,
> > > so prefered way would be to get the content from the index, modify that and
> > > update the index manually (with git update-index).
> >
> > If pre-commit has modified files to be commited, it will abort this
> > commit and give a message to direct the user to commit again
> > with/without the changed content.
> >
> > AFAIK, git add -i can add selected chunk to the index. As you said,
> > can git-update-index also do this job?
>
> git update-index is the underlying plumbing for git add/git rm.
>
> However, you should change foo.css in index even if the working tree copy
> does not match it and is not selected for commit. Only way I see to do that
> is to prepare a patch and apply it to both the working tree (git apply) and
> to the index (git apply --cached).
>
A little complicated-:). So my way is to abort the commit if
pre-commit actually modified the files ( the working tree, not the
index) to be commited, then 'git add -i' to add the changes
introduced just by the pre-commit and 'git commit' again.
--
Ping Yin
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Boaz Harrosh @ 2007-12-31 17:47 UTC (permalink / raw)
To: Marco Costalba
Cc: Filippo Zangheri, Linux Kernel Development, Git Mailing List
In-Reply-To: <e5bfff550712310358g347d883fm9866f328f24e3ad0@mail.gmail.com>
On Mon, Dec 31 2007 at 13:58 +0200, "Marco Costalba" <mcostalba@gmail.com> wrote:
> On Dec 31, 2007 11:59 AM, Filippo Zangheri <filippo.zangheri@yahoo.it> wrote:
>> Hi,
>>
>> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but `make` gave me errors.
>
> Yes, you need qmake of Qt4 not the Qt3 one.
>
<snip>
A Theoretical question.
Is it possible to compile Qt4 app all statically linked and run it on a Qt3 based KDE
machine. Some thing like the windows installation, where every thing is self-contained?
Thanks
Boaz
^ permalink raw reply
* git config problem with strange config files
From: Peter Oberndorfer @ 2007-12-31 17:47 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Hi,
In case of a strange .git/config file "git config key value" can create a
bogus config entry, where one old value is wrong and the new value resides in
the wrong section until the config file is fixed up by hand
The attached test config has a trailing tab in the last line
and no newline after that.
When git config is run the new section name is placed directly after the
trailing tab, which corrupts the old value.
To reproduce the error do the following:
mkdir git_test_config && cd git_test_config
git init
<copy the attached config file to .git/config>
git config section2.key bar
git config --get section2.key
-> returns nothing
git config --get section.key
-> foo [section2]
-> error: More than one value for the key section.key: bar
i tried to make a test out of this but i failed to create a config file
without a trailing newline using here documents :-(
Tested using v1.5.4.rc2 and v1.5.4-rc2-6-gab11903
Greetings Peter
[-- Attachment #2: config --]
[-- Type: text/plain, Size: 21 bytes --]
[section]
key = foo
[-- Attachment #3: config_bogus --]
[-- Type: text/plain, Size: 43 bytes --]
[section]
key = foo [section2]
key = bar
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Junio C Hamano @ 2007-12-31 17:31 UTC (permalink / raw)
To: Stefan Richter
Cc: Jan Engelhardt, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <4778D1CD.4020001@s5r6.in-berlin.de>
Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> Jan Engelhardt wrote:
>>> http://linux.yyz.us/git-howto.html
>>
>> It says
>>
>> """Don't forget to download tags from time to time.
>>
>> git pull only downloads sha1-indexed object data, and the requested
>> remote head. This misses updates to the .git/refs/tags/ and
>> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>>
>> But when I do git pull on a simple tracking tree (e.g. git-clone
>> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
>
> A while ago the default behavior of git pull was changed to fetch all
> tags which point to objects that can be reached from any of the tracked
> heads.
>
> Old behaviour: Option --tags was needed to fetch tags at all. Current
> behavior: Option --tags forces to download all tags and the objects
> they point to. Option --no-tags works like the old default behavior.
>
> Readers of Kernel Hackers' Guide to git will most certainly have a
> recent enough version of git so that the "download_tags" subsection can
> be removed without replacement.
All correct.
That "A while ago" is quite a while ago, though. IIRC it was
added very early in 2006, which is eons ago in git timescale.
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Graham Barr @ 2007-12-31 16:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Grégoire Barbier, git
In-Reply-To: <alpine.LNX.1.00.0712302145500.13593@iabervon.org>
Daniel Barkalow wrote:
> On Sun, 30 Dec 2007, Grégoire Barbier wrote:
>> I'm using Git for a rather short time but enough to fall in love with it. For
>> a few days I'm trying to use it over webdav, that is over http/https with
>> write (push) access. As for me, the main rationale to use http(s) rather than
>> git or ssh is to get through corporate firewalls, otherwise I would probably
>> not bother with webdav.
> In general, we've been able to either get through firewalls with ssh or
> it's all in the same VPN. So it's kind of unloved at this point. People
> poke at it occasionally, but mostly in the context of other fixes, I
> think.
If you have a http proxy that you can use, the you can use ssh via that with
something like corkscrew. http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https
A simple shell script wrapper around ssh to detect when you are behind a firewall
can inject the ProxyCommand into the command line arguments with -o
Graham.
^ permalink raw reply
* Re: How to bypass the post-commit hook?
From: Jan Hudec @ 2007-12-31 17:05 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320712310526l2b801ed7xc52b7aae2d65048e@mail.gmail.com>
On Mon, Dec 31, 2007 at 21:26:21 +0800, Ping Yin wrote:
> On Dec 31, 2007 6:55 PM, Jan Hudec <bulb@ucw.cz> wrote:
> > Note, that you can -- and should -- add the foo.css to the commit. But the
> > file might contain other changes in tree, that are not about to be commited,
> > so prefered way would be to get the content from the index, modify that and
> > update the index manually (with git update-index).
>
> If pre-commit has modified files to be commited, it will abort this
> commit and give a message to direct the user to commit again
> with/without the changed content.
>
> AFAIK, git add -i can add selected chunk to the index. As you said,
> can git-update-index also do this job?
git update-index is the underlying plumbing for git add/git rm.
However, you should change foo.css in index even if the working tree copy
does not match it and is not selected for commit. Only way I see to do that
is to prepare a patch and apply it to both the working tree (git apply) and
to the index (git apply --cached).
It will probably work for you without such finesse, you will just have to be
aware of it's quirks.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] Documentation/user-manual.txt: fix typo
From: J. Bruce Fields @ 2007-12-31 16:28 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: gitster, git
In-Reply-To: <1199107895-25950-1-git-send-email-hendeby@isy.liu.se>
On Mon, Dec 31, 2007 at 02:31:35PM +0100, Gustaf Hendeby wrote:
> Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
> ---
>
> I didn't see this one in the latest patches added to v1.5.4-rc2 so I
> guess it was forgotten, or just dropped because it seems I forgot to
> sign it the last time. (Sorry about that, it should teach me not to
> do anything important at 4 in the morning...) I think the patch is
> obviously correct so I'm resending.
Yep, thanks! Applied and pushed out to
git://linux-nfs.org/~bfields/git.git maint
--b.
commit 57283291b55cdc4ab726231073450d185beb361a
Author: Gustaf Hendeby <hendeby@isy.liu.se>
Date: Mon Dec 31 14:31:35 2007 +0100
Documentation/user-manual.txt: fix typo
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
commit f18b1c55e5b7478524c15685cd643555fc919f3f
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Fri Dec 21 19:57:16 2007 -0500
Documentation: fix remote.<name>.skipDefaultUpdate description
Fix the subcommand name.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
^ permalink raw reply
* [PATCH] Documentation/user-manual.txt: fix typo
From: Gustaf Hendeby @ 2007-12-31 13:31 UTC (permalink / raw)
To: gitster; +Cc: git, Gustaf Hendeby
In-Reply-To: <1198921945-25616-1-git-send-email-hendeby@isy.liu.se>
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
I didn't see this one in the latest patches added to v1.5.4-rc2 so I
guess it was forgotten, or just dropped because it seems I forgot to
sign it the last time. (Sorry about that, it should teach me not to
do anything important at 4 in the morning...) I think the patch is
obviously correct so I'm resending.
/Gustaf
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f2b4206..3f552e9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -74,7 +74,7 @@ version is called a <<def_commit,commit>>.
Those snapshots aren't necessarily all arranged in a single line from
oldest to newest; instead, work may simultaneously proceed along
-parallel lines of development, called <def_branch,branches>>, which may
+parallel lines of development, called <<def_branch,branches>>, which may
merge and diverge.
A single git repository can track development on multiple branches. It
--
1.5.4.rc2.8.g41c7c6
^ permalink raw reply related
* Re: How to bypass the post-commit hook?
From: Ping Yin @ 2007-12-31 13:26 UTC (permalink / raw)
To: Jan Hudec; +Cc: Git Mailing List
In-Reply-To: <20071231105514.GA9214@efreet.light.src>
On Dec 31, 2007 6:55 PM, Jan Hudec <bulb@ucw.cz> wrote:
> On Mon, Dec 31, 2007 at 18:22:37 +0800, Ping Yin wrote:
> > On Dec 31, 2007 5:31 PM, Jan Hudec <bulb@ucw.cz> wrote:
> > > On Mon, Dec 31, 2007 at 13:08:05 +0800, Ping Yin wrote:
> > > Note, that while you don't know the commit sha1 before the commit, you do
> > > know the *blob* sha1s. So you can do this change in pre-commit hook.
> >
> > I chose post-commit because i used commit sha1 instead of blob sha1 as
> > file version in the first time, and now pre-commit seems better. One
> > more question, I use 'git ls-files' to fetch the blob sha1, so is the
> > got sha1 the same when pre-commit and post-commit?
>
> Yes, it should be.
>
Good news. So pre-commit is actually the right choice.
>
> Note, that you can -- and should -- add the foo.css to the commit. But the
> file might contain other changes in tree, that are not about to be commited,
> so prefered way would be to get the content from the index, modify that and
> update the index manually (with git update-index).
If pre-commit has modified files to be commited, it will abort this
commit and give a message to direct the user to commit again
with/without the changed content.
AFAIK, git add -i can add selected chunk to the index. As you said,
can git-update-index also do this job?
--
Ping Yin
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Marco Costalba @ 2007-12-31 11:58 UTC (permalink / raw)
To: Filippo Zangheri; +Cc: Linux Kernel Development, Git Mailing List
In-Reply-To: <4778CB78.2010906@yahoo.it>
On Dec 31, 2007 11:59 AM, Filippo Zangheri <filippo.zangheri@yahoo.it> wrote:
>
> Hi,
>
> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but `make` gave me errors.
Yes, you need qmake of Qt4 not the Qt3 one.
> Afterwards I deleted src/Makefile, ran `qmake-qt4 qgit.pro` and `make` starts compiling some files but the process ends with other errors.
> This is the command line:
>
> filippo@master:/usr/src/git/qgit$ make
> cd src && make -f Makefile
> make[1]: Entering directory `/usr/src/git/qgit/src'
> make -f Makefile.Release
> make[2]: Entering directory `/usr/src/git/qgit/src'
> g++ -c -pipe -O2 -g3 -O2 -Wno-non-virtual-dtor -Wno-long-long -pedantic -Wconversion -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I../../../../share/qt4/mkspecs/linux-g++ -I. -I../../../../include/qt4/QtCore -I../../../../include/qt4/QtCore -I../../../../include/qt4/QtGui -I../../../../include/qt4/QtGui -I../../../../include/qt4 -I../src -I../build -I../build -o ../build/customactionimpl.o customactionimpl.cpp
> make[2]: Leaving directory `/usr/src/git/qgit/src'
> make[1]: Leaving directory `/usr/src/git/qgit/src'
> ../build/ui_customaction.h: In member function 'void Ui_CustomActionBase::setupUi(QWidget*)':
> ../build/ui_customaction.h:68: error: 'class QHBoxLayout' has no member named 'setLeftMargin'
> ../build/ui_customaction.h:69: error: 'class QHBoxLayout' has no member named 'setTopMargin'
This is because you need at least Qt 4.3 as written in the README.
>
>
>
> I'm running Debian Etch 4.0 with vanilla kernel version 2.6.23.1 and I have the following packages installed:
>
> filippo@master:/usr/src/git/qgit$ dpkg -l | grep qt4
> ii libqt4-core 4.2.1-2+etch1 Qt 4 core non-GUI functionality runtime library
> ii libqt4-dev 4.2.1-2+etch1 Qt 4 development files
> ii libqt4-gui 4.2.1-2+etch1 Qt 4 core GUI functionality runtime library
> ii libqt4-qt3support 4.2.1-2+etch1 Qt 3 compatibility library for Qt 4
> ii libqt4-sql 4.2.1-2+etch1 Qt 4 SQL database module
> ii qt4-dev-tools 4.2.1-2+etch1 Qt 4 development tools
>
>
> what am I doing wrong?
>
Please upgrade to Qt 4.3 and everything will be OK ;-)
Happy new year
Marco
^ permalink raw reply
* Fwd: qgit 2.1 questions about range selection
From: Marco Costalba @ 2007-12-31 11:53 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <e5bfff550712310352j3245511chbbd301d35e09204b@mail.gmail.com>
---------- Forwarded message ----------
From: Marco Costalba <mcostalba@gmail.com>
Date: Dec 31, 2007 12:52 PM
Subject: Re: qgit 2.1 questions about range selection
To: Steffen Prohaska <prohaska@zib.de>
On Dec 31, 2007 11:42 AM, Steffen Prohaska <prohaska@zib.de> wrote:
> Hello Marco,
Hi Steffen,
I hope you don't mind if I forward this also to the git list.
Your questions are interesting, and I think could be useful also for
other people.
>
> Here is a first impressions and some questions about the range
> selection, which I find pretty hard to understand.
>
> - The "Range select" dialog.
> * It is displayed upon startup or when I open a new
> repository. But I haven't found a way to access "Range
> select" from the menus. I'd expected to find it as
> "View > Range select".
Currently the only way is to open (with File->open or "open folder"
the tool button or with File->last opened repos list ) again the
_same_ repository. I understand is not the best way. Your suggestion
"View->range select" it seems a better idea.
> * The dialog's "Top:" and "Bottom:" drop downs apparently contain
> tags or "HEAD". Why can't I select a specific branch? I'd
> expected this here, too.
You can write anything you want in top and bottom fields, they are not
read-only, so you can write a branch name or anything understandable
by 'git log'. You can also clear one filed, as example the bottom
field to have all the revisions until the initial one.
> * The dialog's "Top:" and "Bottom:" fields are reset to a
> default each time the dialog opens. Why aren't the last settings
> preserved?
Mmmmm, why not? this goes in the same playfield of "View->Range select", thanks.
> * I find the toggles "Working dir" hard to understand. Why
> not always showing the working dir? Why not displaying
> differences to the index (as gitk does with the "green"
> commit)?
Well differences in the index _are_ displayed with an "orange" commit
(from a long time ago also, much more then gitk BTW). The reason is
not selected by default is that on big repos, as Linux, checking for
working dir changed files takes very long and is not useful for people
that just wants to pull Linux and take a look atthe updates. Anyhow
you can always toggle this directly right clicking anywhere in the
main revision list. A pop up menu appears and "Check for modified
files" is the first entry.
> * Similar for the toggles "All branches", "Whole history".
> Maybe "All branches" could be included in the "Top:" drop down
> and "Whole history" could be included in the "Bottom:" drop down.
>
There should be some tooltips that help here. But again Top and Bottom
are only range delimiters, what happens is that if you write A in the
top field and B in the bottom field git log is called with : git log
A..B
> - The parameters of the current range selection are not obvious.
> After closing the "Range select" dialog the history is
> displayed. But where can I see the parameters of the
> selection? I'd have expected to see an indication which
> branches, tags, whole history, ... I selected. Indications
> of this are scattered over the GUI. For example, a filter can
> be toggled on in the tool menu bar and is greyed out if
> activated. Or "FILTER ON" may be displayed in the window
> title.
>
Well there is already a "Filter ON" but is for a more advanced feature
then range select. Simply, from main list, press key 't' to show tree
view, then select some files/directories (multi selection is allowed),
then press the magic wand toolbar button: that's the FILTER ON (and
you see on the window caption BTW)
> - "Toggle filter by tree" seems to switch to "--all". I see
> more commits than I expect. I'd have expected that this
> toggle adds a boolean "and" to the selection; that is the
> current view would be restricted to commits touching the
> selected path.
>
Mmmmm, if this is the case it's a bug. Thanks I will investigate.
> Maybe the range selection could be unified in the following way.
> The selection is represented as multiple lines; each line
> representing part of the selection parameters. All lines together
> act as a boolean expression selecting the commits. Each line
> contains drop down boxes and text fields (or other GUI elements).
> The selection filter is displayed below the tool bar and the
> tab containing the "Rev list"; or it should be included in the
> "Rev list". For example, the following lines would select the
> commits on branch pu, not on master, touching file help.c
>
> - Selection: [label]
> - Branch [drop down], origin/pu [drop down],
> - Not on branch [drop down], origin/master [drop down],
> - File [drop down], help.c [text field],
>
> Each line contains "-", "+" buttons to remove this line or add a
> line below. The very first line has a button "+" to add a line
> at the very bottom. I attached a snapshot of the Mac OS X
> Smartfolder GUI to illustrate this.
>
>
That's nice!
Currently you can use the "Additional options" field at the bottom of
range select to write a free text that will be pasted directly to the
git log command line arguments.
>
>
> Btw, is the git mailing list the right forum to discuss such
> suggestions?
>
> If so, feel free to reply with CC to git@vger.kernel.org.
>
Already done ;-)
Thanks
Marco
^ permalink raw reply
* [MinGW PATCH] spawn*: default extension to .exe if none is given
From: Nguyễn Thái Ngọc Duy @ 2007-12-31 11:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
This is the behavior of spawn* (or at least Wine source does it).
CreateProcess() does not have such assumption.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
compat/mingw.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 8bbe21b..dc54303 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -533,8 +533,9 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
- struct strbuf envblk, args;
+ struct strbuf envblk, args, newcmd;
unsigned flags;
+ const char *basename;
BOOL ret;
/* Determine whether or not we are associated to a console */
@@ -565,6 +566,21 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
si.hStdOutput = (HANDLE) _get_osfhandle(1);
si.hStdError = (HANDLE) _get_osfhandle(2);
+ /* Assume .exe if there is no extension */
+ strbuf_init(&newcmd, 0);
+ basename = strrchr(cmd, '/');
+ if (strrchr(cmd, '\\') > basename)
+ basename = strrchr(cmd, '\\');
+ if (basename)
+ basename ++;
+ else
+ basename = cmd;
+ if (!strchr(basename, '.')) {
+ strbuf_addstr(&newcmd, cmd);
+ strbuf_addstr(&newcmd, ".exe");
+ cmd = newcmd.buf;
+ }
+
/* concatenate argv, quoting args as we go */
strbuf_init(&args, 0);
if (prepend_cmd) {
@@ -609,6 +625,7 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
if (env)
strbuf_release(&envblk);
strbuf_release(&args);
+ strbuf_release(&newcmd);
if (!ret) {
errno = ENOENT;
--
1.5.4.rc2.1097.gb6e0d
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Stefan Richter @ 2007-12-31 11:26 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712310349260.2093@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
>> http://linux.yyz.us/git-howto.html
>
> It says
>
> """Don't forget to download tags from time to time.
>
> git pull only downloads sha1-indexed object data, and the requested
> remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>
> But when I do git pull on a simple tracking tree (e.g. git-clone
> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
A while ago the default behavior of git pull was changed to fetch all
tags which point to objects that can be reached from any of the tracked
heads.
Old behaviour: Option --tags was needed to fetch tags at all. Current
behavior: Option --tags forces to download all tags and the objects
they point to. Option --no-tags works like the old default behavior.
Readers of Kernel Hackers' Guide to git will most certainly have a
recent enough version of git so that the "download_tags" subsection can
be removed without replacement.
--
Stefan Richter
-=====-=-=== ==-- =====
http://arcgraph.de/sr/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox