* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-22 12:35 UTC (permalink / raw)
To: Boaz Harrosh, git
In-Reply-To: <20090122102925.GD6936@b2j>
bill lam wrote:
> On Thu, 22 Jan 2009, Boaz Harrosh wrote:
>> Sorry My mistake, it should be:
>> [gitrepo] $ git-add etc/fstab
>>
>> Sorry it's a typo, sure you must add files relative to
>> the base directory (one containing the .git/ dir)
>
> Hi Boaz,
>
> I still could not add the file. This time it said symbolic link error.
>
OK so it looks like it is something new. Good to know I will not
upgrade for now as I do use it a lot. Unless there is some config
nub that can be turned. I must say that it is most useful, I use
it everyday.
Someone please comment why are symlink not allowed. Is that because
it might be dangerous? but so is a gun I might shoot myself in the
leg, but they are still been sold.
Boaz
^ permalink raw reply
* Re: git-describe hash length
From: Tomas Carnecky @ 2009-01-22 12:34 UTC (permalink / raw)
To: Martin Pirker; +Cc: git
In-Reply-To: <497857CE.3060101@iaik.tugraz.at>
On 01/22/2009 12:26 PM, Martin Pirker wrote:
> Hi!
>
>
> john@doe:/workspace$ git version
> git version 1.6.1
> john@doe:/workspace$ git describe
> fatal: cannot describe '7aee61cc635a923e70b74091486742481ee0928b'
> john@doe:/workspace$ git describe --always
> 7aee61c
> john@doe:/workspace$ git describe --always --abbrev=8
> 7aee61cc
>
>
> man git-describe:
>
> --abbrev=<n>
> Instead of using the default 8 hexadecimal digits as the
> abbreviated object name, use<n> digits.
>
>
>
> There is one character missing from default or what am I missing?
The man page is wrong:
cache.h:#define DEFAULT_ABBREV 7
builtin-describe.c:static int abbrev = DEFAULT_ABBREV;
tom
^ permalink raw reply
* Re: git on the reg
From: Felipe Contreras @ 2009-01-22 12:40 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20090122071746.GG9224@eratosthenes.cryptobackpack.org>
On Thu, Jan 22, 2009 at 9:17 AM, David Bryson <david@statichacks.org> wrote:
> Hi all,
>
> The regsiter has an article on the guerilla git movement inside
> companies. I recall at the GitTogether folks from big pharma, Google,
> and Facebook were 'unofficially' using git(not to mention myself).
>
> http://www.theregister.co.uk/2009/01/21/git_gaining_ground/
>
> It is very cool to see this bottom up movement gaining some notariety.
> Oh an the Linus jokes are fairly amusing as well ;-).
Excellent article! Explains git in a nutshell on many levels.
--
Felipe Contreras
^ permalink raw reply
* Re: Short rant about git usability - make 'git clone' work on an empty remote repository
From: Sverre Rabbelier @ 2009-01-22 13:00 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: git
In-Reply-To: <20090122100230.GA9653@amd.home.annexia.org>
Heya,
On Thu, Jan 22, 2009 at 11:02, Richard W.M. Jones <rjones@redhat.com> wrote:
> $ git clone git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> fatal: no matching remote head
> $ mkdir ocaml-autoconf
> $ cd ocaml-autoconf
> $ git init
> Initialized empty Git repository in /home/rjones/d/ocaml-autoconf/.git/
> $ git remote add origin git+ssh://rwmj@git.ocamlcore.org/gitroot/ocaml-autoconf/ocaml-autoconf.git
> $ echo test > README
> $ git add README
> $ git commit
> Created initial commit 2c9a63a: Create repository.
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 README
> $ git push origin master
Is, as far as I can see, the minimal you could have done to get your
remote set up. You are right in that cloning an empty repository would
be nice to have as it would save having to remember to do about 8
different commands. Then again, after digging through the source for
half an hour I'm still not sure I even understand what's going on, let
alone know how to fix it ;). You should ask on #git for cloning empty
dir support, maybe it'll annoy Dscho enough to fix it.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Short rant about git usability - make 'git clone' work on an empty remote repository
From: Johannes Schindelin @ 2009-01-22 13:51 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Richard W.M. Jones, git
In-Reply-To: <bd6139dc0901220500q7bb91031o81c3aab41c68d518@mail.gmail.com>
Hi,
On Thu, 22 Jan 2009, Sverre Rabbelier wrote:
> You should ask on #git for cloning empty dir support, maybe it'll annoy
> Dscho enough to fix it.
Bastard :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-22 14:17 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090121170434.GA21727@hashpling.org>
>From bf55fdd37f0fa4d0b3a10f43fa3d1815a6dbc6b3 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] mergetool merge/skip/abort
add functionality to skip merging a file or abort from mergetool
---
git-mergetool.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..bd5711e 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,8 +177,24 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ while true; do
+ printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*|"")
+ break
+ ;;
+ [sS]*)
+ cleanup_temp_files
+ return 0
+ ;;
+ [aA]*)
+ cleanup_temp_files
+ exit 0
+ ;;
+ esac
+ done
fi
case "$merge_tool" in
--
1.6.1
> This looks to me like no merge will happen if --no-prompt/-y or
> mergetool.prompt is set to false. Have you tested with this option or
> have I misread?
just tested and it works fine... meaning it doesn't prompt which is
what it's supposed to do.
> Also, I think you've lost some tabs. Mergetool does have some
> inconsistent tabbing but they way I've been aiming towards (which
> matches most, but not all of git-mergetool.sh) is to use tabs == 8
> spaces for indents but to indent each level by 4 spaces. e.g. three
> levels of indent is one tab plus four spaces.
mixing tabs and spaces == bad, I just realized I can't see half your
indents because I had tabstop=4 in my vimrc because I like indents at
4 spaces which is what you are doing through emulation. this is why I
generally just use tabs or spaces. files like fstab and .sql are my
few exceptions, both of which I do more on columns than indents.
> I'd like to keep (additionally) the behaviour, that the merge starts
> with just pressing <Enter>. Because what you mostly want to do, when
> using git-mergetool, is actually merging.
done, and maybe you... but generally I've got more skips than merges,
but I've got a corner case.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply related
* Re: GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)
From: Sitaram Chamarty @ 2009-01-22 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0901211705280.19665@iabervon.org>
On 2009-01-21, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
>> have managed to right click on a remote branch, choose
>> "checkout this branch" and have made commits on it without
>> knowing they're not on any branch!
>
> I wonder if the GUI could handle this in a way that users would
> understand. This is qualitively like following a link to a spreadsheet in
I'd be happy with a simple warning message saying "are you
sure you know what you are doing?" or words to that effect
:-)
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-22 14:30 UTC (permalink / raw)
To: Kelly F. Hickel, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6855@emailmn.mqsoftware.com>
(Sorry for the mangled quotes)
> That is strange. The command "data 88" should read the next 88 bytes
and
> not stop at the line starting with '.
>
> Just to test, I successfully imported this:
>
> -- snip --
> commit refs/heads/testing/test
> mark :1
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 3
> '.
>
> -- snap --
>
> So I guess the problem lies much earlier: I could imagine that there
is
> _another_ "data" command that has a bogus length and just happens to
end
> after the line "data 88".
>
> Maybe that helps?
>
> I could also imagine that the '. actually is the end of an example
> inside a blob, that literally looks like a fast-import script, but
> actually is not meant for _this_ fast-import run.
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> From: Daniel Barkalow
> Can you find that part of the input? I wouldn't be too surprised if
> something were giving the wrong length in a data command, causing it
to
> either eat another data command and end up in the data or to use
> not-quite-all of the data and end up near the end of the data.
>
> -Daniel
> *This .sig left intentionally blank*
>
>
I found the section in question, it is:
-- snip --
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
This commit was manufactured by cvs2svn to create tag
'T_BU_Problem_9xxx_Merge_3-21-2000'.
merge :1000007126
M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
-- snap --
By my count, 88 is the ending single quote character, leaving the '.' to
be interpreted as a command.
Looks like I should go post this on the cvs2svn list.....
Thanks!
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere
Learn more at www.mqsoftware.com
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Charles Bailey @ 2009-01-22 14:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901220617l22b5a8e4ma48bb069d67cae91@mail.gmail.com>
On Thu, Jan 22, 2009 at 09:17:39AM -0500, Caleb Cushing wrote:
> > Also, I think you've lost some tabs. Mergetool does have some
> > inconsistent tabbing but they way I've been aiming towards (which
> > matches most, but not all of git-mergetool.sh) is to use tabs == 8
> > spaces for indents but to indent each level by 4 spaces. e.g. three
> > levels of indent is one tab plus four spaces.
>
> mixing tabs and spaces == bad, I just realized I can't see half your
> indents because I had tabstop=4 in my vimrc because I like indents at
> 4 spaces which is what you are doing through emulation. this is why I
> generally just use tabs or spaces. files like fstab and .sql are my
> few exceptions, both of which I do more on columns than indents.
There are two conventions at work in git-mergetool.sh but the most
prevalent one (it was like that when I got here!) can be easily
maintained in vim with:
:set tabstop=8
:set softtabstop=4
:set shiftwidth=4
You'll never (well, almost never) know that tabs aren't 4 spaces.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Karl Hasselström @ 2009-01-22 16:03 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <49750E4B.3000203@tedpavlic.com>
On 2009-01-19 18:35:39 -0500, Ted Pavlic wrote:
> I didn't see it because it is generated in the build process. :(
Yeah, sorry about that. I made it that way so it would be kept
up-to-date automatically (which works quite well, by the way).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Ted Pavlic @ 2009-01-22 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: catalin.marinas, git
In-Reply-To: <20090122160350.GA15074@diana.vm.bytemark.co.uk>
>> I didn't see it because it is generated in the build process. :(
>
> Yeah, sorry about that. I made it that way so it would be kept
> up-to-date automatically (which works quite well, by the way).
The only downside is that it's a little harder to keep track of when the
completion script changes (e.g., when you have made your own local
changes). However, the method you use provides very *fast* completion
(as opposed to git and hg completion, which generate their keywords on
the fly and thus run relatively slowly).
HOWEVER, please see the threads (which modify the Python that generates
the script):
[StGit PATCH 1/2] Modify bash completion to support help, version, and
copyright.
[StGit PATCH 2/2] Make bash completion fail to bashdefault before
default completion.
The former thread could be implemented by making help, version, and
copyright modules like the rest of the commands, but I think this method
is fine (and it makes stg help <tab> show fewer entries).
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-22 16:13 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Brent Goodrick, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <e2b179460901220204x7b6a43b5hddfee623d2425429@mail.gmail.com>
Mike Ralphson writes:
> >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> > The environment I'm running git under is the Shell mode inside GNU
> > Emacs. I can't tell you what type of terminal it is, because I believe
> > that is defined deep in the guts of Emacs. Having read your reply
> > above, I'm now wondering whether this is an Emacs issue versus a git
> > issue. If it is an Emacs issue, then I am truly embarrassed for having
> > wasted everyones time with it.
>
> 2009/1/22 Junio C Hamano <gitster@pobox.com>:
> > I think we pay attention to "dumb" when deciding if pager is useful and if
> > we can do color, but I do not think we check anything beyond "is it a tty"
> > when deciding to show progress or not. The only thing we do differently
> > for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
> > with a run of SPs to overwrite trailing part of a line, and we assume even
> > dumb terminals know how to do a carriage-return.
>
> I think this earlier discussion is probably relevant... I'm guessing
> though, $EDITOR is set correctly here 8-)
I do have EDITOR set to a home-built version of gnuclient, and git
talks to Emacs by way of that gnuclient just fine when I'm not using the
-m "commit_message" git-commit option.
>
> 2008/12/17 Junio C Hamano <gitster@pobox.com>:
> > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
> > in compilation mode (and possibly shell mode), so this is not a problem in
> > practice.
> >
> > I have something like this in my .emacs:
> >
> > (setenv "PAGER" "cat")
> >
> > I suspect (I am just a user not a hacker) this will have bad interaction
> > with emacs terminal emulation mode, but I do not use the mode, so it is
> > enough for me.
I have PAGER set to "cat" in the environment before I run Emacs for
the same reason.
Unfortunately, this morning when I rebooted and reloaded from scratch,
I am now unable to reproduce the CR codes output from "git pull" no
matter what I do. I even tried the older git installed on Debian Linux
"testing", and tried unsetting PAGER and GIT_PAGER, and saw the pager
prompts and the terminal escape sequence output as I expected to
(which is not the issue here). I can't expect anyone else to help me
debug this problem further if I can't even reproduce it
anymore. Frustrating.
I do have automatic updates turned on, so perhaps something changed in
the termcap or how terminal I/O is being done outside of git in my
system. Emacs would not have changed since I build Emacs from top of
trunk CVS, and it only uses local Elisp packages AFAIK.
I don't suppose git has any logic that emits the progress messages
based upon some estimate of amount of work it has to do, or has done,
does it?
Thanks,
Brent
P.S., for your reference, below is my evaluation script that
previously showed the CR code from git pull output. I even increased
the number of files added to the second repo up to 50 to see if the
quantity of files being pulled had any effect on the progress messages
output, but that didn't seem to have any effect. If anyone sees
anything bone-headed there, I'm all ears:
--- cut below this line ---
#!/bin/sh
# -*-mode: Shell-script; indent-tabs-mode: nil; -*-
# I could have simply used "set -x" here but then I wouldn't see the
# redirection syntax like ">file1", so instead use a PrintRun
# function:
PrintRun ()
{
echo "COMMAND: $*"
eval "$*; exitcode=\$?"
if [ $exitcode != 0 ]
then
echo "ERROR: Command failed: $*"
exit 1
fi
}
git_term_redirect=""
if [ "$USE_GIT_TERM_REDIRECT" = 1 ]
then
git_term_redirect=" 2>&1 | cat"
echo "Note: using git redirect on some git git commands: \"$git_term_redirect\""
fi
if [ "$USE_LOCALLY_BUILT_GIT" = 1 ]
then
git_bin_dir="$HOME/git_from_source/install/bin"
if [ -d "$git_bin_dir" ]
then
PATH="$HOME/git_from_source/install/bin:$PATH"; export PATH
fi
fi
if [ "$SKIP_PAGER_HACK" = 1 ]
then
unset PAGER
echo "Note: setting PAGER to $PAGER"
else
echo "Note: unsetting PAGER"
PAGER=cat; export PAGER
fi
# Print out the git version as a double check on the above logic:
PrintRun git --version
# Clear out the scratch areas:
PrintRun rm -rf /tmp/git_area1
PrintRun rm -rf /tmp/git_area2
# Populate the initial area:
PrintRun mkdir -p /tmp/git_area1
PrintRun cd /tmp/git_area1
PrintRun git init
PrintRun "echo a new file 1 >file1"
PrintRun "echo a new file 2 >file2"
PrintRun git add file1
PrintRun git add file2
PrintRun git status
PrintRun "git commit -m \"first commit in git_area1\""
PrintRun find .
# Clone from the first area into a second area and add files there:
PrintRun rm -rf /tmp/git_area2
PrintRun cd /tmp
PrintRun git clone /tmp/git_area1 git_area2
PrintRun cd /tmp/git_area2
PrintRun find .
i=1
while [ $i -le 50 ]
do
file="file_$i"
echo "file==\"${file}\""
PrintRun "echo a new file >$file"
PrintRun git add $file
PrintRun git status
PrintRun "git commit -m \"committing new file $file but in git_area2\""
# PrintRun "git status; true" # true means don't fail inside PrintRun
i=`expr $i + 1`
done
# Now attempt to pull the second repo changes back into into the first repo with a "git pull" operation:
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
if [ "$INJECT_TERM" != "" ]
then
echo "Note: Exporting environment variable: TERM=\"$INJECT_TERM\""
TERM="$INJECT_TERM"; export TERM
fi
PrintRun "git pull /tmp/git_area2 master $git_term_redirect"
# if [ "$STOP_AFTER_FIRST_GIT_PULL" = 1 ]
# then
# echo "Note: Stopping after first git pull"
# env | grep -i term
# exit 0
# fi
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun cat file_3
PrintRun "echo conflict1 >>file_3"
PrintRun git add file_3
PrintRun git status
PrintRun "git commit -m \"conflict1 added in git_area1\""
PrintRun cd /tmp/git_area2
PrintRun "echo conflict2 >>file_3"
PrintRun git add file_3
PrintRun git status
PrintRun "git commit -m \"conflict2 added in git_area2\""
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
# This git pull should show the conflict:
PrintRun "git pull /tmp/git_area2 master $git_term_redirect"
PrintRun cat file_3
PrintRun "echo conflict resolved > file_3"
# Running git commit now will fail:
### PrintRun "git commit -m \"conflict resolved\""
# Running git add on the file I just "resolved" by editing it directly above
PrintRun git add file_3
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git commit -m \"conflict resolved\""
PrintRun "git log"
--- cut above this line ---
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Hannu Koivisto @ 2009-01-22 16:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530901211319t8126611wc1437848631fe988@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This brings back my previous question: where is the home directory in
> a Windows system?
It's where %HOMEDRIVE%%HOMEPATH% points to.
--
Hannu
^ permalink raw reply
* Re: [StGit PATCH] Added basic bash completion script for StGit.
From: Karl Hasselström @ 2009-01-22 16:18 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <49789A1F.8010203@tedpavlic.com>
On 2009-01-22 11:09:03 -0500, Ted Pavlic wrote:
> The only downside is that it's a little harder to keep track of when
> the completion script changes (e.g., when you have made your own
> local changes).
It's a generated file -- you're not supposed to edit it! Wouldn't it
be a better idea to edit the program that generates it instead?
> However, the method you use provides very *fast* completion (as
> opposed to git and hg completion, which generate their keywords on
> the fly and thus run relatively slowly).
Yes, I was always irritated by how slow the StGit completion was
compared to git's. Python sucks in this respect.
> HOWEVER, please see the threads (which modify the Python that
> generates the script):
Yes, I'll take a look.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Johannes Schindelin @ 2009-01-22 16:31 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6921@emailmn.mqsoftware.com>
Hi,
On Thu, 22 Jan 2009, Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
Great!
> Looks like I should go post this on the cvs2svn list.....
Indeed. I think that Michael will find the culprit very soon, with this
detailed report.
BTW for future reference, please Cc: the people you are responding to.
The Git mailing list is a high volume list, and people will miss you
answers otherwise.
Thanks,
Dscho
^ permalink raw reply
* Re: [StGit PATCH 2/2] Make bash completion fail to bashdefault before default completion.
From: Ted Pavlic @ 2009-01-22 16:38 UTC (permalink / raw)
To: Ted Pavlic; +Cc: catalin.marinas, git
In-Reply-To: <1232412373-10836-2-git-send-email-ted@tedpavlic.com>
> def install():
> - return ['complete -o default -F _stg stg']
> + return ['complete -o bashdefault -o default -F _stg stg 2>/dev/null \\', [
> + 'complete -o default -F _stg stg' ] ]
Oops -- that second "complete" should have two pipes in front of it...
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* [PATCH] git-describe documentation: --match pattern is glob
From: ecashin @ 2009-01-22 16:21 UTC (permalink / raw)
To: git; +Cc: ecashin
I finally took a few minutes to figure out what kind of pattern
specification the "--match" option to git-describe expects. I
think it would be helpful to mention it explicitly in the manpage
so that trial and error isn't the only recourse for git-describe
users.
It seemed a bit weird to use "torvalds@g5" in the examples,
but I guess it's good to be consistent.
commit 0cbed245ca2812cb7708d9d97a8b5092a8b22b73
Author: Ed L. Cashin <ecashin@coraid.com>
Date: Thu Jan 22 11:09:22 2009 -0500
mention what kind of pattern the --match option expects
It wasn't clear whether the --match option expects a regular
expression or some other kind of pattern specification.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index a99b4ef..92a7995 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -73,7 +73,8 @@ OPTIONS
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
- leaking private tags made from the repository).
+ leaking private tags made from the repository). The pattern
+ syntax is similar to shell globbing.
--always::
Show uniquely abbreviated commit object as fallback.
@@ -117,6 +118,21 @@ closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
+When multiple trees are being tracked, --match can specify which tags
+are interesting. I see that a certain commit appeared first in a
+linux-next release, because I am tracking the linux-next tree as a
+remote:
+
+ [torvalds@g5 linux-2.6]$ git describe --contains 9514dff9
+ next-20080623~13^2~72
+
+But since I really want to know the first mainline release containing
+the commit, I use --match to get those results:
+
+ [torvalds@g5 linux-2.6]$ git describe --contains --match 'v*' 9514dff9
+ v2.6.27-rc1~1103^2~85
+
+
SEARCH STRATEGY
---------------
^ permalink raw reply related
* Re: CR codes from git commands
From: Mike Ralphson @ 2009-01-22 16:41 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <18808.39712.351656.138702@hungover.brentg.com>
2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> Mike Ralphson writes:
> > I think this earlier discussion is probably relevant... I'm guessing
> > though, $EDITOR is set correctly here 8-)
>
> I do have EDITOR set to a home-built version of gnuclient...
Sorry, I was being too subtle. My $EDITOR is set to vim, as god intended. 8-)
Mike
^ permalink raw reply
* Re: CR codes from git commands
From: Daniel Barkalow @ 2009-01-22 16:44 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Mike Ralphson, Junio C Hamano, git
In-Reply-To: <18808.39712.351656.138702@hungover.brentg.com>
On Thu, 22 Jan 2009, Brent Goodrick wrote:
> Mike Ralphson writes:
> > >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:
> > > The environment I'm running git under is the Shell mode inside GNU
> > > Emacs. I can't tell you what type of terminal it is, because I believe
> > > that is defined deep in the guts of Emacs. Having read your reply
> > > above, I'm now wondering whether this is an Emacs issue versus a git
> > > issue. If it is an Emacs issue, then I am truly embarrassed for having
> > > wasted everyones time with it.
> >
> > 2009/1/22 Junio C Hamano <gitster@pobox.com>:
> > > I think we pay attention to "dumb" when deciding if pager is useful and if
> > > we can do color, but I do not think we check anything beyond "is it a tty"
> > > when deciding to show progress or not. The only thing we do differently
> > > for "dumb" terminal is if we use ANSI clear-to-eol escape sequence or fill
> > > with a run of SPs to overwrite trailing part of a line, and we assume even
> > > dumb terminals know how to do a carriage-return.
> >
> > I think this earlier discussion is probably relevant... I'm guessing
> > though, $EDITOR is set correctly here 8-)
>
> I do have EDITOR set to a home-built version of gnuclient, and git
> talks to Emacs by way of that gnuclient just fine when I'm not using the
> -m "commit_message" git-commit option.
>
> >
> > 2008/12/17 Junio C Hamano <gitster@pobox.com>:
> > > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used
> > > in compilation mode (and possibly shell mode), so this is not a problem in
> > > practice.
> > >
> > > I have something like this in my .emacs:
> > >
> > > (setenv "PAGER" "cat")
> > >
> > > I suspect (I am just a user not a hacker) this will have bad interaction
> > > with emacs terminal emulation mode, but I do not use the mode, so it is
> > > enough for me.
>
> I have PAGER set to "cat" in the environment before I run Emacs for
> the same reason.
>
> Unfortunately, this morning when I rebooted and reloaded from scratch,
> I am now unable to reproduce the CR codes output from "git pull" no
> matter what I do. I even tried the older git installed on Debian Linux
> "testing", and tried unsetting PAGER and GIT_PAGER, and saw the pager
> prompts and the terminal escape sequence output as I expected to
> (which is not the issue here). I can't expect anyone else to help me
> debug this problem further if I can't even reproduce it
> anymore. Frustrating.
>
> I do have automatic updates turned on, so perhaps something changed in
> the termcap or how terminal I/O is being done outside of git in my
> system. Emacs would not have changed since I build Emacs from top of
> trunk CVS, and it only uses local Elisp packages AFAIK.
>
> I don't suppose git has any logic that emits the progress messages
> based upon some estimate of amount of work it has to do, or has done,
> does it?
It does have logic to only emit progress messages at a reasonable rate
(otherwise, you might be waiting for the progress messages to be printed
instead of just waiting for the data to arrive). So it's possible that you
now have things going fast enough that it only needs to print one message.
It can also estimate that something hasn't taken long enough for the user
to get impatient yet, and therefore not show progress at all (so the
output won't be littered with progress output for every operation that
could have taken a long time for some data, but didn't for this data).
In any case, it's all done in progress.c, so it should be easy enough to
make changes to if you can come up with something better to do with
progress messages and some way to determine when it should be done.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [StGit PATCH 2/2] Make bash completion fail to bashdefault before default completion.
From: Ted Pavlic @ 2009-01-22 16:44 UTC (permalink / raw)
To: catalin.marinas; +Cc: git, Ted Pavlic
In-Reply-To: <4978A0F1.9080703@tedpavlic.com>
If "-o bashdefault" isn't possible, use old "-o default" only.
(this patch inspired by similar mechanism in Mercurial bash completion
script)
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This patch corrects a bug in the previous one of the same name. In
particular, the second "complete" lacked the "||" in front of it needed
for proper operation. The first complete command should fail over to the
second if "bashdefault" isn't available.
stgit/completion.py | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/stgit/completion.py b/stgit/completion.py
index b3fd282..38f0670 100644
--- a/stgit/completion.py
+++ b/stgit/completion.py
@@ -129,7 +129,8 @@ def main_switch(commands):
'esac')
def install():
- return ['complete -o default -F _stg stg']
+ return ['complete -o bashdefault -o default -F _stg stg 2>/dev/null \\', [
+ '|| complete -o default -F _stg stg' ] ]
def write_completion(f):
commands = stgit.commands.get_commands(allow_cached = False)
--
1.6.1.213.g28da8
^ permalink raw reply related
* [PATCH 2/2] git-log: Follow file copies with 'git log --follow -C -C'
From: Arjen Laarhoven @ 2009-01-22 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <1232642245-94405-1-git-send-email-arjen@yaph.org>
When the '--follow' option is used with '--find-copies-harder' ('-C -C')
logs on individual files will work across file copies as well as
renames.
Intermediate copies will not be shown as a result of the workings of the
'--find-copies-harder' option.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
Documentation/git-log.txt | 6 +++++-
t/t4202-log.sh | 12 ++++++++++++
tree-diff.c | 2 ++
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 34cf4e5..2d42101 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -52,7 +52,11 @@ include::diff-options.txt[]
commits, and doesn't limit diff for those commits.
--follow::
- Continue listing the history of a file beyond renames.
+ Continue listing the history of a file beyond renames. When
+ combined with `--find-copies-harder` (`-C -C`) git will also
+ list the file history beyond copies. Intermediate copies
+ will be skipped, e.g. a copy of file A to B to C will not
+ show B when showing the log on file C.
--log-size::
Before the log message print out its size in bytes. Intended
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 7b976ee..a8dd690 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -109,6 +109,18 @@ test_expect_success 'git log --follow' '
'
+test_expect_success 'git log --follow --find-copies-harder' '
+
+ actual=$(git log --follow -C -C --pretty="format:%s" ein) &&
+ expect=$(echo fourth; echo third ; echo second ; echo initial) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
test_expect_success 'setup case sensitivity tests' '
echo case >one &&
test_tick &&
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..73652b2 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -333,6 +333,8 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_setup(&diff_opts);
DIFF_OPT_SET(&diff_opts, RECURSIVE);
+ if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER))
+ DIFF_OPT_SET(&diff_opts, FIND_COPIES_HARDER);
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
--
1.6.1.354.gd9e51
^ permalink raw reply related
* [PATCH 1/2] t/t4202-log.sh: Add testcases
From: Arjen Laarhoven @ 2009-01-22 16:37 UTC (permalink / raw)
To: git
Add testcases for 'git log --diff-filter=[CM]' (copies and renames).
Also add a testcase for 'git log --follow'.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
t/t4202-log.sh | 59 +++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 0ab925c..7b976ee 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -16,27 +16,31 @@ test_expect_success setup '
test_tick &&
git commit -m second &&
- mkdir a &&
- echo ni >a/two &&
- git add a/two &&
+ git mv one ichi &&
test_tick &&
git commit -m third &&
- echo san >a/three &&
- git add a/three &&
+ cp ichi ein &&
+ git add ein &&
test_tick &&
git commit -m fourth &&
- git rm a/three &&
+ mkdir a &&
+ echo ni >a/two &&
+ git add a/two &&
+ test_tick &&
+ git commit -m fifth &&
+
+ git rm a/two &&
test_tick &&
- git commit -m fifth
+ git commit -m sixth
'
test_expect_success 'diff-filter=A' '
actual=$(git log --pretty="format:%s" --diff-filter=A HEAD) &&
- expect=$(echo fourth ; echo third ; echo initial) &&
+ expect=$(echo fifth ; echo fourth ; echo third ; echo initial) &&
test "$actual" = "$expect" || {
echo Oops
echo "Actual: $actual"
@@ -60,7 +64,43 @@ test_expect_success 'diff-filter=M' '
test_expect_success 'diff-filter=D' '
actual=$(git log --pretty="format:%s" --diff-filter=D HEAD) &&
- expect=$(echo fifth) &&
+ expect=$(echo sixth ; echo third) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'diff-filter=R' '
+
+ actual=$(git log -M --pretty="format:%s" --diff-filter=R HEAD) &&
+ expect=$(echo third) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'diff-filter=C' '
+
+ actual=$(git log -C -C --pretty="format:%s" --diff-filter=C HEAD) &&
+ expect=$(echo fourth) &&
+ test "$actual" = "$expect" || {
+ echo Oops
+ echo "Actual: $actual"
+ false
+ }
+
+'
+
+test_expect_success 'git log --follow' '
+
+ actual=$(git log --follow --pretty="format:%s" ichi) &&
+ expect=$(echo third ; echo second ; echo initial) &&
test "$actual" = "$expect" || {
echo Oops
echo "Actual: $actual"
@@ -72,6 +112,7 @@ test_expect_success 'diff-filter=D' '
test_expect_success 'setup case sensitivity tests' '
echo case >one &&
test_tick &&
+ git add one
git commit -a -m Second
'
--
1.6.1.354.gd9e51
^ permalink raw reply related
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-22 16:50 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Brent Goodrick, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <e2b179460901220841h17c9eda2h38e8baff2964dac3@mail.gmail.com>
Hi,
On Thu, 22 Jan 2009, Mike Ralphson wrote:
> My $EDITOR is set to vim, as god intended. 8-)
Sorry, that is not true: from
http://www.biblegateway.com/passage/?book_id=50&chapter=1&verse=1&version=31&context=verse
we know that in the beginning was the Word.
Ciao,
Dscho
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-22 16:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Brent Goodrick, Mike Ralphson, Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901221117110.19665@iabervon.org>
Hi,
On Thu, 22 Jan 2009, Daniel Barkalow wrote:
> In any case, it's all done in progress.c, so it should be easy enough to
> make changes to if you can come up with something better to do with
> progress messages and some way to determine when it should be done.
Maybe "git --no-progress <program>" would be a sensible user interface?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-22 16:57 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: Junio C Hamano, git
In-Reply-To: <831vuvfh7t.fsf@kalahari.s2.org>
On Thu, Jan 22, 2009 at 6:17 PM, Hannu Koivisto <azure@iki.fi> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This brings back my previous question: where is the home directory in
>> a Windows system?
>
> It's where %HOMEDRIVE%%HOMEPATH% points to.
I thought it was something like that. Do we want something like that
in the manual, or should we assume Windows users know that?
--
Felipe Contreras
^ 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