* [StGit PATCH] Added basic bash completion script for StGit.
From: ted @ 2009-01-19 22:57 UTC (permalink / raw)
To: catalin.marinas; +Cc: git, Ted Pavlic
From: Ted Pavlic <ted@tedpavlic.com>
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/stg-completion.bash | 106 ++++++++++++++++++++++++++++++++
1 files changed, 106 insertions(+), 0 deletions(-)
create mode 100755 contrib/completion/stg-completion.bash
diff --git a/contrib/completion/stg-completion.bash b/contrib/completion/stg-completion.bash
new file mode 100755
index 0000000..13cc792
--- /dev/null
+++ b/contrib/completion/stg-completion.bash
@@ -0,0 +1,106 @@
+#!bash
+#
+# bash completion support for Stacked Git (StGit).
+#
+# Copyright (c) 2009 by Theodore P. Pavlic <ted@tedpavlic.com>
+# Distributed under the GNU General Public License, version 2.0.
+#
+# Design is highly influenced by completion scripts for Mercurial and
+# git.
+#
+# To use these routines:
+#
+# 1) Copy this file to somewhere (e.g. ~/.stg-completion.sh).
+# 2) Added the following line to your .bashrc or .bash_profile:
+# source ~/.stg-completion.sh
+#
+# To submit patches:
+#
+# *) Read Documentation/SubmittingPatches
+# *) Send all patches to the Git mailing list
+#
+# git@vger.kernel.org
+#
+# and CC the message to the StGit maintainer
+#
+# catalin.marinas@gmail.com
+#
+# Prefix the subject with something like "[StGit PATCH]",
+# "[StGit PATCH i/n]", "[StGit PATCH RFC]", or similar. Patches
+# should be "Signed-off-by:" you as described in
+# Documentation/SubmittingPatches.
+#
+# It is recommended that editors submit patches using utilities
+# like
+#
+# stg mail
+# git send-email
+# git format-patch
+#
+# In the latter case, make sure e-amils submitted to the list do
+# not have "format=flowed" and do not "word wrap" your patch.
+#
+
+# This 'extglob' bash option allows for
+# if [[ $param == @(-h|--help) ]]
+# type statements. That is, the pattern is true if $param matches -h OR
+# --help
+shopt -s extglob
+
+__stg_commands()
+{
+ local commands
+ commands="$("$stg" help|grep '^ '|cut -f3 -d' ' 2>/dev/null)" || commands=""
+ COMPREPLY=(${COMPREPLY[@]:-} $(compgen -W '$commands' -- "$cur"))
+}
+
+__stg()
+{
+ local cur prev cmd
+ local stg="$1"
+
+ COMPREPLY=()
+ cur="$2"
+ prev="$3"
+
+ if [ $COMP_CWORD -gt 1 ]; then
+ # Try to complete the argument to an already complete stg command
+ # (e.g., "stg command partial<tab>")
+ cmd=${COMP_WORDS[${COMP_CWORD}-1]}
+ __stg_specific_command
+ else
+ # Try to complete an incomplete stg command (possibly blank)
+ # (e.g., "stg partial<tab>")
+ __stg_commands
+ fi
+
+}
+
+# Handle "stg command <tab>" completion
+__stg_specific_command()
+{
+ # Here, try to find (possibly user-defined) functions that match the
+ # command
+ if [ "$(type -t "__stg_cmd_$cmd")" = function ]; then
+ "__stg_cmd_$cmd"
+ return 0
+ fi
+
+ # Special handling of particular stg commands can be placed here
+ case "$cmd" in
+ help)
+ # Complete help with all possible help commands
+ __stg_commands
+ ;;
+ *)
+ # Bail out to normal bash completion
+ return 1
+ ;;
+ esac
+
+ return 0
+}
+
+# Use __stg for stg completion and bail out to normal bash completion
+complete -o bashdefault -o default -F __stg stg 2>/dev/null \
+ || complete -o default -F __stg stg
--
1.6.1.87.g15624
^ permalink raw reply related
* Re: [PATCH v4 0/7] customizable --color-words
From: Santi Béjar @ 2009-01-19 22:47 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Junio C Hamano, Johannes Schindelin, Boyd Stephen Smith Jr.,
Teemu Likonen
In-Reply-To: <1232209788-10408-1-git-send-email-trast@student.ethz.ch>
2009/1/17 Thomas Rast <trast@student.ethz.ch>:
> Johannes Schindelin (4):
> Add color_fwrite_lines(), a function coloring each line individually
> color-words: refactor word splitting and use ALLOC_GROW()
> color-words: change algorithm to allow for 0-character word
> boundaries
> color-words: take an optional regular expression describing words
>
> Thomas Rast (3):
> color-words: enable REG_NEWLINE to help user
> color-words: expand docs with precise semantics
> color-words: make regex configurable via attributes
>
Also, having a config (diff.color-words?) to set the default regexp
would be great. Thanks.
Santi
^ permalink raw reply
* [PATCH] commit: more compact summary and without extra quotes
From: Santi Béjar @ 2009-01-19 22:45 UTC (permalink / raw)
To: git
Original:
[master]: created d9a5491: "foo:bar"
While with the patch it becomes:
[master d9a5491] foo:bar
As discussed in the git mailing list:
http://marc.info/?l=git&m=122765031208922&w=2
Signed-off-by: Santi Béjar <santi@agolina.net>
---
builtin-commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 2f0b00a..b159af2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -883,7 +883,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
{
struct rev_info rev;
struct commit *commit;
- static const char *format = "format:%h: \"%s\"";
+ static const char *format = "format:%h] %s";
unsigned char junk_sha1[20];
const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
@@ -910,7 +910,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
rev.diffopt.break_opt = 0;
diff_setup_done(&rev.diffopt);
- printf("[%s%s]: created ",
+ printf("[%s%s ",
!prefixcmp(head, "refs/heads/") ?
head + 11 :
!strcmp(head, "HEAD") ?
--
1.6.1.258.g7ff14
^ permalink raw reply related
* [PATCH,v2] git-checkout(1): mention fate of extraneous files
From: jidanni @ 2009-01-19 22:45 UTC (permalink / raw)
To: gitster; +Cc: git, markus.heidelberg
In-Reply-To: <877i4teq78.fsf@jidanni.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-checkout.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 9cd5151..58abdc6 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -17,7 +17,8 @@ DESCRIPTION
When <paths> are not given, this command switches branches by
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>. Using -b will cause <new_branch> to
+specified, <new_branch>. (No files are deleted, use linkgit:git-clean[1]
+for a pristine checkout.) Using -b will cause <new_branch> to
be created; in this case you can use the --track or --no-track
options, which will be passed to `git branch`.
--
1.6.0.6
^ permalink raw reply related
* Re: Syncing with CVS
From: Robin Rosenberg @ 2009-01-19 22:05 UTC (permalink / raw)
To: Christian von Kietzell; +Cc: git
In-Reply-To: <f31e50960901190139w65b69fd1k752973a23c40f384@mail.gmail.com>
måndag 19 januari 2009 10:39:53 skrev Christian von Kietzell:
> Hi,
>
> I have a project I started in git. After a while I exported that to
> CVS via git cvsexportcommit which worked quite nicely. Now, a
> colleague made changes to the project - in CVS. What's the best way to
> get those back into my git repository so that I'll be able to sync
> back and forth between git and CVS? I had a quick look at the wiki but
> couldn't find anything appropriate.
>
> I know of git cvsimport, of course, but that doesn't work on my
> original repository. Or does it? I didn't find anything on how to
> limit what to import. After all, some of the commits are already in my
> repository (the ones I exported).
Just continue with cvsimport, then git rebase origin. That'll drop the
commits that you made when the same commit have been discovered
in CVS.
I personally do the cvs import into a separate repo using a cron job. That
extra repo is my origin so I get up-to-date using git fetch and rebase just
as if the CVS commits would come from a real repo.
-- robin
^ permalink raw reply
* [PATCH v2] bash: offer to show (un)staged changes
From: Thomas Rast @ 2009-01-19 21:38 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20090119172939.GA14053@spearce.org>
Add a bit of code to __git_ps1 that lets it append '*' to the branch
name if there are any unstaged changes, and '+' if there are any
staged changes.
Since this is a rather expensive operation and will force a lot of
data into the cache whenever you first enter a repository, you have to
enable it manually by setting bash.showDirtyState to a true value.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > This makes the feature unavailable for people who care about the stat
> > dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
>
> Yup, and I'm one of those people who sets autorefresindex to false
> in my ~/.gitconfig, usually before I even have user.{name,email} set.
I tried to alleviate the problem with a combination of diff options
that hopefully does the right thing in all cases.
> I do like the idea of what Thomas is trying to do here, but its
> so bloody expensive to compute dirty state on every prompt in
> some repositories that I'd shoot myself. E.g. WebKit is huge,
> computing the dirty state inside of the WebKit repository on each
> prompt would absolutely kill CLI performance to a point of it not
> being usuable. But git.git is small enough its OK on pretty much
> everything except Cygwin.
>
> So as much as I'd like to use this without the update-index --refresh
> bit, I'm not sure its viable in every project out there.
I mostly work on small-ish repos, and while the initial loading is
_very_ noticeable, it's ok after that. But your point about repos
being different is very good, so I changed the patch to use a
git-config variable instead of a shell environment variable. That
way, you could even configure it to a different setting per-repo.
(Which might end up rather confusing, but at least it's possible.)
contrib/completion/git-completion.bash | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f8b845a..7864ca7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -34,6 +34,10 @@
# are currently in a git repository. The %s token will be
# the name of the current branch.
#
+# In addition, if you set bash.showDirtyState to a true value,
+# unstaged (*) and staged (+) changes will be shown next to the
+# branch name.
+#
# To submit patches:
#
# *) Read Documentation/SubmittingPatches
@@ -116,10 +120,24 @@ __git_ps1 ()
fi
fi
+ local w
+ local i
+
+ if test "$(git config --bool bash.showDirtyState)" = "true"; then
+ git diff --no-ext-diff --ignore-submodules \
+ --quiet --exit-code || w="*"
+ if git rev-parse --quiet --verify HEAD >/dev/null; then
+ git diff-index --cached --quiet \
+ --ignore-submodules HEAD -- || i="+"
+ else
+ i="#"
+ fi
+ fi
+
if [ -n "${1-}" ]; then
- printf "$1" "${b##refs/heads/}$r"
+ printf "$1" "${b##refs/heads/}$w$i$r"
else
- printf " (%s)" "${b##refs/heads/}$r"
+ printf " (%s)" "${b##refs/heads/}$w$i$r"
fi
fi
}
--
tg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)
^ permalink raw reply related
* [PATCH v2 2/2] bash completion: refactor diff options
From: Thomas Rast @ 2009-01-19 21:18 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1232399880-22036-1-git-send-email-trast@student.ethz.ch>
diff, log and show all take the same diff options. Refactor them from
__git_diff and __git_log into a variable, and complete them in
__git_show too.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
contrib/completion/git-completion.bash | 36 ++++++++++++++++++-------------
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 096603b..bfae953 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -773,14 +773,7 @@ _git_describe ()
__gitcomp "$(__git_refs)"
}
-_git_diff ()
-{
- __git_has_doubledash && return
-
- local cur="${COMP_WORDS[COMP_CWORD]}"
- case "$cur" in
- --*)
- __gitcomp "--cached --stat --numstat --shortstat --summary
+__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
--full-index --binary --abbrev --diff-filter=
@@ -789,9 +782,21 @@ _git_diff ()
--ignore-all-space --exit-code --quiet --ext-diff
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
- --base --ours --theirs
--inter-hunk-context=
--patience
+ --raw
+"
+
+_git_diff ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --pickaxe-all --pickaxe-regex
+ --base --ours --theirs
+ $__git_diff_common_options
"
return
;;
@@ -977,17 +982,16 @@ _git_log ()
--relative-date --date=
--author= --committer= --grep=
--all-match
- --pretty= --name-status --name-only --raw
+ --pretty=
--not --all
--left-right --cherry-pick
--graph
- --stat --numstat --shortstat
- --decorate --diff-filter=
- --color-words --walk-reflogs
+ --decorate
+ --walk-reflogs
--parents --children --full-history
--merge
--inter-hunk-context=
- --patience
+ $__git_diff_common_options
--pickaxe-all --pickaxe-regex
"
return
@@ -1492,7 +1496,9 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty="
+ __gitcomp "--pretty=
+ $__git_diff_common_options
+ "
return
;;
esac
--
tg: (3f8c856..) t/bash-complete-show (depends on: origin/next t/bash-complete-pickaxe t/bash-complete-pickaxe)
^ permalink raw reply related
* [PATCH v2 1/2] bash completion: move pickaxe options to log
From: Thomas Rast @ 2009-01-19 21:17 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20090119173153.GB14053@spearce.org>
Move the options --pickaxe-all and --pickaxe-regex to git-log, where
they make more sense than with git-diff.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > The changes around pickaxe made me "Huh?". For log pickaxe makes very
> > good sense but for a single diff it doesn't, yet the original seems to
> > have had them only on "git diff" and not on "git log", which feels wrong.
>
> I agree completely. The pickaxe stuff in current completion is
> just plain wrong. I'd like to see it fixed with this cleanup.
> Maybe do it in two parts; fix the pickaxe options to be on log
> and not diff, and then do the cleanup for the common options.
Good point. Sorry for not noticing in the first place; I was too
focused on just getting git-show completion working ;-)
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 60497a4..b5d3bbb 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -784,7 +784,7 @@ _git_diff ()
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
--full-index --binary --abbrev --diff-filter=
- --find-copies-harder --pickaxe-all --pickaxe-regex
+ --find-copies-harder
--text --ignore-space-at-eol --ignore-space-change
--ignore-all-space --exit-code --quiet --ext-diff
--no-ext-diff
@@ -986,6 +986,7 @@ _git_log ()
--parents --children --full-history
--merge
--inter-hunk-context=
+ --pickaxe-all --pickaxe-regex
"
return
;;
--
tg: (28da86a..) t/bash-complete-pickaxe (depends on: origin/master)
^ permalink raw reply related
* Re: how to track multiple upstreams in one repository
From: Julian Phillips @ 2009-01-19 20:45 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901191308030.2428@asgard.lang.hm>
On Mon, 19 Jan 2009, david@lang.hm wrote:
> On Mon, 19 Jan 2009, Julian Phillips wrote:
>
>> On Sun, 18 Jan 2009, david@lang.hm wrote:
>>
>> > for linux I want to track both the linus tree and the -stable tree.
>> > Ideally I want to be able to do a checkout of tags from either tree from
>> > the same directory (along with diffs between items in both trees, etc)
>> >
>> > I have found documentation on how to clone from each of them, but I
>> > haven't found any simple documentation on how to work with both of them.
>>
>> You could always just use
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
>> ? It already contains both the linus tree and all the stable trees ...
>
> I know it contains the releases, but does it contain the -rc trees?
It seems to contain everything from the main Linus tree as far as I can
see from the gitweb (haven't actually used it for kernel work).
>
> David Lang
>
>
--
Julian
---
Stock's Observation:
You no sooner get your head above water but what someone pulls
your flippers off.
^ permalink raw reply
* [PATCH] Fix naming scheme for configure cache variables.
From: Ralf Wildenhues @ 2009-01-19 20:34 UTC (permalink / raw)
To: git
In order to be cached, configure variables need to contain the
string '_cv_', and they should begin with a package-specific
prefix in order to avoid interfering with third-party macros.
Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
---
This avoids a warning with newer autoconf versions about the naming of
the cache variables, and makes the caching work for them.
As to the 'git_' prefix, it could be argued that the other cache
variables used in configure.ac should also be renamed s/ac_/git_/
If you like, I can provide a patch for those, too.
Thanks,
Ralf
configure.ac | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0a5fc8c..363547c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,31 +114,31 @@ AC_MSG_NOTICE([CHECKS for programs])
#
AC_PROG_CC([cc gcc])
# which switch to pass runtime path to dynamic libraries to the linker
-AC_CACHE_CHECK([if linker supports -R], ld_dashr, [
+AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -R /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [ld_dashr=yes], [ld_dashr=no])
+ AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
-if test "$ld_dashr" = "yes"; then
+if test "$git_cv_ld_dashr" = "yes"; then
AC_SUBST(CC_LD_DYNPATH, [-R])
else
- AC_CACHE_CHECK([if linker supports -Wl,-rpath,], ld_wl_rpath, [
+ AC_CACHE_CHECK([if linker supports -Wl,-rpath,], git_cv_ld_wl_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -Wl,-rpath,/"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [ld_wl_rpath=yes], [ld_wl_rpath=no])
+ AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_wl_rpath=yes], [git_cv_ld_wl_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
- if test "$ld_wl_rpath" = "yes"; then
+ if test "$git_cv_ld_wl_rpath" = "yes"; then
AC_SUBST(CC_LD_DYNPATH, [-Wl,-rpath,])
else
- AC_CACHE_CHECK([if linker supports -rpath], ld_rpath, [
+ AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
LDFLAGS="${SAVE_LDFLAGS} -rpath /"
- AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [ld_rpath=yes], [ld_rpath=no])
+ AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_rpath=yes], [git_cv_ld_rpath=no])
LDFLAGS="${SAVE_LDFLAGS}"
])
- if test "$ld_rpath" = "yes"; then
+ if test "$git_cv_ld_rpath" = "yes"; then
AC_SUBST(CC_LD_DYNPATH, [-rpath])
else
AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
--
1.6.1.137.g3d9e8
^ permalink raw reply related
* [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Ralf Wildenhues @ 2009-01-19 20:34 UTC (permalink / raw)
To: Julius Naperkowski, git
In-Reply-To: <20090116094110.GD25275@ins.uni-bonn.de>
In a cross compile setup, configure tests that run programs
cannot be executed; in that case, provide pessimistic default
values.
Bug reported by Julius Naperkowski.
---
> I can post a patch to add sane default settings for AC_RUN_IFELSE in
> cross compile setups, this weekend.
configure.ac | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 363547c..4a208d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,6 +360,7 @@ AC_RUN_IFELSE(
else if (strcmp(buf, "12345"))
return 2;]])],
[ac_cv_c_c99_format=yes],
+ [ac_cv_c_c99_format=no],
[ac_cv_c_c99_format=no])
])
if test $ac_cv_c_c99_format = no; then
@@ -380,6 +381,7 @@ AC_RUN_IFELSE(
FILE *f = fopen(".", "r");
return f && fread(&c, 1, 1, f)]])],
[ac_cv_fread_reads_directories=no],
+ [ac_cv_fread_reads_directories=yes],
[ac_cv_fread_reads_directories=yes])
])
if test $ac_cv_fread_reads_directories = yes; then
@@ -414,6 +416,7 @@ AC_RUN_IFELSE(
if (snprintf(buf, 3, "%s", "12345") != 5
|| strcmp(buf, "12")) return 1]])],
[ac_cv_snprintf_returns_bogus=no],
+ [ac_cv_snprintf_returns_bogus=yes],
[ac_cv_snprintf_returns_bogus=yes])
])
if test $ac_cv_snprintf_returns_bogus = yes; then
--
1.6.1.137.g3d9e8
^ permalink raw reply related
* Re: how to track multiple upstreams in one repository
From: david @ 2009-01-19 21:08 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0901191627480.4115@reaper.quantumfyre.co.uk>
On Mon, 19 Jan 2009, Julian Phillips wrote:
> On Sun, 18 Jan 2009, david@lang.hm wrote:
>
>> for linux I want to track both the linus tree and the -stable tree. Ideally
>> I want to be able to do a checkout of tags from either tree from the same
>> directory (along with diffs between items in both trees, etc)
>>
>> I have found documentation on how to clone from each of them, but I haven't
>> found any simple documentation on how to work with both of them.
>
> You could always just use
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git ?
> It already contains both the linus tree and all the stable trees ...
I know it contains the releases, but does it contain the -rc trees?
David Lang
^ permalink raw reply
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Junio C Hamano @ 2009-01-19 19:48 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090119122018.GA25566@chistera.yi.org>
Adeodato Simó <dato@net.com.org.es> writes:
> * Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:
> ...
>> A workdir is a new work area that is not a normal "work tree with a
>> full repository", but borrows from an existing repository. Any side
>> effect from the work you do in a workdir will be saved in the original
>> repository, and removing one would lose only the three kind of
>> information listed above. Creating a new workdir has the side effect
>> of enabling reflogs and rerere in the original repository.
>
>> But the last sentence somehow feels dirty.
>
> I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
> *enable* reflogs and rerere at all? Or, rather, it just gives an empty
> space for the workdirs "connecting" to it to save their reflogs and
> rerere stuff iff they are configured to do so?
I thought rerere does not kick in if rr-cache is absent, and it kicks in
if rr-cache is present when you do not explicitly disable it. So creation
of directory is a way to enable it. Besides, the net effect for a person
who does not want to have the bare repository contaminated with these
directories is the same. The original repository aquires them.
As I said already, I suspect that it would be more useful in practice to
create these directories as your patch did, than making the new workdir
inherit the lack of rerere and reflog support if the original repository
lacked them. I just wanted to see some documentation that makes it clear
that the original repository _is_ modified by a creation of a new workdir.
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 19:12 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901191306.49979.bss@iguanasuicide.net>
On Mon, Jan 19, 2009 at 2:06 PM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> Really? Why have inotify then? I thought its only purpose is "to keep track
> of the fs". If it is never a net win, why even use/provide it?
Lots of programs want to monitor _one file_ or _one directory_. Cron
daemons monitor /etc/cron.*/ , incron monitors /etc/incron.d/ ,
programs that watch mailspool directories can be made more efficient
this way too.
You might find your system today has perhaps a dozen inotify watches.
Judiciously used, it's great.
cheers
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Boyd Stephen Smith Jr. @ 2009-01-19 19:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Shawn O. Pearce, git
In-Reply-To: <46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On Monday 2009 January 19 12:00:10 Martin Langhoff wrote:
>On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org>
wrote:
>> ... If we had
>> an inotify sort of daemon to keep the data current so the prompt
>> doesn't have to stat every source file on every display it would
>> be reasonable, but we don't have such a thing yet for Git.
>
>[T]he kernel's cache will outperform any userland
>attempting to keep track of the fs via inotify.
Really? Why have inotify then? I thought its only purpose is "to keep track
of the fs". If it is never a net win, why even use/provide it?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Boyd Stephen Smith Jr. @ 2009-01-19 19:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090119172939.GA14053@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Monday 2009 January 19 11:29:39 Shawn O. Pearce wrote:
>E.g. WebKit is huge,
>computing the dirty state inside of the WebKit repository on each
>prompt would absolutely kill CLI performance to a point of it not
>being usuable.
Is the performance any better on other VCSes for this operation? If not,
maybe its just a feature that's infeasible for large trees.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 18:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119181158.GH14053@spearce.org>
On Mon, Jan 19, 2009 at 1:11 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> *sigh*
>
> I was hoping it would work well for the really huge repository case,
> like WebKit, where the stats against the work tree just kill the
> user space application.
Even hot-cache? My perception is that in hot-cache conditions the perf is good.
If it is cold-cache, what in the end you are hoping for is "pegging"
some stuff in the cache. Perhaps there's a way to tell the kernel to
skew the cache eviction scheme. Still, if the kernel's algorythms are
good, the kernel knows more about your fs usage patterns than you
do...
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Johannes Schindelin @ 2009-01-19 18:36 UTC (permalink / raw)
To: Keith Cascio; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.GSO.2.00.0901191000520.25883@kiwi.cs.ucla.edu>
Hi,
On Mon, 19 Jan 2009, Keith Cascio wrote:
> Fixed bug in diff whitespace ignore options. It is now
> OK to specify more than one whitespace ignore option
> on the command line.
>
> Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
ACK,
Dscho
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Mike Hommey @ 2009-01-19 18:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Langhoff, Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119181158.GH14053@spearce.org>
On Mon, Jan 19, 2009 at 10:11:58AM -0800, Shawn O. Pearce wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > ... If we had
> > > an inotify sort of daemon to keep the data current so the prompt
> > > doesn't have to stat every source file on every display it would
> > > be reasonable, but we don't have such a thing yet for Git.
> >
> > Note that inotify is not recursive and is a hog if you ask it to
> > monitor lots of dents.
> >
> > I am not convinced that an inotify-enabled git is a good idea for
> > anything but small/mid-sized project. And such don't need it either.
> >
> > In other words, the kernel's cache will outperform any userland
> > attempting to keep track of the fs via inotify.
>
> *sigh*
>
> I was hoping it would work well for the really huge repository case,
> like WebKit, where the stats against the work tree just kill the
> user space application.
I was hoping something like that too, especially for cold cache cases,
after resuming from hibernation, for instance, in which case the kernel
cache is empty and inotify tracking will help know if something changed.
Mike
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Shawn O. Pearce @ 2009-01-19 18:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <46a038f90901191000i250326e7k2184c149b70fcc8d@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > ... If we had
> > an inotify sort of daemon to keep the data current so the prompt
> > doesn't have to stat every source file on every display it would
> > be reasonable, but we don't have such a thing yet for Git.
>
> Note that inotify is not recursive and is a hog if you ask it to
> monitor lots of dents.
>
> I am not convinced that an inotify-enabled git is a good idea for
> anything but small/mid-sized project. And such don't need it either.
>
> In other words, the kernel's cache will outperform any userland
> attempting to keep track of the fs via inotify.
*sigh*
I was hoping it would work well for the really huge repository case,
like WebKit, where the stats against the work tree just kill the
user space application.
But if its only good for smaller sets of files, then yea, just
doing the stats on demand is going to be better than anything an
inotify daemon might be able to offer.
--
Shawn.
^ permalink raw reply
* [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Keith Cascio @ 2009-01-19 18:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901190446480.3586@pacific.mpi-cbg.de>
Fixed bug in diff whitespace ignore options. It is now
OK to specify more than one whitespace ignore option
on the command line.
Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
---
Dscho,
You are right. The code and the patch are more readable this way.
-- Keith
t/t4015-diff-whitespace.sh | 8 ++++----
xdiff/xutils.c | 6 ++++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index dbb608c..6d13da3 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -99,11 +99,11 @@ EOF
git diff -w > out
test_expect_success 'another test, with -w' 'test_cmp expect out'
git diff -w -b > out
-test_expect_failure 'another test, with -w -b' 'test_cmp expect out'
+test_expect_success 'another test, with -w -b' 'test_cmp expect out'
git diff -w --ignore-space-at-eol > out
-test_expect_failure 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
git diff -w -b --ignore-space-at-eol > out
-test_expect_failure 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
@@ -123,7 +123,7 @@ EOF
git diff -b > out
test_expect_success 'another test, with -b' 'test_cmp expect out'
git diff -b --ignore-space-at-eol > out
-test_expect_failure 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
+test_expect_success 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index d7974d1..04ad468 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -245,12 +245,14 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
while (ptr + 1 < top && isspace(ptr[1])
&& ptr[1] != '\n')
ptr++;
- if (flags & XDF_IGNORE_WHITESPACE_CHANGE
+ if (flags & XDF_IGNORE_WHITESPACE)
+ ; /* already handled */
+ else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
&& ptr[1] != '\n') {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
- if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
+ else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
&& ptr[1] != '\n') {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
--
1.6.1.213.g28da8.dirty
^ permalink raw reply related
* Re: [PATCH] bash: offer to show (un)staged changes
From: Martin Langhoff @ 2009-01-19 18:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119172939.GA14053@spearce.org>
On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> ... If we had
> an inotify sort of daemon to keep the data current so the prompt
> doesn't have to stat every source file on every display it would
> be reasonable, but we don't have such a thing yet for Git.
Note that inotify is not recursive and is a hog if you ask it to
monitor lots of dents.
I am not convinced that an inotify-enabled git is a good idea for
anything but small/mid-sized project. And such don't need it either.
In other words, the kernel's cache will outperform any userland
attempting to keep track of the fs via inotify.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [JGIT PATCH] Fix TreeWalk.idEqual when both trees are missing the path
From: Shawn O. Pearce @ 2009-01-19 17:52 UTC (permalink / raw)
To: Robin Rosenberg, tomi.pakarinen; +Cc: git
The Javadoc of idEqual() says its simply a faster form of
getObjectId(nthA).equals(getObjectId(nthB)), but its code
didn't match that definition when both trees didn't exist
at the current path.
If a tree doesn't exist for the current path getObjectId() returns
ObjectId.zero(), indicating the "magic" 0{40} SHA-1 for the current
path. If both tree entries don't exist for the current path, we
should be doing a compare of ObjectId.zero() against ObjectId.zero(),
which must be true as the values are the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/treewalk/TreeWalk.java | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
index ecf8851..414587c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
@@ -616,7 +616,16 @@ public boolean idEqual(final int nthA, final int nthB) {
final AbstractTreeIterator ch = currentHead;
final AbstractTreeIterator a = trees[nthA];
final AbstractTreeIterator b = trees[nthB];
- return a.matches == ch && b.matches == ch && a.idEqual(b);
+ if (a.matches == ch && b.matches == ch)
+ return a.idEqual(b);
+ if (a.matches != ch && b.matches != ch) {
+ // If neither tree matches the current path node then neither
+ // tree has this entry. In such case the ObjectId is zero(),
+ // and zero() is always equal to zero().
+ //
+ return true;
+ }
+ return false;
}
/**
--
1.6.1.331.g9c367
^ permalink raw reply related
* Re: [JGIT PATCH 8/8] Define a basic merge API, and a two-way tree merge strategy
From: Shawn O. Pearce @ 2009-01-19 17:51 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: Robin Rosenberg, git
In-Reply-To: <20090119174254.GC14053@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Tomi Pakarinen <tomi.pakarinen@gmail.com> wrote:
> > testTrivialTwoWay_disjointhistories() failed because merge strategy
> > didn't handle missing base
> > version. Am'i right?
>
> If that isn't coming out right then perhaps tw.idEqual() is busted
Yup, that's what it is, idEqual is busted.
The definition of TreeWalk.idEqual is:
public boolean idEqual(final int nthA, final int nthB) {
final AbstractTreeIterator ch = currentHead;
final AbstractTreeIterator a = trees[nthA];
final AbstractTreeIterator b = trees[nthB];
return a.matches == ch && b.matches == ch && a.idEqual(b);
}
The problem is this method always returns false if the name isn't
defined in either path. I think this is the definition we want
instead:
if (a.matches == ch && b.matches == ch)
return a.idEqual(b);
if (a.matches != ch && b.matches != ch) {
// If neither tree matches the current path node then neither
// tree has this entry. In such case the ObjectId is zero(),
// and zero() is always equal to zero().
//
return true;
}
return false;
Patch to follow.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] shell: Document that 'cvs server' is a valid command
From: Johannes Schindelin @ 2009-01-19 17:49 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, gitster
In-Reply-To: <1232384803-29373-1-git-send-email-lars@public.noschinski.de>
Hi,
On Mon, 19 Jan 2009, Lars Noschinski wrote:
> git-shell's man page explicitly lists all allowed commands, but 'cvs
> server' was missing. Add it.
Oops (has been there since Oct 7 _2007_). Thank you,
Dscho
^ 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