* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181231420.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>
>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>> But the original point by Sebastian hasn't been answered. He wanted
>>> to make the command list the stash without arguments.
>>>
>>> This was discussed already in the early days of stash and there indeed
>>> was a suggestion to do so (I think I sided with that), but the users
>>> did not want it. IIRC, the argument went like: "when I say 'stash',
>>> that is because I want a quick and immediate way to stash, and I do
>>> not want a list. If I do not have to have a quick way, I would create
>>> a temporary commit on the current branch, or switch to a temporary
>>> branch and commit there."
>> Well, "git stash save" is just five characters more - I really don't see
>> why this would be less comfortable (and for the really lazy people there
>> are still aliases...). On the other hand (if "list" is the default),
>> we'd get a more consistent interface which imho is imho more important
>> than typing five characters less.
>
> It's more about what you're used to. I had an alias named 'stash' long
> before it became a git command. And now guess how _annoying_ it would be
> to type "git stash<Return><Curse out loud at my mouse>git stash
> save<Return>".
>
Not nearly as annoying as losing work because of it, and you obviously
*know* what to do when you're done cursing, while clueless-newbie-X just
hops away and uses subversion.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Sixt @ 2007-12-18 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, H.Merijn Brand, git
In-Reply-To: <Pine.LNX.4.64.0712181351270.23902@racer.site>
Johannes Schindelin schrieb:
> On Tue, 18 Dec 2007, Johannes Sixt wrote:
>> Johannes Schindelin schrieb:
>>> I'd be cautious about using poll(). AFAIK MacOSX 10.2.8 does not have
>>> poll(), and IIRC I had problems finding it in MinGW, too. I know, we
>>> use it in daemon, upload-archive and upload-pack, but these are not
>>> typically functions performed by a client, so I would not know if it
>>> worked on my (now-dead) iBook, or on msysGit.
>> So what? If we use poll() already in daemon, upload-archive and
>> upload-pack, and no MacOSX 10.2.8 user has spoken up with a proposal for
>> replacement, then yet another use won't raise a complaint, either.
>
> daemon, upload-archive and upload-pack are server-side functions, so they
> are substantially less well tested.
upload-pack is used for local fetches and, therefore, should be
well-tested on all systems.
>> And if it were a problem for msysGit, I wouldn't have suggested it ;)
>> The particular use in pager.c would be inside #ifndef __MINGW32__ #endif
>> anyway.
>
> We still did not integrate the 'daemon' branch of 4msysgit, correct?
No, we didn't.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Don't cache DESTDIR in perl/perl.mak.
From: Gerrit Pape @ 2007-12-18 14:25 UTC (permalink / raw)
To: Pierre Habouzit, Eric Wong, Junio C Hamano, git
In-Reply-To: <20071212200211.GB1060@artemis.madism.org>
On Wed, Dec 12, 2007 at 09:02:11PM +0100, Pierre Habouzit wrote:
> On Wed, Dec 12, 2007 at 06:01:48PM +0000, Eric Wong wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > Hmph. That's reverting this:
> > >
> > > commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
> > > Eric, care to comment?
> >
> > I used to make a statically linked binary package for working on an
> > ancient box that didn't have a lot of libraries I wanted, and I probably
> > just called `make install' into DESTDIR as a single step without calling
> > `make' alone without DESTDIR argument, or I had DESTDIR set in
> > config.mak
>
> Actually this fact generated a bug in debian packaging because git is
> built then installed twice in different DESTDIRS, then parts of the
> install is pruned (the two installs are arch-dependant and
> arch-independant files install so it's a very good reason in term of
> packaging).
>
> The fact that perl.mak caches the DESTDIR make it install things in
> the wrong place because it doesn't honour make DESTDIR=foo install and
> always use the cached value instead, which is wrong.
>
> I think Gerrit won't care if it's cached or not, he just cares that it
> still honours environment if present.
Yes, precisely. Thanks, Gerrit.
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 14:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712181503.10614.jnareb@gmail.com>
On Tue, 18 Dec 2007 15:03:09 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> > On Tue, 18 Dec 2007 13:32:59 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> >> H.Merijn Brand wrote:
> >>> On Tue, 18 Dec 2007 10:14:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> >>>>
> >>>> What is ./configure output in your case?
> >>
> >>> /pro/3gl/LINUX/git-2007-12-17 119> cp /pro/3gl/GNU/gcc/r3/gcc-4.2.2/install-sh install-sh
> >>
> >>> -- uncommented the AC_PROG_INSTALL line ...
> >>
> >>> OK, rebuild configure ...
> >>>
> >>> a5:/pro/3gl/LINUX/git-2007-12-17 129> make configure
> >>> GEN configure
> >>> a5:/pro/3gl/LINUX/git-2007-12-17 130> rm config.{log,status}
> >>> a5:/pro/3gl/LINUX/git-2007-12-17 131> configure --prefix=/pro/local \
> >>> --disable-nls --without-iconv --with-perl=/pro/bin/perl >& config-log
> >>> a5:/pro/3gl/LINUX/git-2007-12-17 132> grep -w install config-log config.log config.status
> >>> config-log:checking for a BSD-compatible install... /opt/imake/bin/install -c
> >>> config.log:configure:2218: checking for a BSD-compatible install
> >>> config.log:configure:2273: result: /opt/imake/bin/install -c
> >>> config.log:ac_cv_path_install='/opt/imake/bin/install -c'
> >>> config.status:INSTALL="/opt/imake/bin/install -c"
> >>
> >> Does chosen by ./configure script 'install' binary, namely
> >> /opt/imake/bin/install works correctly, meaning does it install
> >> git correctly?
> >
> > No. I reported this before, but not to the list. This is why I created
> > my own make-install shell:
>
> I though that you were talking about _default_ 'install' program
> (first in PATH). Is /opt/imake/bin/install used below?
Yes. There is only ONE install program
(that is a small lie, there is also /usr/sbin/install, but that is not
accessible for mortal users)
> I have forgot to tell that beside uncommenting AC_PROG_INSTALL line
> in configure.ac (and doing "make configure") you have to also uncomment
> the "INSTALL = @INSTALL@" in config.mak.in for "make install" to use
> install program found by ./configure script.
But I don't think it found install-sh.
/pro/3gl/LINUX/git-2007-12-17 103 > grep -w install config-log
checking for a BSD-compatible install... /opt/imake/bin/install -c
> > /pro/3gl/LINUX/git-2007-12-17 113> make install
> > SUBDIR git-gui
> > INDEX lib/
> > SUBDIR gitk-git
> > make[1]: Nothing to be done for `all'.
> > SUBDIR perl
> > SUBDIR templates
> > install -d -m 755 '/pro/local/bin'
> > rm: /pro/local/bin/ directory
> > Usage: mv [-f] [-i] [-e warn|force|ignore] f1 f2
> > mv [-f] [-i] [-e warn|force|ignore] f1 ... fn d1
> > mv [-f] [-i] [-e warn|force|ignore] d1 d2
>
> Strange...
>
> By the way, I have took a look at hos ./configure script chooses which
> 'install' to use, and at least for GNU Autoconf 2.59 it does not talk
> about HP-UX at all, and checks binaries to reject by grepping for
> a string, instead of checking if it install files correctly using some
> script (at least checking if it install files and creates directories,
> and accepts install options used, without checking for correct permissions
> and group, etc.).
>
> Relevant fragment of generated ./configure script
http://www.xs4all.nl/~procura/configure
added a 'set -x' there:
configure: CHECKS for programs
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
+ echo configure:2219: checking for a BSD-compatible install
+ 1>& 5
+ echo checking for a BSD-compatible install... \c
+ 1>& 6
checking for a BSD-compatible install... + test -z
+ test = set
+ as_save_IFS=
+ IFS=:
+ IFS=
+ test -z .
+ IFS=
+ test -z /u/usr/merijn/bin/private
+ test -f /u/usr/merijn/bin/private/ginstall
+ test -f /u/usr/merijn/bin/private/scoinst
+ test -f /u/usr/merijn/bin/private/install
+ IFS=
etc etc for the rest of the $PATH ...
+ test -z /opt/imake/bin
+ test -f /opt/imake/bin/ginstall
+ test -f /opt/imake/bin/scoinst
+ test -f /opt/imake/bin/install
+ test install = install
+ grep dspmsg /opt/imake/bin/install
+ 1> /dev/null 2>& 1
+ test install = install
+ grep pwplus /opt/imake/bin/install
+ 1> /dev/null 2>& 1
+ ac_cv_path_install=/opt/imake/bin/install -c
+ break 3
+ test set = set
+ INSTALL=/opt/imake/bin/install -c
+ echo configure:2274: result: /opt/imake/bin/install -c
+ 1>& 5
+ echo /opt/imake/bin/install -c
+ 1>& 6
/opt/imake/bin/install -c
+ exit
+ exit_status=0
+ 1>& 5
+ echo
+ cat
+ 0< /var/tmp/sh8180.20
+ echo
+ 2>& 1
+ 2>& 1
+ sed -n s/'/'\\''/g;
s/^\([_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*_cv_[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*\)=\(.*\)/\1='\2'/p
+ echo
+ cat
+ 0< /var/tmp/sh8180.21
+ echo
+ sort
+ echo SHELL
+ eval ac_val=$SHELL
:
:
+ ac_val=o
+ echo OBJEXT='o'
+ echo INSTALL_PROGRAM
+ eval ac_val=$INSTALL_PROGRAM
+ ac_val=
+ echo INSTALL_PROGRAM=''
+ echo INSTALL_SCRIPT
+ eval ac_val=$INSTALL_SCRIPT
+ ac_val=
+ echo INSTALL_SCRIPT=''
+ echo INSTALL_DATA
+ eval ac_val=$INSTALL_DATA
+ ac_val=
+ echo INSTALL_DATA=''
+ echo AR
+ eval ac_val=$AR
:
:
+ echo
+ test -n
+ test -s confdefs.h
+ cat
+ 0< /var/tmp/sh8180.23
+ echo
+ sed /^$/d confdefs.h
+ sort
+ echo
+ test 0 != 0
+ echo configure: exit 0
+ rm -f core *.core
+ rm -rf conftest* confdefs.h conf8180*
> -- >8 -- configure
>
> # Find a good install program. We prefer a C program (faster),
> # so one script is as good as another. But avoid the broken or
> # incompatible versions:
> # SysV /etc/install, /usr/sbin/install
> # SunOS /usr/etc/install
> # IRIX /sbin/install
> # AIX /bin/install
> # AmigaOS /C/install, which installs bootblocks on floppy discs
> # AIX 4 /usr/bin/installbsd, which doesn't work without a -g flag
> # AFS /usr/afsws/bin/install, which mishandles nonexistent args
> # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
> # OS/2's system install, which has a completely different semantic
> # ./install, which can be erroneously created by make from ./install.sh.
> echo "$as_me:$LINENO: checking for a BSD-compatible install" >&5
> echo $ECHO_N "checking for a BSD-compatible install... $ECHO_C" >&6
> if test -z "$INSTALL"; then
> if test "${ac_cv_path_install+set}" = set; then
> echo $ECHO_N "(cached) $ECHO_C" >&6
> else
> as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> for as_dir in $PATH
> do
> IFS=$as_save_IFS
> test -z "$as_dir" && as_dir=.
> # Account for people who put trailing slashes in PATH elements.
> case $as_dir/ in
> ./ | .// | /cC/* | \
> /etc/* | /usr/sbin/* | /usr/etc/* | /sbin/* | /usr/afsws/bin/* | \
> ?:\\/os2\\/install\\/* | ?:\\/OS2\\/INSTALL\\/* | \
> /usr/ucb/* ) ;;
> *)
> # OSF1 and SCO ODT 3.0 have their own names for install.
> # Don't use installbsd from OSF since it installs stuff as root
> # by default.
> for ac_prog in ginstall scoinst install; do
> for ac_exec_ext in '' $ac_executable_extensions; do
> if $as_executable_p "$as_dir/$ac_prog$ac_exec_ext"; then
> if test $ac_prog = install &&
> grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
> # AIX install. It has an incompatible calling convention.
> :
> elif test $ac_prog = install &&
> grep pwplus "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
> # program-specific install script used by HP pwplus--don't use.
> :
> else
> ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c"
> break 3
> fi
> fi
> done
> done
> ;;
> esac
> done
>
>
> fi
> if test "${ac_cv_path_install+set}" = set; then
> INSTALL=$ac_cv_path_install
> else
> # As a last resort, use the slow shell script. We don't cache a
> # path for INSTALL within a source directory, because that will
> # break other packages using the cache if that directory is
> # removed, or if the path is relative.
> INSTALL=$ac_install_sh
> fi
> fi
> echo "$as_me:$LINENO: result: $INSTALL" >&5
> echo "${ECHO_T}$INSTALL" >&6
>
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Nicolas Pitre @ 2007-12-18 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Pierre Habouzit, spearce, Git Mailing List
In-Reply-To: <7vwsrc1idm.fsf@gitster.siamese.dyndns.org>
On Tue, 18 Dec 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > But there's a few that aren't obviously allocations (this is a list done
> > with grep and sparse, I didn't look at whether the values used are then
> > all allocation-related):
> >
> > - diff-delta.c:250 memsize = sizeof(*index)
>
> I haven't studied this codepath.
Harmless overallocation. Nothing to worry about.
Nicolas
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 14:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <4767D7A2.30703@op5.se>
Hi,
On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 18 Dec 2007, Sebastian Harl wrote:
> >
> > > On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
> > > > But the original point by Sebastian hasn't been answered. He
> > > > wanted to make the command list the stash without arguments.
> > > >
> > > > This was discussed already in the early days of stash and there
> > > > indeed was a suggestion to do so (I think I sided with that), but
> > > > the users did not want it. IIRC, the argument went like: "when I
> > > > say 'stash', that is because I want a quick and immediate way to
> > > > stash, and I do not want a list. If I do not have to have a quick
> > > > way, I would create a temporary commit on the current branch, or
> > > > switch to a temporary branch and commit there."
> > > Well, "git stash save" is just five characters more - I really don't
> > > see why this would be less comfortable (and for the really lazy
> > > people there are still aliases...). On the other hand (if "list" is
> > > the default), we'd get a more consistent interface which imho is
> > > imho more important than typing five characters less.
> >
> > It's more about what you're used to. I had an alias named 'stash'
> > long before it became a git command. And now guess how _annoying_ it
> > would be to type "git stash<Return><Curse out loud at my mouse>git
> > stash save<Return>".
>
> Not nearly as annoying as losing work because of it, and you obviously
> *know* what to do when you're done cursing, while clueless-newbie-X just
> hops away and uses subversion.
Really? Clueless-newbie-X certainly knows how to apply the stash,
otherwise she would not have used the command, right?
In the alternative, you could just scrap all those default actions,
showing synopses instead. For all commands, including "git commit", "git
log", "git fetch", etc.
See?
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 15:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181445420.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>>>
>>>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>>>> But the original point by Sebastian hasn't been answered. He
>>>>> wanted to make the command list the stash without arguments.
>>>>>
>>>>> This was discussed already in the early days of stash and there
>>>>> indeed was a suggestion to do so (I think I sided with that), but
>>>>> the users did not want it. IIRC, the argument went like: "when I
>>>>> say 'stash', that is because I want a quick and immediate way to
>>>>> stash, and I do not want a list. If I do not have to have a quick
>>>>> way, I would create a temporary commit on the current branch, or
>>>>> switch to a temporary branch and commit there."
>>>> Well, "git stash save" is just five characters more - I really don't
>>>> see why this would be less comfortable (and for the really lazy
>>>> people there are still aliases...). On the other hand (if "list" is
>>>> the default), we'd get a more consistent interface which imho is
>>>> imho more important than typing five characters less.
>>> It's more about what you're used to. I had an alias named 'stash'
>>> long before it became a git command. And now guess how _annoying_ it
>>> would be to type "git stash<Return><Curse out loud at my mouse>git
>>> stash save<Return>".
>> Not nearly as annoying as losing work because of it, and you obviously
>> *know* what to do when you're done cursing, while clueless-newbie-X just
>> hops away and uses subversion.
>
> Really? Clueless-newbie-X certainly knows how to apply the stash,
> otherwise she would not have used the command, right?
>
Far too many times I've seen people expect help output if the command
they're running is even remotely dangerous, so they go ahead and run
it without arguments to see what it does.
> In the alternative, you could just scrap all those default actions,
> showing synopses instead. For all commands, including "git commit", "git
> log", "git fetch", etc.
>
Like we do for the git wrapper, you mean? Yes, that would be one solution,
although not a very good one for all commands.
It's probably not a bad idea for commands where the primary use is
something else than producing visual output though, such as tag or branch,
but those handle creation/deletion of stuff, so the default action for them
is to list stuff of the kind they operate on. I fail to see why stash should
be any different.
> See?
>
Not really, no. What was your point?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix test failure due to broken sed on Leopard
From: Wincent Colaiuta @ 2007-12-18 15:11 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
The newly-added common-tail-optimization test fails on Leopard because
the broken sed implementation bails with a spurious "unterminated
substitute pattern" error because of the length of one of the
arguments.
So halve the size of the argument (to 1024 - 1, down from the previous
2048 - 1) to get the test passing again.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t4024-diff-optimize-common.sh | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..bbda816 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -7,26 +7,26 @@ test_description='common tail optimization'
z=zzzzzzzz ;# 8
z="$z$z$z$z$z$z$z$z" ;# 64
z="$z$z$z$z$z$z$z$z" ;# 512
-z="$z$z$z$z" ;# 2048
-z2047=$(expr "$z" : '.\(.*\)') ; #2047
+z="$z$z" ;# 1024
+z1023=$(expr "$z" : '.\(.*\)') ; #1023
test_expect_success setup '
- echo "a$z2047" >file-a &&
+ echo "a$z1023" >file-a &&
echo "b" >file-b &&
- echo "$z2047" >>file-b &&
- echo "c$z2047" | tr -d "\012" >file-c &&
+ echo "$z1023" >>file-b &&
+ echo "c$z1023" | tr -d "\012" >file-c &&
echo "d" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d &&
+ echo "$z1023" | tr -d "\012" >>file-d &&
git add file-a file-b file-c file-d &&
- echo "A$z2047" >file-a &&
+ echo "A$z1023" >file-a &&
echo "B" >file-b &&
- echo "$z2047" >>file-b &&
- echo "C$z2047" | tr -d "\012" >file-c &&
+ echo "$z1023" >>file-b &&
+ echo "C$z1023" | tr -d "\012" >file-c &&
echo "D" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d
+ echo "$z1023" | tr -d "\012" >>file-d
'
@@ -61,7 +61,7 @@ EOF
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ git diff -U0 | sed -e "/^index/d" -e "s/$z1023/Z/g" >actual &&
diff -u expect actual
'
--
1.5.4.rc0.1099.g76fa0-dirty
^ permalink raw reply related
* [PATCH] fix style of a few comments in diff-delta.c
From: Nicolas Pitre @ 2007-12-18 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index 601b49e..a4e28df 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -212,11 +212,24 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
if (hash_count[i] <= HASH_LIMIT)
continue;
- entries -= hash_count[i] - HASH_LIMIT;
/* We leave exactly HASH_LIMIT entries in the bucket */
+ entries -= hash_count[i] - HASH_LIMIT;
entry = hash[i];
acc = 0;
+
+ /*
+ * Assume that this loop is gone through exactly
+ * HASH_LIMIT times and is entered and left with
+ * acc==0. So the first statement in the loop
+ * contributes (hash_count[i]-HASH_LIMIT)*HASH_LIMIT
+ * to the accumulator, and the inner loop consequently
+ * is run (hash_count[i]-HASH_LIMIT) times, removing
+ * one element from the list each time. Since acc
+ * balances out to 0 at the final run, the inner loop
+ * body can't be left with entry==NULL. So we indeed
+ * encounter entry==NULL in the outer loop only.
+ */
do {
acc += hash_count[i] - HASH_LIMIT;
if (acc > 0) {
@@ -229,30 +242,17 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
}
entry = entry->next;
} while (entry);
-
- /* Assume that this loop is gone through exactly
- * HASH_LIMIT times and is entered and left with
- * acc==0. So the first statement in the loop
- * contributes (hash_count[i]-HASH_LIMIT)*HASH_LIMIT
- * to the accumulator, and the inner loop consequently
- * is run (hash_count[i]-HASH_LIMIT) times, removing
- * one element from the list each time. Since acc
- * balances out to 0 at the final run, the inner loop
- * body can't be left with entry==NULL. So we indeed
- * encounter entry==NULL in the outer loop only.
- */
}
free(hash_count);
- /* Now create the packed index in array form rather than
- * linked lists */
-
+ /*
+ * Now create the packed index in array form
+ * rather than linked lists.
+ */
memsize = sizeof(*index)
+ sizeof(*packed_hash) * (hsize+1)
+ sizeof(*packed_entry) * entries;
-
mem = malloc(memsize);
-
if (!mem) {
free(hash);
return NULL;
@@ -269,19 +269,19 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
mem = packed_hash + (hsize+1);
packed_entry = mem;
- /* Coalesce all entries belonging to one linked list into
- * consecutive array entries */
-
for (i = 0; i < hsize; i++) {
+ /*
+ * Coalesce all entries belonging to one linked list
+ * into consecutive array entries.
+ */
packed_hash[i] = packed_entry;
for (entry = hash[i]; entry; entry = entry->next)
*packed_entry++ = entry->entry;
}
- /* Sentinel value to indicate the length of the last hash
- * bucket */
-
+ /* Sentinel value to indicate the length of the last hash bucket */
packed_hash[hsize] = packed_entry;
+
assert(packed_entry - (struct index_entry *)mem == entries);
free(hash);
^ permalink raw reply related
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 15:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <4767E07A.2020100@op5.se>
Hi,
On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > In the alternative, you could just scrap all those default actions,
> > showing synopses instead. For all commands, including "git commit",
> > "git log", "git fetch", etc.
>
> Like we do for the git wrapper, you mean? Yes, that would be one
> solution, although not a very good one for all commands.
Exactly. Not a good one.
> It's probably not a bad idea for commands where the primary use is
> something else than producing visual output though, such as tag or
> branch, but those handle creation/deletion of stuff, so the default
> action for them is to list stuff of the kind they operate on. I fail to
> see why stash should be any different.
I also fail to see why stash should be any different. And that's why I
expect it to have a default operation, which is -- you guessed it --
"stash the changes!"
If I am not sure what I am about to do, there is -- wonder of wonders --
the "-h" option! And indeed:
$ git stash -h
Usage: /home/gitte/bin/git-stash [ | save | list | show | apply |
clear | create ]
So what exactly was your point again?
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Harl, Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181513060.23902@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> In the alternative, you could just scrap all those default actions,
>>> showing synopses instead. For all commands, including "git commit",
>>> "git log", "git fetch", etc.
>> Like we do for the git wrapper, you mean? Yes, that would be one
>> solution, although not a very good one for all commands.
>
> Exactly. Not a good one.
>
>> It's probably not a bad idea for commands where the primary use is
>> something else than producing visual output though, such as tag or
>> branch, but those handle creation/deletion of stuff, so the default
>> action for them is to list stuff of the kind they operate on. I fail to
>> see why stash should be any different.
>
> I also fail to see why stash should be any different. And that's why I
> expect it to have a default operation, which is -- you guessed it --
> "stash the changes!"
>
Actually, I guessed "list the stashes".
> If I am not sure what I am about to do, there is -- wonder of wonders --
> the "-h" option! And indeed:
>
> $ git stash -h
> Usage: /home/gitte/bin/git-stash [ | save | list | show | apply |
> clear | create ]
>
> So what exactly was your point again?
>
My point is that it would be nice if all git commands that actually
manipulate objects (create/delete/modify) had a safe default, and
that experienced users such as yourself could endure the insufferable
agony of retraining your fingers to type five more chars so that
people won't have to get bitten by surprises.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Wincent Colaiuta @ 2007-12-18 15:28 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Sebastian Harl, Junio C Hamano,
Benoit Sigoure, git
In-Reply-To: <4767D7A2.30703@op5.se>
El 18/12/2007, a las 15:22, Andreas Ericsson escribió:
> Johannes Schindelin wrote:
>> Hi,
>> On Tue, 18 Dec 2007, Sebastian Harl wrote:
>>> On Mon, Dec 17, 2007 at 04:31:12PM -0800, Junio C Hamano wrote:
>>>> But the original point by Sebastian hasn't been answered. He
>>>> wanted to make the command list the stash without arguments.
>>>>
>>>> This was discussed already in the early days of stash and there
>>>> indeed was a suggestion to do so (I think I sided with that), but
>>>> the users did not want it. IIRC, the argument went like: "when I
>>>> say 'stash', that is because I want a quick and immediate way to
>>>> stash, and I do not want a list. If I do not have to have a
>>>> quick way, I would create a temporary commit on the current
>>>> branch, or switch to a temporary branch and commit there."
>>> Well, "git stash save" is just five characters more - I really
>>> don't see why this would be less comfortable (and for the really
>>> lazy people there are still aliases...). On the other hand (if
>>> "list" is the default), we'd get a more consistent interface which
>>> imho is imho more important than typing five characters less.
>> It's more about what you're used to. I had an alias named 'stash'
>> long before it became a git command. And now guess how _annoying_
>> it would be to type "git stash<Return><Curse out loud at my
>> mouse>git stash save<Return>".
>
> Not nearly as annoying as losing work because of it, and you obviously
> *know* what to do when you're done cursing, while clueless-newbie-X
> just
> hops away and uses subversion.
There's not really any peril of losing work here, seeing as this
should be a lossless round trip:
git stash
# oops! didn't mean to save
git stash apply
We could help clueless-newbie-X here by augmenting the save output:
Saved "WIP on master: 8ed8a26... s"
HEAD is now at 8ed8a26... s
As follows (or similar):
Saved working directory and index state "WIP on master: 8ed8a26... s"
(To restore them type "git stash apply")
HEAD is now at 8ed8a26... s
ie. we explicitly tell them what was saved (their working directory
and index state), and also how to get it back immediately if that's
not what they meant to do. Something like this (no doubt will be
whitespace-mangled because I'm pasting this into my email client, but
it's just to demo the idea):
diff --git a/git-stash.sh b/git-stash.sh
index f16fd9c..a2f3723 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -99,7 +99,8 @@ save_stash () {
git update-ref -m "$stash_msg" $ref_stash $w_commit ||
die "Cannot save the current status"
- printf >&2 'Saved "%s"\n' "$stash_msg"
+ printf >&2 'Saved working directory and index state "%s"\n'
"$stash_msg"
+ echo >&2 '(To restore them type "git stash apply")'
}
have_stash () {
Cheers,
Wincent
^ permalink raw reply related
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Jakub Narebski @ 2007-12-18 15:40 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Sebastian Harl, Junio C Hamano,
Benoit Sigoure, git
In-Reply-To: <4767E717.2060902@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>>> Johannes Schindelin wrote:
>>>
>>>> In the alternative, you could just scrap all those default
>>>> actions, showing synopses instead. For all commands, including
>>>> "git commit", "git log", "git fetch", etc.
>>>
>>> Like we do for the git wrapper, you mean? Yes, that would be one
>>> solution, although not a very good one for all commands.
>>
>> Exactly. Not a good one.
>>
>>> It's probably not a bad idea for commands where the primary use is
>>> something else than producing visual output though, such as tag or
>>> branch, but those handle creation/deletion of stuff, so the default
>>> action for them is to list stuff of the kind they operate on. I
>>> fail to see why stash should be any different.
>>
>> I also fail to see why stash should be any different. And that's why
>> I expect it to have a default operation, which is -- you guessed it --
>> "stash the changes!"
>
> Actually, I guessed "list the stashes".
>
>> If I am not sure what I am about to do, there is -- wonder of wonders --
>> the "-h" option! And indeed:
>> $ git stash -h
>> Usage: /home/gitte/bin/git-stash [ | save | list | show |
>> apply | clear | create ]
>> So what exactly was your point again?
>>
>
> My point is that it would be nice if all git commands that actually
> manipulate objects (create/delete/modify) had a safe default, and
> that experienced users such as yourself could endure the insufferable
> agony of retraining your fingers to type five more chars so that
> people won't have to get bitten by surprises.
Also for "git commit"?
In my opinion _basic_ usage of git-stash is simply using it with
one stash only: "git stash" / "git unstash" (i.e. "git stash apply";
by the way this is one (beside "git view") use case for builtin
predefined aliases). Using it with multiple stashes (only then
"git stash list" is needed) is advanced usage; and for advanced
usage longer form is preferred, I think.
"git branch", "git log" and "git remote" are horse of differenc color
because the _cannot_ function without name of branch/tag/remote given,
so hey provide "list" when no name was given.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Add format-patch option --no-name-prefix.
From: Pascal Obry @ 2007-12-18 15:42 UTC (permalink / raw)
To: git; +Cc: pascal
This option can be used to generate a patch file
where file names are relative to the Git root
directory. Such a patch can then be applied with
the standard patch tool using option -p0.
Signed-off-by: Pascal Obry <pascal@obry.net>
---
Documentation/git-format-patch.txt | 6 +++++-
builtin-log.c | 7 ++++++-
diff.c | 10 ++++++++--
diff.h | 1 +
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 6fb9429..5a642ad 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -15,7 +15,7 @@ SYNOPSIS
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
- [--ignore-if-in-upstream]
+ [--ignore-if-in-upstream] [--no-name-prefix]
[--subject-prefix=Subject-Prefix]
[ <since> | <revision range> ]
@@ -90,6 +90,10 @@ include::diff-options.txt[]
without the default first line of the commit appended.
Mutually exclusive with the --stdout option.
+--no-name-prefix::
+ Generate a patch file that can be applied with a patch(1) -p0
+ from the Git root directory.
+
-k|--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
diff --git a/builtin-log.c b/builtin-log.c
index cc3cc90..36582bd 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -599,6 +599,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
int subject_prefix = 0;
int ignore_if_in_upstream = 0;
int thread = 0;
+ int no_name_prefix = 0;
const char *in_reply_to = NULL;
struct patch_ids ids;
char *add_signoff = NULL;
@@ -636,6 +637,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
}
else if (!prefixcmp(argv[i], "--start-number="))
start_number = strtol(argv[i] + 15, NULL, 10);
+ else if (!prefixcmp(argv[i], "--no-name-prefix"))
+ no_name_prefix = 1;
else if (!strcmp(argv[i], "--numbered-files"))
numbered_files = 1;
else if (!strcmp(argv[i], "--start-number")) {
@@ -719,8 +722,10 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
die ("unrecognized argument: %s", argv[1]);
if (!rev.diffopt.output_format)
- rev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY | DIFF_FORMAT_PATCH;
+ rev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY | DIFF_FORMAT_PATCH | DIFF_FORMAT_NAME_PREFIX;
+ if (no_name_prefix)
+ rev.diffopt.output_format &= ~DIFF_FORMAT_NAME_PREFIX;
if (!DIFF_OPT_TST(&rev.diffopt, TEXT))
DIFF_OPT_SET(&rev.diffopt, BINARY);
diff --git a/diff.c b/diff.c
index e26584c..f07d9c0 100644
--- a/diff.c
+++ b/diff.c
@@ -1212,8 +1212,14 @@ static void builtin_diff(const char *name_a,
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
- a_one = quote_two("a/", name_a + (*name_a == '/'));
- b_two = quote_two("b/", name_b + (*name_b == '/'));
+ if (o->output_format & DIFF_FORMAT_NAME_PREFIX) {
+ a_one = quote_two("a/", name_a + (*name_a == '/'));
+ b_two = quote_two("b/", name_b + (*name_b == '/'));
+ }
+ else {
+ a_one = quote_two("", name_a + (*name_a == '/'));
+ b_two = quote_two("", name_b + (*name_b == '/'));
+ }
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
diff --git a/diff.h b/diff.h
index 7e8000a..86458a3 100644
--- a/diff.h
+++ b/diff.h
@@ -30,6 +30,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_FORMAT_SUMMARY 0x0008
#define DIFF_FORMAT_PATCH 0x0010
#define DIFF_FORMAT_SHORTSTAT 0x0020
+#define DIFF_FORMAT_NAME_PREFIX 0x0040
/* These override all above */
#define DIFF_FORMAT_NAME 0x0100
--
1.5.4.rc0.56.g6fbe
^ permalink raw reply related
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Pascal Obry @ 2007-12-18 15:47 UTC (permalink / raw)
To: git
In-Reply-To: <1197992574-3464-1-git-send-email-pascal@obry.net>
To give a bit of context about this patch. I need to send changeset to a
server by e-mail for testing purpose before committing. The server is
assuming that the patch can be applied with "patch -p0 < file" from the
repository root. The option --no-name-prefix does just that, removing
the leading 'a/' and 'b/'.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Johannes Sixt @ 2007-12-18 15:54 UTC (permalink / raw)
To: Pascal Obry; +Cc: git, pascal
In-Reply-To: <1197992574-3464-1-git-send-email-pascal@obry.net>
Pascal Obry schrieb:
> This option can be used to generate a patch file
> where file names are relative to the Git root
> directory. Such a patch can then be applied with
> the standard patch tool using option -p0.
While I've always wondered what the a/ and b/ prefixes were good for (and
I still do), I also wonder what's so different between typing
patch -p0
and
patch -p1
that we need another diff option for it. Ok, on my keyboard 0 is typed
with the right hand, and 1 with the left hand, but... ??
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Pascal Obry @ 2007-12-18 15:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pascal Obry, git
In-Reply-To: <4767ED52.9010004@viscovery.net>
Johannes Sixt a écrit :
> that we need another diff option for it. Ok, on my keyboard 0 is typed
> with the right hand, and 1 with the left hand, but... ??
Because you just did not read my follow-up message :)
I need this has I do not have the way to change the server applying the
patch. So nothing wrong with my hands or fingers :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Andreas Ericsson @ 2007-12-18 16:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git, pascal
In-Reply-To: <1197992574-3464-1-git-send-email-pascal@obry.net>
Pascal Obry wrote:
> int thread = 0;
> + int no_name_prefix = 0;
Do we not need no double negations, yes?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-18 16:06 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Sebastian Harl, Junio C Hamano,
Benoit Sigoure, git
In-Reply-To: <m3lk7sovt0.fsf@roke.D-201>
Jakub Narebski wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Johannes Schindelin wrote:
>>> On Tue, 18 Dec 2007, Andreas Ericsson wrote:
>>>> Johannes Schindelin wrote:
>>>>
>>>>> In the alternative, you could just scrap all those default
>>>>> actions, showing synopses instead. For all commands, including
>>>>> "git commit", "git log", "git fetch", etc.
>>>> Like we do for the git wrapper, you mean? Yes, that would be one
>>>> solution, although not a very good one for all commands.
>>> Exactly. Not a good one.
>>>
>>>> It's probably not a bad idea for commands where the primary use is
>>>> something else than producing visual output though, such as tag or
>>>> branch, but those handle creation/deletion of stuff, so the default
>>>> action for them is to list stuff of the kind they operate on. I
>>>> fail to see why stash should be any different.
>>> I also fail to see why stash should be any different. And that's why
>>> I expect it to have a default operation, which is -- you guessed it --
>>> "stash the changes!"
>> Actually, I guessed "list the stashes".
>>
>>> If I am not sure what I am about to do, there is -- wonder of wonders --
>>> the "-h" option! And indeed:
>>> $ git stash -h
>>> Usage: /home/gitte/bin/git-stash [ | save | list | show |
>>> apply | clear | create ]
>>> So what exactly was your point again?
>>>
>> My point is that it would be nice if all git commands that actually
>> manipulate objects (create/delete/modify) had a safe default, and
>> that experienced users such as yourself could endure the insufferable
>> agony of retraining your fingers to type five more chars so that
>> people won't have to get bitten by surprises.
>
> Also for "git commit"?
>
git commit has a very safe default; It runs "git status" and exits.
> In my opinion _basic_ usage of git-stash is simply using it with
> one stash only: "git stash" / "git unstash" (i.e. "git stash apply";
> by the way this is one (beside "git view") use case for builtin
> predefined aliases). Using it with multiple stashes (only then
> "git stash list" is needed) is advanced usage; and for advanced
> usage longer form is preferred, I think.
>
Perhaps. I'll stop quibbling about it. I don't care very deeply
about it anyway.
> "git branch", "git log" and "git remote" are horse of differenc color
> because the _cannot_ function without name of branch/tag/remote given,
> so hey provide "list" when no name was given.
>
git stash takes a name too. It's optional though, and has caused any
number of source lines to be rewritten by grumbling authors who just
started to like git a little less because of it (yes, I know that has
been fixed, but it makes me look twice when discussing defaults for
git stash).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-18 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071218052115.GA13422@diana.vm.bytemark.co.uk>
Thanks again for maintaining these branches.
On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> git://repo.or.cz/stgit/kha.git safe
>
> David Kågedal (17):
[...]
> Simplify merge_recursive
> Use the output from merge-recursive to list conflicts
I'll drop git.merge() entirely since it is only used by the 'sync'
command due to the performance issues I had in the past with rename
detection in git-merge-recursive. Hopefully, these are gone now.
I'll try to fix the automatic invocation of the interactive merger in
case of conflicts (it is only present in git.merge()).
> Karl Hasselström (24):
> Fix "stg resolved" to work with new conflict representation
For some reason, the interactive resolving keeps invoking the merger.
I'll have a look.
> "stg status --reset" is not needed anymore
I would keep this as an alias for 'git reset --hard' (see below as well).
> Remove "stg add"
> Remove "stg rm"
> Remove "stg cp"
I plan to add a generic command for these kind of aliases. The reason
is that I don't really like mixing GIT and StGIT commands (I think at
some point I'll get confused and try to run stg commands with git).
> Remove "stg resolved"
I'd like to keep this command. git-mergetool doesn't support the tool
I use (emacs + ediff and more stgit-specific file extensions like
current, patch etc.). I also don't find 'git add' to be meaningful for
marking a conflict as solved.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Pascal Obry @ 2007-12-18 16:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, git
In-Reply-To: <4767EF5B.3010600@op5.se>
Andreas Ericsson a écrit :
> Pascal Obry wrote:
>> int thread = 0;
>> + int no_name_prefix = 0;
>
> Do we not need no double negations, yes?
Not sure, looks clearer to use variable name corresponding to the option
name to me...
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 16:11 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Sebastian Harl, Junio C Hamano, Benoit Sigoure,
git
In-Reply-To: <4767EFFA.1070909@op5.se>
Hi,
On Tue, 18 Dec 2007, Andreas Ericsson wrote:
> Jakub Narebski wrote:
>
> > Andreas Ericsson <ae@op5.se> writes:
> >
> > > My point is that it would be nice if all git commands that actually
> > > manipulate objects (create/delete/modify) had a safe default, and
> > > that experienced users such as yourself could endure the
> > > insufferable agony of retraining your fingers to type five more
> > > chars so that people won't have to get bitten by surprises.
> >
> > Also for "git commit"?
>
> git commit has a very safe default; It runs "git status" and exits.
Not in my universe. It starts an editor, and then commits what I staged.
> > In my opinion _basic_ usage of git-stash is simply using it with one
> > stash only: "git stash" / "git unstash" (i.e. "git stash apply"; by
> > the way this is one (beside "git view") use case for builtin
> > predefined aliases). Using it with multiple stashes (only then "git
> > stash list" is needed) is advanced usage; and for advanced usage
> > longer form is preferred, I think.
> >
>
> Perhaps. I'll stop quibbling about it. I don't care very deeply about it
> anyway.
Ah. That explains why you made a case against the default operation ;-)
Ciao,
Dscho
^ permalink raw reply
* git-svn fix for broken symlinks
From: Sverre Johansen @ 2007-12-18 16:11 UTC (permalink / raw)
To: git
Hi,
There is a bug in older versions of SVN that makes it possible to create
symlinks where the target is not the path to the file, but instead the
content of the target file. The bug is described here [0].
This breaks git-svn because it expects files which is marked as symlinks
to have the content "link: <filename>".
There was a thread about this back in July, resulting in this patch [1]. Is that
patch planned to be merged anytime soon? I'm using it, and it works great
for me.
[0]: http://subversion.tigris.org/issues/show_bug.cgi?id=2692
[1]: http://kerneltrap.org/mailarchive/git/2007/7/19/252025
--
Sverre Johansen
^ permalink raw reply
* [PATCH] Teach diff machinery to display other prefixes than "a/" and "b/"
From: Johannes Schindelin @ 2007-12-18 16:21 UTC (permalink / raw)
To: Pascal Obry; +Cc: git, pascal
In-Reply-To: <1197992574-3464-1-git-send-email-pascal@obry.net>
With the new option "--prefix=<prefix1>[:<prefix2>]" you can change
the shown prefix, or suppress it (by specifying the empty string).
Initial patch by Pascal Obry.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 18 Dec 2007, Pascal Obry wrote:
> This option can be used to generate a patch file
> where file names are relative to the Git root
> directory. Such a patch can then be applied with
> the standard patch tool using option -p0.
How about this instead? It is not much longer, but more
versatile, as you can actually change the prefix, and not only in
format-patch.
Oh, and if somebody has a better idea for the name of the option,
I would appreciate your input.
Documentation/diff-options.txt | 4 ++++
diff.c | 29 +++++++++++++++++++++--------
diff.h | 1 +
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9ecc1d7..672a2d0 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -211,5 +211,9 @@ endif::git-format-patch[]
--no-ext-diff::
Disallow external diff drivers.
+--prefix=<prefix1>[:<prefix2>]::
+ Show the given path prefixes instead of "a/" and "b/". Leave
+ it empty to show no prefix at all.
+
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
diff --git a/diff.c b/diff.c
index e26584c..404ba91 100644
--- a/diff.c
+++ b/diff.c
@@ -290,9 +290,10 @@ static void emit_rewrite_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
struct diff_filespec *two,
- int color_diff)
+ struct diff_options *o)
{
int lc_a, lc_b;
+ int color_diff = DIFF_OPT_TST(o, COLOR_DIFF);
const char *name_a_tab, *name_b_tab;
const char *metainfo = diff_get_color(color_diff, DIFF_METAINFO);
const char *fraginfo = diff_get_color(color_diff, DIFF_FRAGINFO);
@@ -309,9 +310,9 @@ static void emit_rewrite_diff(const char *name_a,
diff_populate_filespec(two, 0);
lc_a = count_lines(one->data, one->size);
lc_b = count_lines(two->data, two->size);
- printf("%s--- a/%s%s%s\n%s+++ b/%s%s%s\n%s@@ -",
- metainfo, name_a, name_a_tab, reset,
- metainfo, name_b, name_b_tab, reset, fraginfo);
+ printf("%s--- %s%s%s%s\n%s+++ %s%s%s%s\n%s@@ -",
+ metainfo, o->a_prefix, name_a, name_a_tab, reset,
+ metainfo, o->b_prefix, name_b, name_b_tab, reset, fraginfo);
print_line_count(lc_a);
printf(" +");
print_line_count(lc_b);
@@ -1212,8 +1213,8 @@ static void builtin_diff(const char *name_a,
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
- a_one = quote_two("a/", name_a + (*name_a == '/'));
- b_two = quote_two("b/", name_b + (*name_b == '/'));
+ a_one = quote_two(o->a_prefix, name_a + (*name_a == '/'));
+ b_two = quote_two(o->b_prefix, name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
@@ -1242,8 +1243,7 @@ static void builtin_diff(const char *name_a,
if ((one->mode ^ two->mode) & S_IFMT)
goto free_ab_and_return;
if (complete_rewrite) {
- emit_rewrite_diff(name_a, name_b, one, two,
- DIFF_OPT_TST(o, COLOR_DIFF));
+ emit_rewrite_diff(name_a, name_b, one, two, o);
o->found_changes = 1;
goto free_ab_and_return;
}
@@ -2020,6 +2020,9 @@ void diff_setup(struct diff_options *options)
else
DIFF_OPT_CLR(options, COLOR_DIFF);
options->detect_rename = diff_detect_rename_default;
+
+ options->a_prefix = "a/";
+ options->b_prefix = "b/";
}
int diff_setup_done(struct diff_options *options)
@@ -2291,6 +2294,16 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (40 < options->abbrev)
options->abbrev = 40;
}
+ else if (!strcmp(arg, "--prefix=")) {
+ char *colon = strchr(arg + 9, ':');
+ options->a_prefix = arg + 9;
+ if (colon) {
+ *colon = '\0';
+ options->b_prefix = colon + 1;
+ }
+ else
+ options->b_prefix = options->a_prefix;
+ }
else
return 0;
return 1;
diff --git a/diff.h b/diff.h
index 7e8000a..beccf85 100644
--- a/diff.h
+++ b/diff.h
@@ -69,6 +69,7 @@ struct diff_options {
const char *orderfile;
const char *pickaxe;
const char *single_follow;
+ const char *a_prefix, *b_prefix;
unsigned flags;
int context;
int break_opt;
--
1.5.4.rc0.70.g30f7
^ permalink raw reply related
* Re: preventing a push
From: Linus Torvalds @ 2007-12-18 16:32 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <4767BDD8.9080404@melosgmbh.de>
On Tue, 18 Dec 2007, Christoph Duelli wrote:
>
> Is there a (recommended?) way to prevent accidental pushing (or pulling) from
> one repository into another (like the level command from bk days)?
I used BK for years, never knew about any level thing. I assume that was
some way to introduce an "ordering" between repositories, where you could
only push/pull in a controlled manner?
There's no obvious way to do exactly that, but the hooks git has may or
may not be ok. For example, if you want to disallow pushing into some
repository entirely (because you _only_ expect people to pull into it),
you should be able to just make a "pre-receive" hook that always returns
false. See Documentation/hooks.txt.
NOTE! There is no way to figure out what the pushing repository status is,
which is why I say there is no way to do a "level"-equivalent thing
(assuming I guessed what "level" does from the name). However, depending
on how you allow people to access the machine, the hook obviously can look
at things like $USER or other environment variables (ie you could make it
look at what machine the user connected from etc).
But nothing really ever identifies the source repository (on a "git
level") for a push: as far as git is concerned, all repositories are
equal, and your hooks would invariably have to use non-git knowledge to
figure out whether some operation should be allowed or not.
Linus
^ 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