* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-02 21:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: David Kastrup, git
In-Reply-To: <fcaeb9bf0708021356v57b29a70yb69a2fa000bd5b55@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 8/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Non POSIX substitions such as ${parameter/pattern/string} and
>> ${parameter:offset} are not to be used. We do not want to
>> depend on bash.
>
> There is in a test (t5300-pack-objects.sh) but I guess the
> restrictions do not apply on tests.
That would have been an earlier mistake. Keeping tests portable
is important, perhaps it might be of lessor importance but
still.
^ permalink raw reply
* Re: [PATCH] Fix set_work_tree on cygwin
From: Johannes Schindelin @ 2007-08-02 21:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070802204909.GA2829@steel.home>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
> Johannes Schindelin, Thu, Aug 02, 2007 17:38:37 +0200:
>
> > On Thu, 2 Aug 2007, Alex Riesen wrote:
> >
> > >@@ -209,7 +209,8 @@ const char *set_work_tree(const char *dir)
> > > len = strlen(dir);
> > > if (len > postfix_len && !strcmp(dir + len - postfix_len,
> > > "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
> > >- strncpy(dir_buffer, dir, len - postfix_len);
> > >+ strncpy(dir_buffer, dir, len - postfix_len);
> > >+ dir_buffer[len - postfix_len] = '\0';
> > >
> > > /* are we inside the default work tree? */
> > > rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
> >
> > Darn, darn, darn. strncpy does _not_ NUL terminate. I keep forgetting
> > that.
> >
> > Better use strlcpy()?
>
> Of course, but it just should not be needed at all: static supposed to
> be zeroed.
Certainly. But reality outweighs theory, and so I Ack either your patch
or replacing it by strlcpy().
Ciao,
Dscho
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 21:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0708021356v57b29a70yb69a2fa000bd5b55@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 8/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Non POSIX substitions such as ${parameter/pattern/string} and
>> ${parameter:offset} are not to be used. We do not want to
>> depend on bash.
>
> There is in a test (t5300-pack-objects.sh) but I guess the
> restrictions do not apply on tests.
Oh, but they definitely should. Precisely on those platforms with
shells not generally in use by the developers it becomes _most_
important to reliably be able to trace failed tests to problems with
the _commands_, not problems with the tests.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkctvfk9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Hi, I wanted to ask what the general stance towards shell script
>> cleanups and simplifications would be. For example, I find the
>> expr usage quite inscrutable in commit, and there is no necessity
>> of putting "shift" in every case branch instead of once behind it,
>> and a lot of conditionals and other manipulations can be made much
>> easier on the eye by using parameter expansion patterns that are,
>> as far as I can see, available with every reasonable Bourne Shell
>> and clones.
>
> As to Bourne-ness of the shell script, please realize that your
> maintainer is very old fashioned ;-), but is willing to be taught
> new tricks within reason.
Most of the "new tricks" I try on bash, dash and ash.
> We try to limit ourselves to -, =, ?, + (and their colon "if
> empty" variants when it really make sense) in parameter
> expansion of shell variables. We also use % and # (and their
> "match largest" variants).
You do?
Indeed:
-*- mode: grep; default-directory: "/home/tmp/git/" -*-
Grep started at Thu Aug 2 22:47:30
grep -nH -e '\${[a-zA-Z0-9_]*[#%]' *.sh
git-am.sh:146: resolvemsg=${1#--resolvemsg=}; shift ;;
git-clone.sh:358: destname="refs/$branch_top/${name#refs/heads/}" ;;
git-clone.sh:360: destname="refs/$tag_top/${name#refs/tags/}" ;;
git-filter-branch.sh:361: ref="${ref#refs/tags/}"
git-pull.sh:98: curr_branch=${curr_branch#refs/heads/}
git-rebase.sh:93: eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
git-stash.sh:52: branch=${branch#refs/heads/}
Grep finished (matches found) at Thu Aug 2 22:47:31
I am confused now: a different poster adamantly stated that /bin/sh on
Solaris did not support those constructs, and that every functionality
of git was working fine for him.
> Non POSIX substitions such as ${parameter/pattern/string} and
> ${parameter:offset} are not to be used. We do not want to
> depend on bash.
Sure. What about the git-rebase line using $(($end - $msgnum)) ?
That's even more risque than ##.
> After 1.5.3 git-commit.sh will hopefully become built-in, so I would
> rather not touch the script.
Too bad: this should mean that $EDITOR can get called from C... I've
been glad to see that so far this could be avoided.
> Certainly, the kind of change that is "intended to be style-only but
> somebody needs to make sure it does not introduce regression to
> everybody's shell" is very unwelcome at this point.
Understood. But using ${...#...} and ${...:+...} does not exactly
seem to be news in the git code base. Even though we have the claim
that Solaris' sh won't deal with the former.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Nguyen Thai Ngoc Duy @ 2007-08-02 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7vlkctvfk9.fsf@assigned-by-dhcp.cox.net>
On 8/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> Non POSIX substitions such as ${parameter/pattern/string} and
> ${parameter:offset} are not to be used. We do not want to
> depend on bash.
There is in a test (t5300-pack-objects.sh) but I guess the
restrictions do not apply on tests.
--
Duy
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-02 20:50 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <AF1190E2-A0F4-479F-B0A1-50B2C7278995@yahoo.ca>
Jean-François Veillette <jean_francois_veillette@yahoo.ca>
writes:
> I find comments like this to be counter productive.
> Admin it, git porcelain still has some work to be done.
Yes, but this certainly is not an area that needs changing.
^ permalink raw reply
* Re: [PATCH] Fix set_work_tree on cygwin
From: Alex Riesen @ 2007-08-02 20:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0708021636470.14781@racer.site>
Johannes Schindelin, Thu, Aug 02, 2007 17:38:37 +0200:
> Hi,
>
> On Thu, 2 Aug 2007, Alex Riesen wrote:
>
> >@@ -209,7 +209,8 @@ const char *set_work_tree(const char *dir)
> > len = strlen(dir);
> > if (len > postfix_len && !strcmp(dir + len - postfix_len,
> > "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
> >- strncpy(dir_buffer, dir, len - postfix_len);
> >+ strncpy(dir_buffer, dir, len - postfix_len);
> >+ dir_buffer[len - postfix_len] = '\0';
> >
> > /* are we inside the default work tree? */
> > rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
>
> Darn, darn, darn. strncpy does _not_ NUL terminate. I keep forgetting
> that.
>
> Better use strlcpy()?
Of course, but it just should not be needed at all: static supposed to
be zeroed.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Junio C Hamano @ 2007-08-02 20:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708021247.08612.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Personally, this late in the game, I would be more interested in
>> resolving the File::Find() stuff, which has been a real issue in
>> the field, than the compressed transfer one.
>
> I posted my tentative Ack, haven't I?
>
> I guess that your solution is good, and doesn't have any drawbacks,
> besides perhaps a tiny little bit of lost performance. So I think
> that you should just commit this...
>
>
> As to the new stuff: I think I postpone large changes, like blob
> size in tree view, or links to no merges and first parent
> log/shortlog/history view, or list form of two pipelines we have in
> gitweb, or HTML cleanup, etc. after the v1.5.3 release.
Thanks, alright, I am relieved to know that we are on the same
page.
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Linus Torvalds @ 2007-08-02 20:43 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Michael Haggerty, git, users
In-Reply-To: <65F1862F-4DF2-4A52-9FD5-20802AEACDAB@zib.de>
On Thu, 2 Aug 2007, Steffen Prohaska wrote:
>
> Right now, I'd prefer the import by parsecvs because of the
> simpler history. However, I don't know if I loose history
> information by doing so. I'd start by a run of cvs2svn to validate
> the overall structure of the CVS repository.
Well, once imported, you could just go through the branches and tags, and
just delete the ones you consider uninteresting, and then do a "git gc".
You'd want to re-pack after a fast-import anyway (regardless of the source
of the fast-import input), so maybe cvs2svn ends up giving you a bit
unnecessary info, but it should be easy enough to get rid of
after-the-fact.
Linus
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-02 20:37 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqdqkygp.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Hi, I wanted to ask what the general stance towards shell script
> cleanups and simplifications would be. For example, I find the expr
> usage quite inscrutable in commit, and there is no necessity of
> putting "shift" in every case branch instead of once behind it, and a
> lot of conditionals and other manipulations can be made much easier on
> the eye by using parameter expansion patterns that are, as far as I
> can see, available with every reasonable Bourne Shell and clones.
The shift in parameter parsing case arms were originally
generated by an automated tool. If it bothers you, feel free to
move them at the end, I would not mind. In fact, handcrafted
parameter parser in other scripts do use shift-at-the-end.
As to Bourne-ness of the shell script, please realize that your
maintainer is very old fashioned ;-), but is willing to be
taught new tricks within reason.
We try to limit ourselves to -, =, ?, + (and their colon "if
empty" variants when it really make sense) in parameter
expansion of shell variables. We also use % and # (and their
"match largest" variants).
Non POSIX substitions such as ${parameter/pattern/string} and
${parameter:offset} are not to be used. We do not want to
depend on bash.
We try to avoid [ ] and instead spell "test" explicitly; this is
just a personal taste, and not about portability but more about
readability.
After 1.5.3 git-commit.sh will hopefully become built-in, so I
would rather not touch the script. Certainly, the kind of
change that is "intended to be style-only but somebody needs to
make sure it does not introduce regression to everybody's shell"
is very unwelcome at this point.
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Lübbe Onken @ 2007-08-02 20:32 UTC (permalink / raw)
To: git; +Cc: users
In-Reply-To: <200708022221.13129.robin.rosenberg.lists@dewire.com>
Hi Folks,
I guess that the initial poster sent this message to the TortoiseSVN
users list only by mistake, because the subject has nothing at all to do
with TortoiseSVN.
Could you please be so kind and remove the TortoiseSVN users list from
future replies to this thread?
thanks
-Lübbe
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Lübbe Onken @ 2007-08-02 20:33 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Simon 'corecode' Schubert, Steffen Prohaska,
Michael Haggerty, git, users
In-Reply-To: <200708022221.13129.robin.rosenberg.lists@dewire.com>
Hi Folks,
I guess that the initial poster sent this message to the TortoiseSVN
users list only by mistake, because the subject has nothing at all to do
with TortoiseSVN.
Could you please be so kind and remove the TortoiseSVN users list from
future replies to this thread?
thanks
-Lübbe
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Lübbe Onken @ 2007-08-02 20:31 UTC (permalink / raw)
To: users-6zjzXkf2FExf8fUKLXF2/HdfcadvtA/q
Cc: git-u79uwXL29TY76Z2rM5mHXA,
users-6zjzXkf2FExf8fUKLXF2/HdfcadvtA/q
In-Reply-To: <200708022221.13129.robin.rosenberg.lists-RgPrefM1rjDQT0dZR+AlfA@public.gmane.org>
Hi Folks,
I guess that the initial poster sent this message to the TortoiseSVN
users list only by mistake, because the subject has nothing at all to do
with TortoiseSVN.
Could you please be so kind and remove the TortoiseSVN users list from
future replies to this thread?
thanks
-Lübbe
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Robin Rosenberg @ 2007-08-02 20:21 UTC (permalink / raw)
To: Simon 'corecode' Schubert
Cc: Steffen Prohaska, Michael Haggerty, git, users
In-Reply-To: <46B2309E.3060804@fs.ei.tum.de>
torsdag 02 augusti 2007 skrev Simon 'corecode' Schubert:
> Steffen Prohaska wrote:
> > I remember that togit reported a broken pipe. My feeling was
> > that git-fastimport aborted, which may be reason why tohg
> > worked better. I didn't try to understand more details. I never
> > read ruby code before and it was already a challenge for me to
> > get everything up and running (rcs, rbtree).
>
> yah, that pretty much tells me it is shawn's bug :) but without more
details, it is very hard to diagnose. tohg should tell you which rcs revs
are the offenders. be sure to use a recent fromcvs however.
If the bug is still unfixed and you haven't been able to diagnose for lack of
repos, you could try the Eclipse CVS repo.
When I converted the Eclipse source to git I had a problem converting the
whole repo, i.e. fastimport died. The conversion died so I excluded some
large parts that were effectively forks and some websites.
-- robin
^ permalink raw reply
* [StGIT PATCH 6/6] Fixed completion function hardcoding .git/.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stgit-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index 2d0d5f2..7ae9e6a 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -108,7 +108,7 @@ _all_other_patches ()
_all_branches ()
{
local g=$(_gitdir)
- [ "$g" ] && (cd .git/patches/ && echo *)
+ [ "$g" ] && (cd $g/patches/ && echo *)
}
_conflicting_files ()
^ permalink raw reply related
* [StGIT PATCH 4/6] Add a no-act flag to stg-dispatch and stg-fold-file-from.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-dispatch | 20 +++++++++++++++-----
contrib/stg-fold-files-from | 15 +++++++++++++--
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/contrib/stg-dispatch b/contrib/stg-dispatch
index 8911946..e9cfb05 100755
--- a/contrib/stg-dispatch
+++ b/contrib/stg-dispatch
@@ -6,7 +6,7 @@ set -e
# do so), but from the patch containing the changes to migrate,
# instead of doing so from the target patch.
-# usage: stg-dispatch <topatch> [-#<n>[-<n>][,<n>]...] <file-pattern>
+# usage: stg-dispatch [-n] <topatch> [-#<n>[-<n>][,<n>]...] <file-pattern>
# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
@@ -17,6 +17,12 @@ die()
exit 1
}
+noact=0
+if [ "x$1" = "x-n" ]; then
+ noact=1
+ shift
+fi
+
TOPATCH="$1"
shift
@@ -28,7 +34,11 @@ CURRENTPATCH=$(stg top)
[ "x$TOPATCH" != "x$CURRENTPATCH" ] ||
die "dispatching to current patch ($CURRENTPATCH) makes no sense"
-stg goto "$TOPATCH"
-stg-fold-files-from "$CURRENTPATCH" "$@"
-stg refresh
-stg goto "$CURRENTPATCH"
+if [ $noact = 1 ]; then
+ stg-fold-files-from "$CURRENTPATCH" -n "$@"
+else
+ stg goto "$TOPATCH"
+ stg-fold-files-from "$CURRENTPATCH" "$@"
+ stg refresh
+ stg goto "$CURRENTPATCH"
+fi
diff --git a/contrib/stg-fold-files-from b/contrib/stg-fold-files-from
index 806a157..c52abfc 100755
--- a/contrib/stg-fold-files-from
+++ b/contrib/stg-fold-files-from
@@ -8,7 +8,7 @@ set -e
# identify hunk numbers easily.
# Use "-O -U<n>" to get finer hunk granularity for -#<n>.
-# usage: stg-fold-files-from <patch> [-O <stg-show-flags>] [-#<n>[-<n>][,<n>]...] <file-pattern>
+# usage: stg-fold-files-from <patch> [-n] [-O <stg-show-flags>] [-#<n>[-<n>][,<n>]...] <file-pattern>
# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
@@ -20,10 +20,12 @@ filtercmd=cat
hunks=
foldflags=
showflags=()
+noact=0
while [ "$#" -gt 0 ]; do
case "$1" in
-\#*) hunks="$1" ;;
-t) foldflags="-t" ;;
+ -n) noact=1 ;;
-O) showflags+=(-O "$2"); shift ;;
-*) { echo >&2 "unknown flag '$1'"; exit 1; } ;;
*) break ;;
@@ -32,4 +34,13 @@ while [ "$#" -gt 0 ]; do
done
[ "$#" = 1 ] || { echo >&2 "supports one file only"; exit 1; }
-stg show "${showflags[@]}" "$PATCH" | filterdiff -p1 $hunks -i "$1" | stg fold $foldflags
+getpatch()
+{
+ stg show "${showflags[@]}" "$PATCH" | filterdiff -p1 $hunks -i "$1"
+}
+
+if [ $noact = 1 ]; then
+ getpatch "$1"
+else
+ getpatch "$1" | stg fold $foldflags
+fi
^ permalink raw reply related
* [StGIT PATCH 5/6] Provide file completion for add/resolved/refresh based on status.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stgit-completion.bash | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index a843db4..2d0d5f2 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -111,6 +111,30 @@ _all_branches ()
[ "$g" ] && (cd .git/patches/ && echo *)
}
+_conflicting_files ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && stg status --conflict
+}
+
+_dirty_files ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && stg status --modified --new --deleted
+}
+
+_unknown_files ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && stg status --unknown
+}
+
+_known_files ()
+{
+ local g=$(_gitdir)
+ [ "$g" ] && git ls-files
+}
+
# List the command options
_cmd_options ()
{
@@ -162,6 +186,11 @@ _complete_options ()
COMPREPLY=($(compgen -W "$options" -- "${COMP_WORDS[COMP_CWORD]}"))
}
+_complete_files ()
+{
+ COMPREPLY=($(compgen -W "$(_cmd_options $1) $2" -- "${COMP_WORDS[COMP_CWORD]}"))
+}
+
_stg_common ()
{
_complete_options "$(_cmd_options $1)"
@@ -223,12 +252,16 @@ _stg ()
log) _stg_patches $command _all_patches ;;
mail) _stg_patches $command _all_patches ;;
pick) _stg_patches $command _unapplied_patches ;;
- refresh)_stg_patches_options $command _applied_patches "-p --patch" ;;
+# refresh)_stg_patches_options $command _applied_patches "-p --patch" ;;
+ refresh) _complete_files $command "$(_dirty_files)" ;;
rename) _stg_patches $command _all_patches ;;
show) _stg_patches $command _all_patches ;;
sync) _stg_patches $command _applied_patches ;;
# working-copy commands
diff) _stg_patches_options $command _applied_patches "-r --range" ;;
+ resolved) _complete_files $command "$(_conflicting_files)" ;;
+ add) _complete_files $command "$(_unknown_files)" ;;
+# rm) _complete_files $command "$(_known_files)" ;;
# commands that usually raher accept branches
branch) _complete_branch $command _all_branches ;;
rebase) _complete_branch $command _all_branches ;;
^ permalink raw reply related
* [StGIT PATCH 3/6] Add -O flag to stg-fold-files-from.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-fold-files-from | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/stg-fold-files-from b/contrib/stg-fold-files-from
index 53d3d02..806a157 100755
--- a/contrib/stg-fold-files-from
+++ b/contrib/stg-fold-files-from
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
set -e
# stg-fold-files-from - picks changes to one file from another patch.
@@ -6,8 +6,9 @@ set -e
# of hunks from the file, using the -# flag to filterdiff.
# Use together with "filterdiff --annotate" in your diff pager, to
# identify hunk numbers easily.
+# Use "-O -U<n>" to get finer hunk granularity for -#<n>.
-# usage: stg-fold-files-from <patch> [-#<n>[-<n>][,<n>]...] <file-pattern>
+# usage: stg-fold-files-from <patch> [-O <stg-show-flags>] [-#<n>[-<n>][,<n>]...] <file-pattern>
# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
@@ -18,14 +19,17 @@ shift
filtercmd=cat
hunks=
foldflags=
+showflags=()
while [ "$#" -gt 0 ]; do
case "$1" in
- -\#*) hunks="$1"; shift ;;
- -t) foldflags="-t"; shift ;;
+ -\#*) hunks="$1" ;;
+ -t) foldflags="-t" ;;
+ -O) showflags+=(-O "$2"); shift ;;
-*) { echo >&2 "unknown flag '$1'"; exit 1; } ;;
*) break ;;
esac
+ shift
done
[ "$#" = 1 ] || { echo >&2 "supports one file only"; exit 1; }
-stg show "$PATCH" | filterdiff -p1 $hunks -i "$1" | stg fold $foldflags
+stg show "${showflags[@]}" "$PATCH" | filterdiff -p1 $hunks -i "$1" | stg fold $foldflags
^ permalink raw reply related
* [StGIT PATCH 2/6] New contrib scripts: stg-dispatch and stg-show.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-dispatch | 34 ++++++++++++++++++++++++++++++++++
contrib/stg-show | 27 +++++++++++++++++++++++++++
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/contrib/stg-dispatch b/contrib/stg-dispatch
new file mode 100755
index 0000000..8911946
--- /dev/null
+++ b/contrib/stg-dispatch
@@ -0,0 +1,34 @@
+#!/bin/sh
+set -e
+
+# stg-dispatch - percollates files matching a pattern down to another patch.
+# It does the same job as stg-fold-files-from (and makes use of it to
+# do so), but from the patch containing the changes to migrate,
+# instead of doing so from the target patch.
+
+# usage: stg-dispatch <topatch> [-#<n>[-<n>][,<n>]...] <file-pattern>
+
+# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+die()
+{
+ echo >&2 "$(basename $0) error: $*"
+ exit 1
+}
+
+TOPATCH="$1"
+shift
+
+stg applied | grep "^$TOPATCH\$" >/dev/null ||
+ die "cannot dispatch to unapplied patch '$TOPATCH'"
+
+CURRENTPATCH=$(stg top)
+
+[ "x$TOPATCH" != "x$CURRENTPATCH" ] ||
+ die "dispatching to current patch ($CURRENTPATCH) makes no sense"
+
+stg goto "$TOPATCH"
+stg-fold-files-from "$CURRENTPATCH" "$@"
+stg refresh
+stg goto "$CURRENTPATCH"
diff --git a/contrib/stg-show b/contrib/stg-show
new file mode 100755
index 0000000..8c61540
--- /dev/null
+++ b/contrib/stg-show
@@ -0,0 +1,27 @@
+#!/bin/bash
+set -e
+
+# stg-show - unlike "stg show", just "git show" with knowledge of stg refs
+
+# Ex:
+# stg-show --color-words -- files
+
+# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+command=(git show)
+
+# subsitute git id's for stg ones until --
+endofpatches=0
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ --) endofpatches=1; break ;;
+ -*) command+=("$1"); shift ;;
+ *) command+=( $(stg id "$1" 2>/dev/null || echo "$1") ); shift ;;
+ esac
+done
+
+# append remaining args
+command+=("$@")
+
+eval "${command[@]}"
^ permalink raw reply related
* [StGIT PATCH 1/6] Improve stg-fold-files-from doc.
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070802200704.16614.57993.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-fold-files-from | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/stg-fold-files-from b/contrib/stg-fold-files-from
index bfb4a1f..53d3d02 100755
--- a/contrib/stg-fold-files-from
+++ b/contrib/stg-fold-files-from
@@ -2,12 +2,12 @@
set -e
# stg-fold-files-from - picks changes to one file from another patch.
-# Only supports picking from one file, but allows to select any range
+# Only supports picking from one file pattern, but allows to select any range
# of hunks from the file, using the -# flag to filterdiff.
# Use together with "filterdiff --annotate" in your diff pager, to
# identify hunk numbers easily.
-# usage: stg-fold-files-from <patch> [-#<n>[-<n>][,<n>]...] <file>
+# usage: stg-fold-files-from <patch> [-#<n>[-<n>][,<n>]...] <file-pattern>
# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
^ permalink raw reply related
* [StGIT PATCH 0/6] Various contrib/ updates
From: Yann Dirson @ 2007-08-02 20:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This series, asside from small fixes, enhance the bash completion to
be aware of file status (notably, makes it much more comfortable to
refresh only selective files), and introduces 2 new contrib scripts:
- whereas stg-fold-files-from was designed to merge in the current
patch changes from several other patches, stg-dispatch makes life
easier to split a given patch into several other ones (ie. making a
split series out of a monolithic patch).
- stg-show is a RFC/proof-of-concept for a redesign of "stg show",
which calls git-show much more transparently. This allows to harness
the full power of the git-show command-line without duplicating the
logic in stgit.
I already made heavy use of the scripts in the last days, and I rate
them as good candidates for 0.13.1.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] Fix documentation for core.gitproxy to reflect code
From: Junio C Hamano @ 2007-08-02 20:12 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20708020523m1a243bf2g9778994441cd21d5@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> This is with respect to my earlier email about core.gitproxy. I
> figured since 1.5.3 is looming it would be best to get the
> documentation correct, then nag about the feature later!
>
> Dave.
That's not a commit log message.
If the existing example does not work, then please say that you
fixed it (i.e. "The values in the example does not work. The
accepted forms are such and such and such, so use them in the
example") in the log message. "Your earlier email" does not
count. People who are reading the "git log" output would not
have easy access to it.
If core.gitproxy is not documented (I suspect the parts you
touched are not about "how to use core.gitproxy" but "what's the
syntax of a configuration file" example), it needs its own
proper entry in config.txt. If it has one, but if you feel it
needs more explanation or exmples, that section needs to be
updated.
Please retry.
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-02 19:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqzm1a2l72.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Quite honestly, a script that indiscriminately touches everybody
>> but only modifies a few is simply broken. Think about "make".
>> "git diff" reporting many cache-dirty files is simply reminding
>> you the brokenness of such a script.
>
> I wouldn't call this "broken", but clearly suboptimal, yes. But for an
> occasionnal one-liner (perl -pi -e ... or so), I lose less time
> recompiling extra-files than I would writting a cleaner script. "make"
> has no way to detect the absence of modification, while git has.
The first part of your sentence makes sense. You are trading
"make" time with the reduction in effort to write a throw-away
script. That makes sense --- and you pay with a more expensive
make, but that is a valid tradeoff you choose to make. You can
just choose to make the same tradeoff by running an extra
refresh.
You could do something like the trivial patch attached below to
squelch diff-files "cache-dirty" output, if you wanted to.
After trying to work with this modified git for some time,
however, it has become very clear that doing this and nothing
else is a stupid thing to do (I'll suggest potential
improvements at the end). For one thing, it obviously loses the
"quick git-diff to see what I touched" benefit. And that issue
is real, as I first touched diff-lib.c to come up with this
until I realized that doing it in here is much cleaner and
simpler --- this patch is discarding that information, and makes
writing a changelog for this patch, if it were to be included,
more expensive for the user -- that is me.
Another thing is that it loses the coal-mine canary value the
"cache-dirty" output has. After running a loosely written bulk
regexp script, like this:
perl -p -i -e 's/foo/bar/' *.c
the cached stat data are destroyed for all paths, and it makes
all the subsequent git worktree operations needlessly more
expensive; existing output makes me realize this situation.
It is not a stupid thing to run such a script [*1*]; in this
case, I am choosing the convenience of using such a suboptimal
(as you said) script. But after running such a script, I DO
WANT git to tell me that I made the index suboptimal, so that I
can and should refresh it to gain the lost performance back.
Personally, I almost never run "git status". The command is
there primarily because other systems had a command called
"status", and migrant wondered why we didn't. We do not need
it, and we do not have to use it.
* For getting the status so-far, I use "git diff" (and "git
diff ." when in a subdirectory). It is "how have I changed
things?", and that is when it is very useful to know "ah, I
originally went in that direction but decided against it and
did it differently" by the cache-dirtiness output. The
coal-mine canary value is also felt here;
* For a quick final status, "git diff --stat" is much simpler
to read than "git status", and that is what I use. It is
"what have I changed overall?". As this actually counts the
real changes, you would not see those null changes that come
from the cache dirtiness you are complaining about;
* When I am ready to commit, "git status" output comes in the
commit log editor. At that point, I already have been
reminded by the previous "git diff" (which is usually run
often unless the patch is very small like this), and I do not
need cache-dirtiness output anymore after making my commit.
You do not have to say, to the above paragraph, that it is
different from your workflow. I am showing what the opmimum
workflow would be, and it is up to you not to listen to me.
Even if we were willing to lose the "quick git-diff to see what
I touched" benefit and want to go the route of the attached
patch suggests (which I personally do not think we are), there
should be a way to either (1) tell the user that many paths are
found to be cache-dirty and it is a good idea to refresh the
stat information, after squelching diff-files output this way,
or (2) update the stat information automatically when diff-files
finds too many paths are cache-dirty (perhaps without even
telling the user). The latter requires you to declare that
git-diff is not a read-only operation anymore, though, so you
would need some thought before going in that direction.
[Footnote]
*1* Some people might argue that "perl -i" should have a mode to
leave the original if the script does not modify the contents.
Maybe they are right, but that is an orthogonal issue.
---
diff.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index a5fc56b..ea1239d 100644
--- a/diff.c
+++ b/diff.c
@@ -3143,6 +3143,45 @@ static void diffcore_apply_filter(const char *filter)
*q = outq;
}
+static void diffcore_remove_empty(void)
+{
+ int i;
+ struct diff_queue_struct *q = &diff_queued_diff;
+ struct diff_queue_struct outq;
+ outq.queue = NULL;
+ outq.nr = outq.alloc = 0;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+
+ /*
+ * 1. Keep the ones that cannot be diff-files
+ * "false" match that are only queued due to
+ * cache dirtyness.
+ *
+ * 2. Modified, same size and mode, and the object
+ * name of one side is unknown. If they do not
+ * have identical contents, keep them.
+ * They are different.
+ */
+ if ((p->status != DIFF_STATUS_MODIFIED) || /* (1) */
+ (p->one->sha1_valid && p->two->sha1_valid) ||
+ (p->one->mode != p->two->mode) ||
+
+ diff_populate_filespec(p->one, 1) || /* (2) */
+ diff_populate_filespec(p->two, 1) ||
+ (p->one->size != p->two->size) ||
+ diff_populate_filespec(p->one, 0) ||
+ diff_populate_filespec(p->two, 0) ||
+ memcmp(p->one->data, p->two->data, p->one->size))
+ diff_q(&outq, p);
+ else
+ diff_free_filepair(p);
+ }
+ free(q->queue);
+ *q = outq;
+}
+
void diffcore_std(struct diff_options *options)
{
if (options->quiet)
@@ -3160,6 +3199,7 @@ void diffcore_std(struct diff_options *options)
diffcore_order(options->orderfile);
diff_resolve_rename_copy();
diffcore_apply_filter(options->filter);
+ diffcore_remove_empty();
options->has_changes = !!diff_queued_diff.nr;
}
^ permalink raw reply related
* Re: cvs2svn conversion directly to git ready for experimentation
From: Simon 'corecode' Schubert @ 2007-08-02 19:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Michael Haggerty, git, users
In-Reply-To: <EDE86758-FFD0-4CED-A2C9-033FA13DD3B6@zib.de>
Steffen Prohaska wrote:
> I remember that togit reported a broken pipe. My feeling was
> that git-fastimport aborted, which may be reason why tohg
> worked better. I didn't try to understand more details. I never
> read ruby code before and it was already a challenge for me to
> get everything up and running (rcs, rbtree).
yah, that pretty much tells me it is shawn's bug :) but without more details, it is very hard to diagnose. tohg should tell you which rcs revs are the offenders. be sure to use a recent fromcvs however.
cheers
simon
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Marko Macek @ 2007-08-02 19:22 UTC (permalink / raw)
To: Michael Haggerty, git, users, prohaska
In-Reply-To: <46B2132D.7090304@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Michael Haggerty wrote:
> This can definitely be caused by unlabeled branches. It can also be
> caused by branches rooted in a vendor branch. In many cases, such
> branches can actually be grafted onto trunk, but cvs2svn does not (yet)
> attempt this.
It would be nice to be able to exclude the vendor branch if only
the initial commit was made on it (or maybe handle it better, by
remapping the commits to the main branch when they match).
I have tested this on my repository and currently gitk draws
large 'railroad switching stations' because many tags have the
vendor branch as a parent (and in some cases also the parent branch,
in addition to the parent commit).
Mark
[-- Attachment #2: railroad.png --]
[-- Type: image/png, Size: 3828 bytes --]
[-- Attachment #3: Type: text/plain, Size: 193 bytes --]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cvs2svn.tigris.org
For additional commands, e-mail: users-help@cvs2svn.tigris.org
^ 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