* [PATCH] checkout: be quiet if not on isatty()
From: Steffen Daode Nurpmeso @ 2011-08-27 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Daode Nurpmeso, Tay Ray Chuan, git
In-Reply-To: <7vwrg5u7oz.fsf@alter.siamese.dyndns.org>
(Original subject was:
Re: [PATCH] progress: use \r as EOL only if isatty(stderr) is true)
@ Junio C Hamano <gitster@pobox.com> wrote (2011-06-28 20:33+0200):
> [..]
> I thought that we try to disable the progress pretty much
> everywhere when we are not talking to a tty[..]
Today i got this by accident:
================================================================
openbsd-src.git-null: performing reduce
Checking out files: 17% (11410/65508) ^MChecking out files:
18% (11792/65508) ^M [..]
This is the output of my dumb arena-manager, which i append after
the first scissor for reference. (Maybe someone finds it useful.
It's a dumb sh(1) thing, i don't do shell scripting that often.)
I haven't actually tried it yet, but setting .quiet for
unpack_trees may stop this output. (Compilation succeeds,
though.) I still and *truly* have no idea of the git(1)
internals, so i may oversee .. just *any* thinkable side-effect.
Hope this helps a bit.
(Actual patch as response. Have a nice weekend.)
--Steffen
Ciao, sdaoden(*)(gmail.com)
ASCII ribbon campaign ( ) More nuclear fission plants
against HTML e-mail X can serve more coloured
and proprietary attachments / \ and sounding animations
-- >8 --
#!/bin/bash
# NOTE: this acts according to extensions, e.g.:
# docutils.svn-git-null: git svn
# groff.cvs-git-null : git cvsimport
# openbsd-src.git-null : git
# vim.hg-null : Mercurial
# If a '-null' is in the suffix one may use 'reduce' and 'expand'
# modes; for git(1) these modes require an empty NULL branch:
# $ git co --orphan NULL && git rm -rf '*' &&
# echo DEFAULT-BRANCH >NULL && git add NULL && git ci -m NULL
# Mercurial has builtin support for 'null'. (Nice for backups.)
# Top dir where everything happens
ARENA="$HOME/arena/code.extern.repos"
##
GIT=git
HG=hg
SVN=svn
CVS='cvs -fz 9 update -ACRPd'
ESTAT=0
LOGFILE=lastlog.txt
CVSROOT=/nonexistent
CURR=/nonexistent
log() {
echo "$*"
echo "$*" >> $LOGFILE
}
logerr() {
echo >&2 "ERROR: $*"
echo "ERROR: $*" >> $LOGFILE
ESTAT=1
}
SEP='================================================================'
intro() {
log ''
log $SEP
log $1
}
final() {
local es=$?
if test $es -eq 0; then
log "... ok: $1"
else
logerr "$1"
ESTAT=$es
fi
log $SEP
log ''
}
if test "$BASH" = x""; then
echo >&2 "This script needs the GNU bash shell interpreter"
exit 1
fi
cd $ARENA || {
echo >&2 "Failed to chdir to $ARENA"
exit 1
}
rm -rf $LOGFILE || {
echo >&2 "Failed to remove stale $LOGFILE"
exit 1
}
MODE="$1"
shift
PARAMS="$@"
set -u
test $# -ne 0 || PARAMS=$(echo *.*)
# Perform basename cleanup and move over to $params[]
log "$0: script startup, mode $MODE"
declare -a params
for rd in $PARAMS; do
rd=$(echo "$rd" | sed -Ee 's/(.+)\/+$/\1/' -e 's/.*\/([^/]+)$/\1/')
params[${#params[*]}]="$rd"
done
GITDID=
case "$MODE" in
reduce|expand)
if test "$MODE" == 'reduce'; then
git_branch='NULL'
hg_branch='null'
else
git_branch=
hg_branch=''
fi
for rd in ${params[@]}; do
if test "$rd" == "${rd/null/}"; then
log "[$rd: $MODE does not apply]"
continue
fi
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
if test "$rd" != "${rd/git-null}"; then
# On branch NULL file NULL contains master branch's name
if test -z "$git_branch"; then
if test -f NULL; then
git_branch=$(<NULL)
else
echo >&2 "No file NULL in $rd"
git_branch=master
fi
fi
$GIT checkout $git_branch
else
$HG up $hg_branch
fi
exit $?
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
update)
for rd in ${params[@]}; do
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
if test "$rd" != "${rd/.git}"; then
#$GIT pull -v --ff-only --stat --prune
$GIT fetch --verbose --prune
GITDID=1
elif test "$rd" != "${rd/.svn-git}"; then
$GIT svn rebase
GITDID=1
elif test "$rd" != "${rd/.cvs-git}"; then
ldir='.git/.cvsps'
tar xjf "$ldir.tbz" || {
echo >&2 "$rd: bail: tar xjf $ldir.tbz"
exit 1
}
hdir="$HOME/.cvsps"
test -d "$hdir" || mkdir "$hdir" || {
echo >&2 "$rd: failed to create $hdir directory"
exit 2
}
root="$ldir/CVSROOT"
repo="$ldir/MODULE"
cache=$(<$ldir/CVSPS_FILE)
mv -f "$ldir/cvs-revisions" .git/
mv -f "$ldir/$cache" "$hdir/$cache"
$GIT cvsimport -aR -r origin -p '-u,--cvs-direct' \
-d $(<$root) $(<$repo)
es=$?
GITDID=1
mv -f .git/cvs-revisions "$ldir/"
mv -f "$hdir/$cache" "$ldir/$cache"
tar cjf "$ldir.tbz" "$ldir" || {
echo >&2 "$rd: bail: tar cjf $ldir.tbz $ldir"
exit 3
}
rm -rf $ldir
exit $es
elif test "$rd" != "${rd/.hg}"; then
$HG -v pull #-u
elif test "$rd" != "${rd/.svn}"; then
$SVN update
elif test "$rd" != "${rd/.cvs}"; then
$CVS
else
echo "Unknown revision-control-system: $rd"
exit 1
fi
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
fullgc|gc)
gct=
test "$MODE" == fullgc && gct=--aggressive
for rd in ${params[@]}; do
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
test "$rd" != "${rd/.git}" && git gc $gct
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
*)
echo 'USAGE: manager reduce|expand|update|gc|fullgc LIST-OF-DIRECTORIES'
exit 1
;;
esac
test x"$GITDID" != x && log 'git(1) fetched data - do arena-manager [full]gc ..'
test $ESTAT -ne 0 && log 'Errors occurred!'
exit $ESTAT
# vim:set fenc=utf-8 filetype=sh syntax=sh ts=4 sts=4 sw=4 et tw=79:
^ permalink raw reply
* Re: Files that cannot be added to the index
From: Shaun Ruffell @ 2011-08-27 19:26 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, seanh, git
In-Reply-To: <20110827184009.GA12767@digium.com>
On Sat, Aug 27, 2011 at 01:40:09PM -0500, Shaun Ruffell wrote:
>
> So, in summary, it looks like this is fixed.
Actually, after playing with it a little more on OSX, I think it was
just operator error on my part and that, for this, the versions are
behaving the same.
Adding a non-existent file produces an error:
$ git add adjaskdj
fatal: pathspec 'adjaskdj' did not match any files
Adding a file that is on the filesystem but only differs in case with a
file in the index silently fails:
$ mv Makefile makefile
$ echo "hello" >> makefile
$ git ls-files -m
Makefile
$ git add makefile
And then when you try to commit the file you just added it fails:
$ git commit
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Makefile
#
no changes added to commit (use "git add" and/or "git commit -a")
Adding a file that is in the index, but only differs by case with a file
in the filesystem works:
$ git add Makefile
$ git commit -m "test"
[master 8de0bd6] test
1 files changed, 1 insertions(+), 0 deletions(-)
^ permalink raw reply
* "git submodule foreach" very slow ...
From: rupert THURNER @ 2011-08-27 19:07 UTC (permalink / raw)
To: git
git usually is lightning fast, it even knows how many processor
threads are available and uses them. for a test i converted
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg into a git
repository with one subrepository for every directory. rebasing takes
now 3 hours, while git without subrepositories takes 10 minutes.
$ ls -1 | wc
1162 1162 9527
$ time git submodule foreach git svn rebase
....
real 199m29.626s
user 60m49.631s
sys 70m51.888s
contrary, if one creates one git repository for all these little
directories, rebasing is twenty times faster:
$ time git svn rebase
...
real 10m1.032s
user 5m33.632s
sys 2m53.955s
rupert
^ permalink raw reply
* Re: [PATCH 1/4] t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
From: Junio C Hamano @ 2011-08-27 18:50 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, hilco.wijbenga, david
In-Reply-To: <1314406767-17832-1-git-send-email-drafnel@gmail.com>
Thanks; will queue all four patches.
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Junio C Hamano @ 2011-08-27 18:46 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeff King, Johan Herland, Jonathan Nieder
In-Reply-To: <4E587CC0.4090508@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> 1. The extra information typed into the email series is not archived in
> the git repository, and therefore the emails have to be kept around.
The convention is to have information that is not meant to be kept around
after '---', so...
> 2. If it is discovered between "git format-patch" and "git send-email"
> that one of the patches needs a tweak, then the email series has to be
> generated anew and all of the hand-edits need to be redone.
I actually often work this backwards. Tweak the patch files, apply them to
commit that they are meant to be applied, retest and then finally send.
There is no "generating anew" involved.
> 4. There is no place to store the "additional information" (the part
> that comes in patch emails between the "---" and the diffstat) while
> working on the patch series;...
I thought there was a RFC floating around to do this using notes and also
teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
one of the J's were involved, so I am CC'ing them.
^ permalink raw reply
* Re: [PATCH v2 2/2] Forbid DEL characters in reference names
From: Junio C Hamano @ 2011-08-27 18:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, cmn
In-Reply-To: <1314418364-2532-3-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Please check that the uses of "printf" in the test script are portable
> and quoted correctly.
> ...
> +invalid_ref "$(printf 'heads/foo\t')"
> +invalid_ref "$(printf 'heads/foo\177')"
> +valid_ref "$(printf 'heads/fu\303\237')"
I think these should be fine.
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Junio C Hamano @ 2011-08-27 18:30 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, cmn
In-Reply-To: <4E58710B.60507@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 08/27/2011 06:12 AM, Michael Haggerty wrote:
>> And add tests that such refnames are accepted and normalized
>> correctly.
>
> ...oops, I just noticed that you have committed a this same patch to pu
> already, but with a better log message. Please retain that version.
Thanks. Very much appreciated.
It sometimes gets frustrating to see a re-rolled submission that ignores
the fix-ups to messages and patches I make locally before queued to 'pu'.
It is easy for me to say that they should fetch 'pu' to see what is queued
before resubmitting, but I've been wondering if there is a better way to
communicate back such differences, so that submitters can easily sanity
check to see if my fix-ups are sensible, and to ensure that the re-rolled
patches do not discard them by mistake before submitting.
I could post what are queued in new topics back to the list as part of
ack, but that would make the list too noisy to read.
^ permalink raw reply
* Re: Files that cannot be added to the index
From: Shaun Ruffell @ 2011-08-27 18:40 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, seanh, git
In-Reply-To: <20110827060718.GA28136@sigill.intra.peff.net>
On Sat, Aug 27, 2011 at 02:07:18AM -0400, Jeff King wrote:
> On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:
>
> > On Fri, Aug 26, 2011 at 10:59:19PM +0200, seanh wrote:
> > > I'm using git version 1.7.4.4 on OSX Lion, from macports. (I was
> > > having the problem on Snow Leopard too.)
> >
> > Not sure if this is your problem exactly but awhile back I ran into
> > something similar to what you describe and tracked it down to the
> > fact that my filesystem was case insensitive. i.e.
>
> I think both of you may be seeing the same bug I tracked down here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/173612/focus=174634
>
> Does the patch from the very end of the thread solve the problem for
> you? I should probably clean it up for inclusion in git.
I was going to apply the patch and see what happens, however when I
built and tested 1.7.6 as a baseline I no longer could reproduce the
issue.
$ git commit -m "Makefile"
[master a931b27] Makefile
1 files changed, 0 insertions(+), 222 deletions(-)
delete mode 100644 Makefile
create mode 100644 makefile
$ git ls-files -m
The previous version I had installed from one of the OSX package
managers (not sure if it was fink or Macports) was 1.6.5.3.
NOTE: I had to compile git from source like "NO_FINK=1 make" in
order to avoid the "ld: warning: in /sw/lib/libiconv.dylib, file is
not of required architecture" error message.
So, in summary, it looks like this is fixed.
Thanks,
Shaun
^ permalink raw reply
* Re: [PATCH] Makefile: Improve compiler header dependency check
From: Jonathan Nieder @ 2011-08-27 16:26 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Fredrik Kuivinen, git
In-Reply-To: <1314434470-7988-1-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> I fired up git's next branch on a mac laptop where I
> have a config.mak that builds universal git binaries:
>
> CFLAGS = -arch i386 -arch x86_64
>
> This configuration broke when 111ee18c31f9bac9436426399355facc79238566
> was merged into next.
Good catch; thanks. This information would be useful for the commit
message.
> gcc cannot generate header dependencies when
> multiple -arch statements are used
Sounds like a bug. Any idea why it behaves that way? What error message
does it write?
If it is a bug, it might be worth reporting this to the gcc devs while
at it.
[...]
> --- a/Makefile
> +++ b/Makefile
> @@ -1251,7 +1251,8 @@ USE_COMPUTED_HEADER_DEPENDENCIES =
> else
> ifndef COMPUTE_HEADER_DEPENDENCIES
> dep_check = $(shell sh -c \
> - '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
> + '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null \
> + $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) 2>&1; \
> echo $$?')
EXTRA_CPPFLAGS is a target-specific variable and would always be empty,
So I think this would be clearer without.
While we're touching this line, do you know if the "sh -c" is
necessary? I would expect $(shell ...) to run its arguments in a
shell.
Thanks --- despite the nitpicks above, this one looks good.
Jonathan
^ permalink raw reply
* Re: Files that cannot be added to the index
From: seanh @ 2011-08-27 15:39 UTC (permalink / raw)
To: git
In-Reply-To: <20110827060718.GA28136@sigill.intra.peff.net>
On Sat, Aug 27, 2011 at 02:07:18AM -0400, Jeff King wrote:
> I think both of you may be seeing the same bug I tracked down here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/173612/focus=174634
I don't think it's the same problem. For me the problem does not occur
with any git repo, only with two repos in particular. Also, the output
is not different every time, there are two files in particular that
always show up with phantom modifications in git status and git diff.
^ permalink raw reply
* Re: Files that cannot be added to the index
From: seanh @ 2011-08-27 15:35 UTC (permalink / raw)
To: Shaun Ruffell; +Cc: git
In-Reply-To: <20110826211233.GB3093@digium.com>
On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:
> Not sure if this is your problem exactly but awhile back I ran into
> something similar to what you describe and tracked it down to the
> fact that my filesystem was case insensitive. i.e.
My filesystem (HFS+ on OSX Lion) is case-insensitive, yeah. I bet you're
right, because in one repo the modified file shows up in `git status` as
LOG.txt but in the output from `ls` it is called `Log.txt`. It's the
same in the other repo that has the problem, the case of the filename
that is having the problem is different in `git status` and `ls`.
Perhaps the problem might have been introduced by moving the repo from a
case-sensitive to an insensitive filesystem? Or by originally starting
the repo on a sensitive fs and then using git clone to clone it onto an
insensitive one. Or, maybe at some point I committed a change to the
case of the filename and that introduced a problem on case-insenstive
filesystems.
Did you find a way around the problem? I guess that the repo does not
really have any uncommitted changes, so I just want to convince `git
status` and `git diff` of this.
^ permalink raw reply
* Re: git for game development?
From: Michael Witten @ 2011-08-27 15:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Jeff King, Lawrence Brett, git
In-Reply-To: <7vwre2pw3m.fsf@alter.siamese.dyndns.org>
On Wed, Aug 24, 2011 at 17:17, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> I don't remember all of the details of bup, but if it's possible to
>> implement something similar at a lower level (i.e., at the layer of
>> packfiles or object storage), then it can be a purely local thing, and
>> the compatibility issues can go away.
>
> I tend to agree, and we might be closer than we realize.
>
> I suspect that people with large binary assets were scared away by rumors
> they heard second-hand, based on bad experiences other people had before
> any of the recent efforts made in various "large Git" topics, and they
> themselves haven't tried recent versions of Git enough to be able to tell
> what the remaining pain points are. I wouldn't be surprised if none of the
> core Git people tried shoving huge binary assets in test repositories with
> recent versions of Git---I certainly haven't.
>
> We used to always map the blob data as a whole for anything we do, but
> these days, with changes like your abb371a (diff: don't retrieve binary
> blobs for diffstat, 2011-02-19) and my recent "send large blob straight to
> a new pack" and "stream large data out to the working tree without holding
> everything in core while checking out" topics, I suspect that the support
> for local usage of large blobs might be sufficiently better than the old
> days. Git might even be usable locally without anything else, which I find
> implausible, but I wouldn't be surprised if there remained only a handful
> minor things remaining that we need to add to make it usable.
>
> People toyed around with ideas to have a separate object store
> representation for large and possibly incompressible blobs (a possible
> complaint being that it is pointless to send them even to its own
> packfile). One possible implementation would be to add a new huge
> hierarchy under $GIT_DIR/objects/, compute the object name exactly the
> same way for huge blobs as we normally would (i.e. hash concatenation of
> object header and then contents) to decide which subdirectory under the
> "huge" hierarchy to store the data (huge/[0-9a-f]{2}/[0-9a-f]{38}/ like we
> do for loose objects, or perhaps huge/[0-9a-f]{40}/ expecting that there
> won't be very many). The data can be stored unmodified as a file in that
> directory, with type stored in a separate file---that way, we won't have
> to compress, but we just copy. You still need to hash it at least once to
> come up with the object name, but that is what gives us integrity checks,
> is unavoidable and is not going to change.
>
> The sha1_object_info() layer can learn to return the type and size from
> such a representation, and you can further tweak the same places as the
> "streaming checkout" and the "checkin to a pack" topics touched to support
> such a representation.
>
> I would suspect that the local object representation is _not_ the largest
> pain point; such a separate object store representation is not buying us
> very much over a simpler "single large blob in a separate packfile", and
> if the counter-argument is "no, decompressing still costs a lot", then the
> real issue might be we decompress and look at the data when we do not have
> to (i.e. issues similar to what abb371a addressed), not "decompress vs
> straight copy make a bit difference".
I've added Avery to the Cc list, because he really needs to chime in here.
I am completely unqualified to make a comment about this, but I think
that it would be silly to ignore the insights that Avery has about
storing large objects; `bup' uses rolling checksums and a `bloom
filter' implementation and who knows what else.
^ permalink raw reply
* Re: Is there a scriptable way to update the stat-info in the index without having git open and read those files?
From: Pete Wyckoff @ 2011-08-27 15:18 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List
In-Reply-To: <CABPp-BEiN7ffNmvLCvEfz056M_F36j+gV9t6J9-x_=H9q0rZFw@mail.gmail.com>
newren@gmail.com wrote on Mon, 22 Aug 2011 16:28 -0600:
> I want to do something really close to
> git update-index -q --refresh
> However, I want it to assume the files in the working tree are
> unmodified from the index (i.e. don't waste time opening and reading
> the file) and simply update the stat information in the index to match
> the current files on disk.
>
> Yes, I know that would be unsafe if the files don't have the
> appropriate contents; I'm promising that they do have the appropriate
> contents and don't want to pay the performance penalty for git to
> verify. Is that possible?
I have the same issue in my workflow, and agree with Junio that this
is just too bizarre to put in the code. Here's the script I use,
relying on dulwich, that you might find helpful.
-- Pete
------8<------------------
#!/usr/bin/env python2.6
# git-index-clone - Update index after a volume clone
# Copyright 2010 Pete Wyckoff <pw@padd.com>
import sys
import os
from dulwich.index import Index
index_name = ".git/index"
#
# Debugging option: show the index entry for just one file name,
# e.g. git-index-clone file/name/in/tree
#
def show_entry(name):
idx = Index(index_name)
if name not in idx:
print >>sys.stderr, "No index entry", name
return
print "index", idx[name]
t = update_from_stat(idx[name], name)
print "stat ", t
#
# Stat the file, return the new tuple
#
def update_from_stat(idx, name):
(ctime, mtime, dev, ino, mode, uid, gid, size, sha, flags) = idx
sb = os.lstat(name)
# times are float; dulwich converts to (sec, ns) on write
ctime = sb.st_ctime
mtime = sb.st_mtime
dev = sb.st_dev
ino = sb.st_ino
# assume mode unchanged
uid = sb.st_uid
gid = sb.st_gid
# assume size, sha, flags unchanged
return (ctime, mtime, dev, ino, mode, uid, gid, size, sha, flags)
def convert():
idx_in = Index(index_name)
os.unlink(index_name)
idx_out = Index(index_name)
for name in idx_in:
idx_out[name] = update_from_stat(idx_in[name], name)
idx_out.write()
os.chmod(index_name, 0644) # drop exec perms
def usage():
print >>sys.stderr, "Usage: %s [<index entry name>]\n"
sys.exit(1)
def main():
if len(sys.argv) == 1:
convert()
elif len(sys.argv) == 2:
show_entry(sys.argv[1])
else:
usage()
return 0
if __name__ == "__main__":
sys.exit(main())
^ permalink raw reply
* What would be a normal tool chain for supporting git
From: Philip Oakley @ 2011-08-27 14:18 UTC (permalink / raw)
To: Git List
I'm using git in a windows engineering environment [visual studio, matlab,
etc]. My main familiarity has been with windows tools :-( I know). My unix
knowledge is dated.
What would be a typical toolset I would need to set up for contributing to
git?
Philip
^ permalink raw reply
* Re: [PATCHv2] git-replace.txt: Clarify list mode
From: Michael J Gruber @ 2011-08-27 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
In-Reply-To: <7v4o14f844.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 26.08.2011 18:30:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Clarify that in list mode, "git replace" outputs the shortened ref
>> names, not their values.
>>
>> Also, point to the difficult to find git show-ref $(git replace -l).
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> Documentation/git-replace.txt | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
>> index 17df525..cd00837 100644
>> --- a/Documentation/git-replace.txt
>> +++ b/Documentation/git-replace.txt
>> @@ -61,6 +61,13 @@ OPTIONS
>> all if no pattern is given).
>> Typing "git replace" without arguments, also lists all replace
>> refs.
>> ++
>> +Note that this lists the names of the replace refs, not their values
>> +(not their replacements). You can get the latter like this, e.g.:
>
> Hmm, the update is _not wrong_ per-se, but...
>
> I highly doubt we would want to try to cover confusions that may come from
> any and all different mis-/pre-conceptions people may have by making the
> description _longer_.
>
> Which part of the wording in the existing description made you think that
> the command might list both names and their contents? We should identify
> that misleading description (if there is) and fix that, instead of tacking
> clarifying clauses at the end.
Full disclosure: I misunderstood it when I read it the first time. I
never expected it to list pairs of refs, but the questions is: Does it
list the original sha1 or the replacement sha1?
"replace ref" can be very easily misunderstood as "the ref which
replaces", i.e. the replacement sha1. I know a ref is not a rev, but
"replace ref" can easily be misread as "replace rev", "replaced ref" etc.
Secondly, "git replace -l sha1" is completely useless, and I did not
expect that either. Granted, it outputs sha1 or not, depending on
whether it is replaced or not, so "completely" is a bit harsh, but still.
So, while I still have things to learn about git, I've also had my share
of exposure to refs and revs, and if I misunderstand a man page, it
indicates that there may be others whom I could help with what I've
learned from my own misunderstandings.
Also, as regards to clarifying: In out man pages, we often show
practical, non-obvious ways in which a user can combine commands, and I
think git show-ref $(git replace -l) is one of them.
> Given these statements:
>
> "git replace" lists all replace refs.
> "ls" lists paths in the directory.
>
> I would say a natural reading of them is that they list "replace refs" and
> "paths", not "replace refs and their contents" and "paths and their contents".
This is natural, and the confusion above is a non-issue, *if* the reader
is very aware of the implementation of replacements as lightweight
tag-like refs with the sha1 as refname.
> By the way, one thing I forgot to say was that I do not think the variant
> of the output you wanted to have is necessarily a bad thing (it is bad to
> change the existing output to that variant, breaking other
> people). Perhaps it can become "-v(erbose)" output?
I'd say yes, Christian seems to prefer having "-v" even closer to
"branch -v". I'd say a user has the right to expect "-v,--verbose"
giving more information, but the type and extent of information should
depend on the actual command :)
Michael
^ permalink raw reply
* [PATCH v4] gitk: Allow commit editing
From: Michal Sojka @ 2011-08-27 12:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, paulus
In-Reply-To: <20110825173018.GA519@sigill.intra.peff.net>
On Thu, 25 Aug 2011, Jeff King wrote:
> On Thu, Aug 25, 2011 at 03:15:42PM +0200, Michal Sojka wrote:
> > + # Check whether some other refs contain the commit to be edited
> > + if {[exec git rev-list --stdin $id << $otherrefsneg] eq {}} {
> > + if { [confirm_popup [mc "The commit you are going to edit is contained in another, possibly non-local, ref (e.g. branch or tag).\
> > + It is a bad idea to change a ref that is possibly used by other people. See git-rebase(1) for details.\n\n\
> > + Do you want to continue?"]]} {
> > + return 1
>
> Minor micro-optimization: this can be "git rev-list -1". You only care
> if it produces the one commit, so that's sufficient. Without "-1", git
> will keep reporting commits all the way down to the merge base with some
> other ref.
Here is a new version with the micro-optimization.
Another minor change is that this patch now applies to gitk repo
(http://git.kernel.org/pub/scm/gitk/gitk.git) instead of the main git
repo.
-Michal
--8<---------------cut here---------------start------------->8---
I often use gitk to review patches before pushing them out and I would
like to have an easy way to edit commits. The current approach with
copying the commitid, switching to terminal, invoking git rebase -i,
editing the commit and switching back to gitk is a way too complicated
just for changing a single letter in the commit message or removing a
debug printf().
This patch adds "Edit this commit" item to gitk's context menu which
invokes interactive rebase in a non-interactive way :-). git gui is
used to actually edit the commit.
Besides editing the commit message, splitting of commits, as described
in git-rebase(1), is also supported.
The user is warned if the commit to be edited is contained in another
ref besides the current branch and the stash (e.g. in a remote
branch). Additionally, error box is displayed if the user attempts to
edit a commit not contained in the current branch.
Signed-off-by: Michal Sojka <sojka@os.inf.tu-dresden.de>
---
gitk | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index a701e0d..1ca2d00 100755
--- a/gitk
+++ b/gitk
@@ -2481,6 +2481,7 @@ proc makewindow {} {
makemenu $rowctxmenu {
{mc "Diff this -> selected" command {diffvssel 0}}
{mc "Diff selected -> this" command {diffvssel 1}}
+ {mc "Edit this commit" command edit_commit}
{mc "Make patch" command mkpatch}
{mc "Create tag" command mktag}
{mc "Write commit to file" command writecommit}
@@ -8445,18 +8446,18 @@ proc rowmenu {x y id} {
if {$id ne $nullid && $id ne $nullid2} {
set menu $rowctxmenu
if {$mainhead ne {}} {
- $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead] -state normal
+ $menu entryconfigure 8 -label [mc "Reset %s branch to here" $mainhead] -state normal
} else {
- $menu entryconfigure 7 -label [mc "Detached head: can't reset" $mainhead] -state disabled
+ $menu entryconfigure 8 -label [mc "Detached head: can't reset" $mainhead] -state disabled
}
if {[info exists markedid] && $markedid ne $id} {
- $menu entryconfigure 9 -state normal
$menu entryconfigure 10 -state normal
$menu entryconfigure 11 -state normal
+ $menu entryconfigure 12 -state normal
} else {
- $menu entryconfigure 9 -state disabled
$menu entryconfigure 10 -state disabled
$menu entryconfigure 11 -state disabled
+ $menu entryconfigure 12 -state disabled
}
} else {
set menu $fakerowmenu
@@ -9120,6 +9121,68 @@ proc cherrypick {} {
notbusy cherrypick
}
+proc rebase_ok {id} {
+ if {[exec git merge-base $id HEAD] ne $id} {
+ error_popup [mc "You cannot edit commits outside of the current branch."]
+ return 0
+ }
+ set headref [exec git symbolic-ref HEAD]
+ set allrefs [split [exec git for-each-ref --format=%(refname)] "\n"]
+ set otherrefs {}
+ set otherrefsneg ""
+ foreach ref $allrefs {
+ if {$ref eq "refs/stash" || $ref eq $headref} continue
+ set otherrefsneg "$otherrefsneg^$ref\n"
+ }
+
+ # Check whether some other refs contain the commit to be edited
+ if {[exec git rev-list --stdin $id --max-count=1 << $otherrefsneg] eq {}} {
+ if { [confirm_popup [mc "The commit you are going to edit is contained in another, possibly non-local, ref (e.g. branch or tag).\
+ It is a bad idea to change a ref that is possibly used by other people. See git-rebase(1) for details.\n\n\
+ Do you want to continue?"]]} {
+ return 1
+ } else {
+ return 0
+ }
+ }
+ return 1
+}
+
+proc edit_commit {} {
+ global rowmenuid selectedline
+
+ if {![rebase_ok $rowmenuid]} return
+
+ nowbusy edit [mc "Editing commit"]
+ if {[catch {exec sh -c "(GIT_EDITOR='sed -ie 1s/^pick/edit/' git rebase -p -i --no-autosquash $rowmenuid^ && git gui citool --amend) 2>&1"} err]} {
+ notbusy edit
+ error_popup $err
+ exec git rebase --abort
+ return
+ }
+ set newcommit [exec git rev-parse HEAD]
+ while {[catch {exec sh -c "git diff-index --quiet --cached HEAD && git diff-files --quiet"} err]} {
+ if {[confirm_popup [mc "There are uncommited changes in the working tree or in the index.\
+ Do you want to create a new commit (OK) or discard them (Cancel)?"]]} {
+ catch {exec git gui citool} err;
+ # In case of error (i.e. the user did not commit anything), we just ask him again
+ } else {
+ exec git reset --hard
+ }
+ }
+ if {[catch {exec sh -c "git rebase --continue 2>&1"} err]} {
+ notbusy edit
+ error_popup $err
+ exec git rebase --abort
+ return
+ }
+ updatecommits
+ # XXX How to select the edited commit? This doesn't work.
+ selbyid $newcommit
+ notbusy edit
+}
+
+
proc resethead {} {
global mainhead rowmenuid confirm_ok resettype NS
--
1.7.5.4
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply related
* Re: obstack fails to compile on OS X 10.7
From: David Aguilar @ 2011-08-27 10:14 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Fredrik Kuivinen
In-Reply-To: <4A1A024F-C5D5-4E5F-8474-DA3D87412C8A@gernhardtsoftware.com>
On Sat, Aug 27, 2011 at 02:21:40AM -0400, Brian Gernhardt wrote:
> Some of the errors look like things I could track down, but some just confuse me. If anyone else could take a look into this, it would be much appreciated.
>
> ~~ Brian G.
>
> gcc -o compat/obstack.o -c -MF compat/.depend/obstack.o.d -MMD -MP -Wall -Wdeclaration-after-statement -Werror -Wno-deprecated-declarations -I. -DUSE_ST_TIMESPEC -DSHA1_HEADER='"block-sha1/sha1.h"' -DNO_MEMMEM compat/obstack.c
> In file included from compat/obstack.c:30:
> compat/obstack.h:190: error: __block attribute can be specified on variables only
> compat/obstack.c:70: error: expected specifier-qualifier-list before ‘uintmax_t’
> compat/obstack.c:111:24: error: exitfail.h: No such file or directory
> cc1: warnings being treated as errors
> compat/obstack.c: In function ‘print_and_abort’:
> compat/obstack.c:436: warning: implicit declaration of function ‘gettext’
> compat/obstack.c:436: warning: incompatible implicit declaration of built-in function ‘gettext’
> compat/obstack.c:438: error: ‘exit_failure’ undeclared (first use in this function)
> compat/obstack.c:438: error: (Each undeclared identifier is reported only once
> compat/obstack.c:438: error: for each function it appears in.)
> compat/obstack.c:439: warning: ‘noreturn’ function does return
> make: *** [compat/obstack.o] Error 1
>
> $ gcc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
I ran into the same thing.
This fixes it for me, but we might want to rearrange the
#includes a bit. I think this needs more work.. including
compat/obstack.h from kwset.c seems wrong.
Should we just include obstack.h in git-compat-util instead?
I suspect that more exotic platforms may have problems
with obstack.h as well. This probably needs some testing
on SunOS, AIX, IRIX, etc.
-- 8< --
Subject: [RFC PATCH] obstack: Fix portability issues
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 and possibly others
do not have exit.h, exitfail.h, or obstack.h. Add compat
versions of these headers as well as exitfail.c from glibc.
The ELIDE_CODE check in obstack.c is not sufficient so add a
separate NEEDS_OBSTACK variable to allow platforms to opt into
using the compatibility versions of these files.
The __block variable was renamed to __blk to avoid a gcc error:
compat/obstack.h:190: error: __block attribute can be specified on variables only
Signed-off-by: David Aguilar <davvid@gmail.com>
Reported-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Makefile | 11 +++++++++++
compat/exit.h | 32 ++++++++++++++++++++++++++++++++
compat/exitfail.c | 24 ++++++++++++++++++++++++
compat/exitfail.h | 20 ++++++++++++++++++++
compat/obstack.c | 19 +++----------------
compat/obstack.h | 2 +-
kwset.c | 3 ++-
7 files changed, 93 insertions(+), 18 deletions(-)
create mode 100644 compat/exit.h
create mode 100644 compat/exitfail.c
create mode 100644 compat/exitfail.h
diff --git a/Makefile b/Makefile
index 30f3812..87ad4a2 100644
--- a/Makefile
+++ b/Makefile
@@ -517,6 +517,8 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/exitfail.h
+LIB_H += compat/exit.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += compat/win32/sys/poll.h
@@ -599,6 +601,7 @@ LIB_OBJS += cache-tree.o
LIB_OBJS += color.o
LIB_OBJS += combine-diff.o
LIB_OBJS += commit.o
+LIB_OBJS += compat/exitfail.o
LIB_OBJS += compat/obstack.o
LIB_OBJS += config.o
LIB_OBJS += connect.o
@@ -872,6 +875,8 @@ ifeq ($(uname_S),Darwin)
NEEDS_CRYPTO_WITH_SSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
+ NEEDS_OBSTACK = YesPlease
+ NEEDS_EXITFAIL = YesPlease
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
OLD_ICONV = UnfortunatelyYes
endif
@@ -1416,6 +1421,12 @@ endif
ifdef NEEDS_RESOLV
EXTLIBS += -lresolv
endif
+ifdef NEEDS_OBSTACK
+ BASIC_CFLAGS += -DNEEDS_OBSTACK
+endif
+ifdef NEEDS_EXITFAIL
+ BASIC_CFLAGS += -DNEEDS_EXITFAIL
+endif
ifdef NO_D_TYPE_IN_DIRENT
BASIC_CFLAGS += -DNO_D_TYPE_IN_DIRENT
endif
diff --git a/compat/exit.h b/compat/exit.h
new file mode 100644
index 0000000..9dbfb7c
--- /dev/null
+++ b/compat/exit.h
@@ -0,0 +1,32 @@
+/* exit() function.
+ Copyright (C) 1995, 2001 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+#ifndef _EXIT_H
+#define _EXIT_H
+
+/* Get exit() declaration. */
+#include <stdlib.h>
+
+/* Some systems do not define EXIT_*, even with STDC_HEADERS. */
+#ifndef EXIT_SUCCESS
+# define EXIT_SUCCESS 0
+#endif
+#ifndef EXIT_FAILURE
+# define EXIT_FAILURE 1
+#endif
+
+#endif /* _EXIT_H */
diff --git a/compat/exitfail.c b/compat/exitfail.c
new file mode 100644
index 0000000..a2dd5dd
--- /dev/null
+++ b/compat/exitfail.c
@@ -0,0 +1,24 @@
+/* Failure exit status
+
+ Copyright (C) 2002, 2003 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING.
+ If not, write to the Free Software Foundation,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+#ifdef NEEDS_EXITFAIL
+#include "exitfail.h"
+#include "exit.h"
+
+int volatile exit_failure = EXIT_FAILURE;
+#endif
diff --git a/compat/exitfail.h b/compat/exitfail.h
new file mode 100644
index 0000000..e46cf9c
--- /dev/null
+++ b/compat/exitfail.h
@@ -0,0 +1,20 @@
+/* Failure exit status
+
+ Copyright (C) 2002 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING.
+ If not, write to the Free Software Foundation,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+extern int volatile exit_failure;
diff --git a/compat/obstack.c b/compat/obstack.c
index 75440d9..825658c 100644
--- a/compat/obstack.c
+++ b/compat/obstack.c
@@ -18,15 +18,12 @@
Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
-
-#ifdef HAVE_CONFIG_H
-# include <config.h>
-#endif
-
#ifdef _LIBC
# include <obstack.h>
# include <shlib-compat.h>
#else
+# include <gettext.h>
+# include "git-compat-util.h"
# include "obstack.h"
#endif
@@ -54,7 +51,7 @@
#include <stddef.h>
-#ifndef ELIDE_CODE
+#if !defined ELIDE_CODE || defined NEEDS_OBSTACK
# if HAVE_INTTYPES_H
@@ -400,16 +397,6 @@ _obstack_memory_used (struct obstack *h)
return nbytes;
}
\f
-/* Define the error handler. */
-# ifdef _LIBC
-# include <libintl.h>
-# else
-# include "gettext.h"
-# endif
-# ifndef _
-# define _(msgid) gettext (msgid)
-# endif
-
# ifdef _LIBC
# include <libio/iolibio.h>
# endif
diff --git a/compat/obstack.h b/compat/obstack.h
index 449070e..5636b91 100644
--- a/compat/obstack.h
+++ b/compat/obstack.h
@@ -187,7 +187,7 @@ extern int _obstack_begin_1 (struct obstack *, int, int,
void (*) (void *, void *), void *);
extern int _obstack_memory_used (struct obstack *);
-void obstack_free (struct obstack *__obstack, void *__block);
+void obstack_free (struct obstack *__obstack, void *__blk);
\f
/* Error handler called when `obstack_chunk_alloc' failed to allocate
diff --git a/kwset.c b/kwset.c
index fd4515a..d01c562 100644
--- a/kwset.c
+++ b/kwset.c
@@ -37,7 +37,8 @@
#include "cache.h"
#include "kwset.h"
-#include "obstack.h"
+#include "git-compat-util.h"
+#include "compat/obstack.h"
#define NCHAR (UCHAR_MAX + 1)
#define obstack_chunk_alloc xmalloc
--
1.7.6.476.g57292
^ permalink raw reply related
* Re: [PATCH v2] xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
From: Marat Radchenko @ 2011-08-27 8:50 UTC (permalink / raw)
To: Tay Ray Chuan, Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <1313546037-4104-1-git-send-email-rctay89@gmail.com>
On ср 17 авг 2011 05:53:57 MSD, Tay Ray Chuan <rctay89@gmail.com> wrote:
> In xdl_cleanup_records(), we see O(n*m) performance, where n is the
> number of records from xdf->dstart to xdf->dend, and m is the size of a
> bucket in xdf->rhash (<= by mlim).
>
> Here, we improve this to O(n) by pre-computing nm (in rcrec->len(1|2))
> in xdl_classify_record().
Thanks for your patch, btw, now diff is much faster
^ permalink raw reply
* [PATCH] Makefile: Improve compiler header dependency check
From: David Aguilar @ 2011-08-27 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Fredrik Kuivinen, git
The Makefile enables CHECK_HEADER_DEPENDENCIES when the
compiler supports generating header dependencies.
Make the check use the same flags as the invocation
to avoid a false positive when user-configured compiler
flags contain incompatible options.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
I fired up git's next branch on a mac laptop where I
have a config.mak that builds universal git binaries:
CFLAGS = -arch i386 -arch x86_64
This configuration broke when 111ee18c31f9bac9436426399355facc79238566
was merged into next. gcc cannot generate header dependencies when
multiple -arch statements are used but the test generated a false
positive.
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index aa67142..30f3812 100644
--- a/Makefile
+++ b/Makefile
@@ -1251,7 +1251,8 @@ USE_COMPUTED_HEADER_DEPENDENCIES =
else
ifndef COMPUTE_HEADER_DEPENDENCIES
dep_check = $(shell sh -c \
- '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null \
+ $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) 2>&1; \
echo $$?')
ifeq ($(dep_check),0)
COMPUTE_HEADER_DEPENDENCIES=YesPlease
--
1.7.6.476.g57292
^ permalink raw reply related
* obstack fails to compile on OS X 10.7
From: Brian Gernhardt @ 2011-08-27 6:21 UTC (permalink / raw)
To: Git List
Some of the errors look like things I could track down, but some just confuse me. If anyone else could take a look into this, it would be much appreciated.
~~ Brian G.
gcc -o compat/obstack.o -c -MF compat/.depend/obstack.o.d -MMD -MP -Wall -Wdeclaration-after-statement -Werror -Wno-deprecated-declarations -I. -DUSE_ST_TIMESPEC -DSHA1_HEADER='"block-sha1/sha1.h"' -DNO_MEMMEM compat/obstack.c
In file included from compat/obstack.c:30:
compat/obstack.h:190: error: __block attribute can be specified on variables only
compat/obstack.c:70: error: expected specifier-qualifier-list before ‘uintmax_t’
compat/obstack.c:111:24: error: exitfail.h: No such file or directory
cc1: warnings being treated as errors
compat/obstack.c: In function ‘print_and_abort’:
compat/obstack.c:436: warning: implicit declaration of function ‘gettext’
compat/obstack.c:436: warning: incompatible implicit declaration of built-in function ‘gettext’
compat/obstack.c:438: error: ‘exit_failure’ undeclared (first use in this function)
compat/obstack.c:438: error: (Each undeclared identifier is reported only once
compat/obstack.c:438: error: for each function it appears in.)
compat/obstack.c:439: warning: ‘noreturn’ function does return
make: *** [compat/obstack.o] Error 1
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
^ permalink raw reply
* Re: Files that cannot be added to the index
From: Jeff King @ 2011-08-27 6:07 UTC (permalink / raw)
To: Shaun Ruffell; +Cc: Michael J Gruber, seanh, git
In-Reply-To: <20110826211233.GB3093@digium.com>
On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:
> On Fri, Aug 26, 2011 at 10:59:19PM +0200, seanh wrote:
> > I'm using git version 1.7.4.4 on OSX Lion, from macports. (I was
> > having the problem on Snow Leopard too.)
>
> Not sure if this is your problem exactly but awhile back I ran into
> something similar to what you describe and tracked it down to the
> fact that my filesystem was case insensitive. i.e.
> [...]
> $ git commit
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: Makefile
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ git add makefile
> $ git commit
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: Makefile
> #
> no changes added to commit (use "git add" and/or "git commit -a")
I think both of you may be seeing the same bug I tracked down here:
http://thread.gmane.org/gmane.comp.version-control.git/173612/focus=174634
Does the patch from the very end of the thread solve the problem for
you? I should probably clean it up for inclusion in git.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Alexey Shumkin @ 2011-08-27 5:14 UTC (permalink / raw)
To: git
In-Reply-To: <20110825204047.GA9948@sigill.intra.peff.net>
> Also, any other extensions that would go into such a list? I have no
> idea what the common extension is for something like pascal or csharp.
# [Object] Pascal unit files
*.pas diff=pascal
# + project files (they rarely contain procedures/functions
# but it is not forbidden in specification)
*.dpr diff=pascal
# for Lazarus - pp and .lpr respectivly
*.pp diff=pascal
*.lpr diff=pascal
^ permalink raw reply
* Idea: "git format-patch" should get more information out of git
From: Michael Haggerty @ 2011-08-27 5:12 UTC (permalink / raw)
To: git
It is a nuisance that the emails for a patch series have to be
hand-edited after they are generated by "git format-patch". Some of the
problems with this workflow are
1. The extra information typed into the email series is not archived in
the git repository, and therefore the emails have to be kept around.
2. If it is discovered between "git format-patch" and "git send-email"
that one of the patches needs a tweak, then the email series has to be
generated anew and all of the hand-edits need to be redone.
3. If a "v2" of the patch series has to be created, all of the
hand-edits have to be done again.
4. There is no place to store the "additional information" (the part
that comes in patch emails between the "---" and the diffstat) while
working on the patch series; it all has to be remembered or noted
somewhere else until just before sending off the patch emails.
Wouldn't it be nice if more of the information needed by "git
format-patch" could be extracted from the git repository? For example:
* The subject and body of the cover letter could be written to the log
message of an annotated tag at the tip of the patch series. "git
format-patch" could retrieve it if the "--cover-letter" option is used.
* The CC and ACK lists could be written as specially-formatted lines in
the annotated tag's log message, or perhaps in a git note.
* The "additional information" could be written to git notes.
I don't know whether git notes are the right vessel for such
information. For example, are they carried along when a commit is rebased?
I don't have time to implement any of this, but perhaps somebody thinks
this is a good idea and is inspired to work on it.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Michael Haggerty @ 2011-08-27 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <1314418364-2532-2-git-send-email-mhagger@alum.mit.edu>
On 08/27/2011 06:12 AM, Michael Haggerty wrote:
> And add tests that such refnames are accepted and normalized
> correctly.
...oops, I just noticed that you have committed a this same patch to pu
already, but with a better log message. Please retain that version.
Patch 2/2, however, is new.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH v2 2/2] Forbid DEL characters in reference names
From: Michael Haggerty @ 2011-08-27 4:12 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, cmn, Michael Haggerty
In-Reply-To: <1314418364-2532-1-git-send-email-mhagger@alum.mit.edu>
DEL is an ASCII control character and therefore should not be
permitted in reference names. Add tests for this and other unusual
characters.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Please check that the uses of "printf" in the test script are portable
and quoted correctly.
refs.c | 2 +-
t/t1402-check-ref-format.sh | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 3a8789d..0fa8dcf 100644
--- a/refs.c
+++ b/refs.c
@@ -837,7 +837,7 @@ int for_each_rawref(each_ref_fn fn, void *cb_data)
static inline int bad_ref_char(int ch)
{
- if (((unsigned) ch) <= ' ' ||
+ if (((unsigned) ch) <= ' ' || ch == 0x7f ||
ch == '~' || ch == '^' || ch == ':' || ch == '\\')
return 1;
/* 2.13 Pattern Matching Notation */
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 7563043..ed4275a 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -30,6 +30,9 @@ invalid_ref 'heads/foo.lock'
valid_ref 'heads/foo@bar'
invalid_ref 'heads/v@{ation'
invalid_ref 'heads/foo\bar'
+invalid_ref "$(printf 'heads/foo\t')"
+invalid_ref "$(printf 'heads/foo\177')"
+valid_ref "$(printf 'heads/fu\303\237')"
test_expect_success "check-ref-format --branch @{-1}" '
T=$(git write-tree) &&
--
1.7.6.8.gd2879
^ permalink raw reply related
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