* Re: [PATCH] Enable git rev-list to parse --quiet
From: Nick Andrew @ 2008-07-18 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvzeojm.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 17, 2008 at 10:42:21PM -0700, Junio C Hamano wrote:
> Thanks for noticing, but this replaces one breakage with another.
>
> Your new behaviour is a new "tell me if it is an empty set" option, and it
> means quite different thing from what --quiet does.
Fair enough. Yes, I want to find out if it is an empty set. The
manpage does say "fully connected" which I interpreted to mean
that one set of commits is a subset of the other..
I want to automatically (e.g. in crontab) update a git repo to the latest
HEAD from a remote branch ... but with the possibility that the local
repo has local changes, and I want no chance of merge failure. In other
words, "git fetch remote; git merge origin/master" and only do the
merge if it's a fast-forward. If there are any local commits, or local
uncommitted changes, then leave the local working tree alone.
So my idea was to use "git rev-list --quiet master ^origin/master"
and check the exit code; if zero do "git merge origin/master". Without
a working "--quiet" nor exit code I can pipe the output to "wc -l"
but is there a more efficient/reliable way to implement the requirement?
Nick.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-18 9:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Petr Baudis, Johannes Schindelin,
Git Mailing List
In-Reply-To: <200807181107.18098.jnareb@gmail.com>
On Fri, Jul 18, 2008 at 10:07 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
>> [...] It is understandable that you would
>> want to script something that recurses into the submodules that you have
>> checked out (or submodules that Fred wants you to look at), do the
>> equivalent of "git fetch ../fred" you did at the toplevel to automate that
>> step, but I very much agree with Pasky here in that it feels very wrong to
>> hijack "submodule update" for it.
>
> There were two proposals how to deal with fetching all submodules:
> (a) git-submodule recursing into submodules, IIRC even with some
> implementation (b) new "git submodule fetch" command.
>
Yes - I think there's a few more options and possible combinations
a. git submodule update having <repository> <refspec> to recurse into
submodules (a)(original patch)
b. git submodule fetch
c. git fetch --submodules
d. git fetch (automatically recurse if there are submodules)
e. git fetch (automatically recurse if there is some setting in .git/config)
I started at (a) and agree that it's a bad choice.
Any of b-e would work for me.
My (personal) preferences would be for d/e, then c, then b - but -
that's based on my belief that submodules are a pretty fundamental
thing and having a separate UI is bad.
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-18 9:16 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>
Hi,
_please_, trim the parts of quoted e-mails that you are not reacting
to. It makes your mails easier to read.
On Fri, Jul 18, 2008 at 09:11:53AM +0100, Nigel Magnay wrote:
> No.
> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
>
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
>
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
Ok! Handling this case makes sense, though I would have wished you to
word this use case this clearly from the beginning; or maybe I'm just
slow. :-)
Now, we (at least we two) agree that this use case is worth supporting,
I still don't like the solution you propose, though. The problem that we
are trying to solve is:
"How do we mass-supply custom submodule URLs when publishing the
customized main repository at a custom location too?"
Now, the most natural solution is for Fred to actually customize
.gitmodules content when committing the submodule updates:
(i) Either just give submodule update a hypothetical flag that will
ignore .git/config for that particular run or,
(ii) even much better, actually change logical submodule names in
.gitmodules; this is appropriate as you want the modules to actually
point at a significantly different repository. Thus,
[submodule "boo"]
path=boo
url=git://repo.or.cz/boo.git
will become
[submodule "boo/fred"]
path=boo
url=git://repo.or.cz/boo/fred.git
Also, you will be able to redefine the URL of boo/fred too in
.git/config (e.g. you're behind a firewall that lets only HTTP
through; I'm actually behind such a firewall these days at my
(non-SUSE ;) work).
This should be reasonably elegant, works with no Git changes, however
still has one significant problem - you very much do not want such a
.gitmodules change in any of the commits you merge, since it breaks
bisectability in case Fred or his repositories go away.
In that case, several possibilities come up on my mind:
(1) Fred will prepare special branch for testing with modified
.gitmodules and then for a merge he offers a different branch with clean
.gitmodules. This works, but it is obnoxious.
(2) Fred will pass a patch for .gitmodules as a part of his review
request. This works too and is obnoxious in slightly different aspects
than (1).
(3) Fred will offer a rewrite rule that you will pass to submodule
update, like your solution proposed, but much more universal so that it
is not tailored just to your particular repository hierarchy. A simple
sed script could work fine.
(4) Something else that I'm not realizing.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Re* git-remote SEGV on t5505 test.
From: Junio C Hamano @ 2008-07-18 9:13 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <48805D65.1060704@posdata.co.kr>
SungHyun Nam <namsh@posdata.co.kr> writes:
>> SungHyun, I did not test this patch myself (all my shells grok $() command
>> substitutions), so I won't be committing this until/unless I see a "tested
>> on system X and works fine".
>
> I tested it on Solaris and works fine. ^^
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-18 9:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080718175040.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>> + Teach git-merge -X<option> again.
>> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>> + builtin-merge.c: use parse_options_step() "incremental parsing"
>> machinery
>> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>>
>> This needs to be merged to master iff/when merge-theirs gets merged,
>> but I do not think this series is widely supported, so both are on hold.
>
> Why do you say it is not widely supported? I may be wrong but I think
> you developed these patches after somebody from the mailing list asked
> for this feature.
Well, for one thing, I do not believe in their cause. As I wrote in the
log messages for these commits (actually not these above which is a series
for merge fixup, but the other topic), I do not think it is a sensible
thing to say "let's take as much automerge results as possible to salvage
our changes where they do not overlap with what the upstream did, but I
would give up our changes to places that the upstream also touched,
because I do not understand what they did well enough to be able to
resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
that.
That also was the reason I did not add any documentation to it. But I do
like the change to the infrastructure to allow passing strategy-specific
options through git-merge and git-pull. Perhaps I should write something
up, if only to salvage that -X<option> part, even though I am very much
inclined to discard -Xtheirs (and -Xours) part.
^ permalink raw reply
* Re: Re* git-remote SEGV on t5505 test.
From: SungHyun Nam @ 2008-07-18 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5fjd7x5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> SungHyun Nam <namsh@posdata.co.kr> writes:
>>
>>> Is it possible that we can use 'SHELL_PATH' here?
>> It is not just possible but we really should. There are other test
>> scripts that use hardcoded /bin/sh, but by setting SHELL_PATH the user is
>> already telling us that what the vendor has in /bin/sh isn't adequately
>> POSIX enough, and we really should try to honor that.
>>
>> "git grep -n /bin/sh t/t*sh | grep -v ':1:#!'" would tell you which ones
>> are suspect.
>
> SungHyun, I did not test this patch myself (all my shells grok $() command
> substitutions), so I won't be committing this until/unless I see a "tested
> on system X and works fine".
I tested it on Solaris and works fine. ^^
$ uname -sro
SunOS 5.9 Solaris
$ SHELL_PATH=/bin/bash bash ./t9001-send-email.sh
* ok 1: prepare reference tree
* ok 2: Setup helper tool
* ok 3: Extract patches
* ok 4: Send patches
* ok 5: Verify commandline
* ok 6: Show all headers
* ok 7: reject long lines
* ok 8: no patch was sent
* ok 9: allow long lines with --no-validate
* ok 10: Invalid In-Reply-To
* ok 11: Valid In-Reply-To when prompting
* ok 12: setup fake editor
* ok 13: --compose works
* ok 14: first message is compose text
* ok 15: second message is patch
* ok 16: sendemail.cc set
* ok 17: sendemail.cc unset
* ok 18: --compose adds MIME for utf8 body
* ok 19: --compose respects user mime type
* ok 20: --compose adds MIME for utf8 subject
* passed all 20 test(s)
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Jakub Narebski @ 2008-07-18 9:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nigel Magnay, Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vwsjj8t3s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> [...] It is understandable that you would
> want to script something that recurses into the submodules that you have
> checked out (or submodules that Fred wants you to look at), do the
> equivalent of "git fetch ../fred" you did at the toplevel to automate that
> step, but I very much agree with Pasky here in that it feels very wrong to
> hijack "submodule update" for it.
There were two proposals how to deal with fetching all submodules:
(a) git-submodule recursing into submodules, IIRC even with some
implementation (b) new "git submodule fetch" command.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Junio C Hamano @ 2008-07-18 9:00 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nigel Magnay, Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <m363r3y42v.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> "Nigel Magnay" <nigel.magnay@gmail.com> writes:
>
>> Fred is a person (and != origin). His tree(s) are entirely correct and
>> consistent, and he doesn't yet wish to push to origin (and perhaps he
>> cannot, because he does not have permission to do so).
>> ...
> I _think_ that you can currently work around this problem by using
> URL rewriting (url.<base>.insteadOf).
Doesn't it also involve config modification?
I think the right thing to do for this kind of "trial merge" should be the
same as cases that do not involve submodules. You *DO NOT* give a handy
way to muck with your configuration to make "origin" point at fred.
Instead, you would do something like:
$ git fetch ../fred master
$ git checkout FETCH_HEAD
... review test fix ...
... when you are done, go back, discarding the state from Fred
$ git checkout master
What submodule changes from the above workflow would be what happens after
you switch to the trial state (the above example detaches HEAD temporarily
while peeking into Fred's history). It is understandable that you would
want to script something that recurses into the submodules that you have
checked out (or submodules that Fred wants you to look at), do the
equivalent of "git fetch ../fred" you did at the toplevel to automate that
step, but I very much agree with Pasky here in that it feels very wrong to
hijack "submodule update" for it.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-18 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk01hqzz.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
> + Teach git-merge -X<option> again.
> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
> + builtin-merge.c: use parse_options_step() "incremental parsing"
> machinery
> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>
> This needs to be merged to master iff/when merge-theirs gets merged,
> but I do not think this series is widely supported, so both are on hold.
Why do you say it is not widely supported? I may be wrong but I think you developed these patches after somebody from the mailing list asked for this feature.
You may find out people are enthusiastic about this only after you merge it to your master branch.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Jakub Narebski @ 2008-07-18 8:45 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Petr Baudis, Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>
"Nigel Magnay" <nigel.magnay@gmail.com> writes:
> On Thu, Jul 17, 2008 at 7:22 PM, Petr Baudis <pasky@suse.cz> wrote:
>> On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
>>> And it works, but
>>>
>>> $ git pull fred
>>> $ git submodule update
>>>
>>> Can leave you with problems, because if a submodule wasn't pushed to
>>> origin, you won't have it available. This is because the commands are
>>> equivalent to
>>>
>>> $ git pull fred
>>> for each submodule()
>>> cd submodule
>>> git fetch origin
>>> git checkout <sha1>
> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
>
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
>
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
>
> I'm trying to improve the UI for projects using submodules to make it
> mostly transparent; the best way I can come up with is to pick on
> individual usecases and show that they're a particular pain and that
> perhaps they don't need to be.
I _think_ that you can currently work around this problem by using
URL rewriting (url.<base>.insteadOf).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Andreas Ericsson @ 2008-07-18 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807161804400.8950@racer>
Johannes Schindelin wrote:
> Hi,
>
> there have been a number of occasions where I came across people trying to
> be helpful and teaching Git newbies a few tricks.
>
> However, in quite a number of cases, which seem to surge over the last
> weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list
> etc.
>
> Their rationale is invariably "but I found it useful", and they seem to be
> unable to recognize the puzzlement in the faces of the people they are
> trying to help.
>
> Instead they insist that they did nothing wrong.
>
> I had the pleasure of introducing Git to a few users in the last months
> and in my opinion, restricting myself to teaching them these commands
> first helped tremendously:
>
> - clone, pull, status, add, commit, push, log
>
> All of these were presented without options, to keep things simple.
>
> In particular, I refrained from giving them the "-a" option to commit.
> That seemed to help incredibly with their embracing the index as a natural
> concept (which it is).
>
> Often I presented the "pull" and "push" commands _only_ with "origin
> master" ("origin is where the repository came from, and master is the
> branch; you will want to use other parameters here after you used Git for
> a while").
>
> _After_ they grew comfortable with Git, I taught them a few options here
> and there, not hiding, but also not promoting the full range of options.
>
> So the next tricks were
>
> - log -p, rm, diff, diff --cached, show
>
> The last one is "show", and with that command, I taught the
> "<commit>:" and "<commit>:<file>" syntax, too (which some Git old-timers
> did not know about ;-)
>
Thanks for the excellent write-up. I wish I'd had this when I did the
introductory courses at my dayjob. With those simple commands, 90%
of the users get access to 90% of the usefulness of git, imo. And,
more importantly, it's enough to get them started right away.
> The pace needed to be adjusted to the users, in my experience, but not the
> order.
>
> Now, it makes me really, really sad that Git has a reputation of being
> complicated, but I regularly hear from _my_ users that they do not
> understand how that came about.
>
> Am I the only one who deems teaching plumbing to users ("I like it raw!
> So I teach it the same way!") harmful?
>
I wholeheartedly agree. Telling people about "git rev-list" on day one
is probably the single greatest mistake I've ever done wrt git. To the
non-gitizen, it takes some mumbo-jumbo arguments and spits out a long
list of mumbo-jumbo output. Had I started with "git log" instead, it
would have been infinitely easier to explain how each commit has a
totally unique name.
In addition, I'd recommend setting
color.branch=auto
color.diff=auto
color.pager=true
color.status=true
before starting the "course". It makes the learning experience a whole
lot nicer.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: stgit: bug with refresh and -p
From: Karl Hasselström @ 2008-07-18 8:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <9e4733910807171829q6abdcfc2m90c40a70dbc8fef5@mail.gmail.com>
On 2008-07-17 21:29:01 -0400, Jon Smirl wrote:
> A refresh with -p is not picking up newly added files.
>
> jonsmirl@terra:~/fs$ stg status
> ? include/linux/i2c/max9485.h
> jonsmirl@terra:~/fs$ git add include/linux/i2c/max9485.h
> jonsmirl@terra:~/fs$ stg refresh -p max9485
> Checking for changes in the working directory ... done
> Popping patches "jds-audio" - "jds-psc" ... done
> Refreshing patch "max9485" ... done
> Fast-forwarded patches "jds-psc" - "jds-audio"
> jonsmirl@terra:~/fs$ stg status
> ? include/linux/i2c/max9485.h
> jonsmirl@terra:~/fs$ stg --version
> Stacked GIT 0.14.3.163.g06f9
Hmm, I don't immediately see why this happens. I've posted a bug about
it: https://gna.org/bugs/index.php?12038
It's fixed by the refresh rewrite in my experimental branch, but
there's no test for it, so I had to check by hand.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-18 8:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080717182253.GZ32184@machine.or.cz>
On Thu, Jul 17, 2008 at 7:22 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
>> And it works, but
>>
>> $ git pull fred
>> $ git submodule update
>>
>> Can leave you with problems, because if a submodule wasn't pushed to
>> origin, you won't have it available. This is because the commands are
>> equivalent to
>>
>> $ git pull fred
>> for each submodule()
>> cd submodule
>> git fetch origin
>> git checkout <sha1>
>
> Oh! So, only after replying to most of your mail, I have realized what
> are you talking about all the time - _just_ this particular failure
> mode:
>
> "Someone pushed out a repository repointing submodules to
> invalid commits, and instead of waiting for the person to fix
> this breakage, we want to do a one-off fetch of all submodules
> from a different repository."
>
> There's nothing else you're trying to solve by this, right?
>
No.
"Someone says 'please review the state of my tree, _before_ I push it
out to a (central) repository"
Fred is a person (and != origin). His tree(s) are entirely correct and
consistent, and he doesn't yet wish to push to origin (and perhaps he
cannot, because he does not have permission to do so).
All the tutorials give credit to the fact that in git you don't need a
central server - you can pull directly from people. Except in the case
where you're using submodules, where you're basically forced to
hand-modify .git/config (in this instance, to point to where 'fred' is
storing his submodule trees) before doing a submodule update. This
makes git complicated for users.
I'm trying to improve the UI for projects using submodules to make it
mostly transparent; the best way I can come up with is to pick on
individual usecases and show that they're a particular pain and that
perhaps they don't need to be.
>
> Now, I think that this is a completely wrong problem to solve. Your
> gitweb is going to be broken, everyone has to jump through hoops because
> of this, and that all just because of a single mistake. It shouldn't
> have _happenned_ in the first place.
>
> So the proper solution for this should be to make an update hook that
> will simply not _let_ you push out a tree that's broken like this.
> Something like this (completely untested):
>
> die() { echo "$@"; exit 1; }
> git rev-list ^$2 $3 | while read commit; do
> git show $commit:.gitmodules >/tmp/gm$$
> git config -f /tmp/gm$$ --get-regexp 'submodule\..*\.path' |
> cut -d ' ' -f 1 |
> sed 's/^.*\.//; s/\..*$//;' |
> while read submodule; do
> path=$(git config -f /tmp/gm$$ "submodule.$submodule.path")
> url=$(git config -f /tmp/gm$$ "submodule.$submodule.url")
> entry=$(git ls-tree $commit "$path")
> [ -n "$entry" ] || die "submodule $submodule points at a non-existing path"
> [ "$(echo "$entry" | cut -d ' ' -f 1)" = "160000" ] || die "submodule $submodule does not point to a gitlink entry"
>
> subcommit="$(echo "$entry" | cut -d ' ' -f 2)"
> urlhash="$(echo "$url" | sha1sum | cut -d ' ' -f 1)"
> # We keep local copies of submodule repositories
> # for commit existence checking
> echo "Please wait, updating $url cache..."
> if [ -d /tmp/ucache/$urlhash ]; then
> (cd /tmp/ucache/$urlhash && git fetch)
> else
> git clone --bare "$url" /tmp/ucache/$urlhash
> fi
> [ "$(git --git-dir=/tmp/ucache/$urlhash cat-file -t "$subcommit" 2>/dev/null)" = "commit" ] || die "submodule $submodule does not point at an existing commit"
> done
> done
>
> Comments? If it seems good, it might be worth including in
> contrib/hooks/. Maybe even in the default update hook, controlled by
> a config option.
>
> All the troubles here stem from the fact that normally, Git will not let
> you push any invalid state to the server. This is not completely true in
> this case, but we should prevent this behaviour instead of inventing
> hacks to work it around.
>
>> Unless each submodule had a [remote] specified for "fred", you'd be
>> stuffed. But what you could do is either by passing the right URL, or
>> looking at the superproject [remote] for "fred" - i.e: If in the
>> superproject you have
>>
>> [remote "fred"]
>> url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
>> [submodule "module"]
>> url = ssh://git@repo/pub/scm/git/module.git
>>
>> Then the submodule "module" on fred, if it's a working-copy, can be calculated
>> ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git
>>
>> If it isn't a WC then you'd have to have a [remote "fred"] in that
>> submodule, but I'm thinking that'd be a rare case.
>
> This is ultra-evil. I think assuming things like this is extremely dirty
> and not reasonable for a universal code, _unless_ we explicitly decide
> that this is a new convention you want to introduce as a recommendation.
> But you should've been very clear about this upfront.
>
> _If_ you still insist on the one-off fetches for some reason, I think
> it's reasonable to provide your own simple script for your users that
> will autogenerate these URLs appropriately for your particular setup.
> I don't think there is any real need for a more generic solution.
>
>> I'd assumed (possibly wrongly?) that there was resistance to putting
>> any of the submodule logic in things other than git-submodules.
>
> Are you following the thread about submodule support for git mv, git rm?
>
> --
> Petr "Pasky" Baudis
> GNU, n. An animal of South Africa, which in its domesticated state
> resembles a horse, a buffalo and a stag. In its wild condition it is
> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
>
^ permalink raw reply
* Re: Git bash - is this MSYS bash or something else?
From: Lennart Borgman (gmail) @ 2008-07-18 8:06 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <288BA074-4995-47FB-BD22-75D36BF77A44@zib.de>
Steffen Prohaska wrote:
>
> On Jul 18, 2008, at 2:47 AM, Lennart Borgman (gmail) wrote:
>
>> I wonder if the bash.exe that comes with GIT is MSYS bash or a rewrite?
>
> It is the MSYS bash.
Thanks Steffen.
>> Does it follow the usual MSYS bash rules?
>
> What does this mean?
I just wondered if something was changed regarding starting of programs
from MSYS bash.
^ permalink raw reply
* Re: GSoC podcast 18: Git
From: Matthieu Moy @ 2008-07-18 7:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <alpine.DEB.1.00.0807170133150.4318@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi list,
>
> you might be interested in listening to Leslie Hawthorn interviewing Git's
> GSoC administrator (Shawn) and his lazy bum^Wbackup administrator (yours
> truly).
>
> I haven't seen it being mentioned on the official blog, but after waiting
> for over an hour, I figured I could just send the direct link:
>
> http://google-developer-podcast.googlecode.com/files/gsocpodcast018.ogg
Interesting.
Didn't listen the whole thing yet, but there's a sentence from Shawn
that summarizes really well the point behind private Vs public stuff:
"Make it look like you are a better programmer than you really are."
--
Matthieu
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Dmitry Potapov @ 2008-07-18 7:41 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5fk1ooq.fsf@lola.quinscape.zz>
On Thu, Jul 17, 2008 at 06:05:25PM +0200, David Kastrup wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Distinguishing between branch part of directory name by _convention_
> > is design mistake; the fact that the tool doesn't help to ensure that
> > (a) tags lie on branch (b) tags _doesn't change_ is an example of this
> > stupidity.
>
> How much have you worked with Subversion so far? I am doing quite a bit
> of work with it, and the do-everything-via-copying paradigm does not get
> in my hair. It actually means that I have to remember fewer commands.
> And it is pretty easy to understand.
Staying on trunk, try to compare your files foo and bar with version
1.0. With Git, it is simple
git v1.0 -- foo bar
but I don't think you can do that so easily with SVN.
But the real problem with the do-everything-via-copying paradigm is
that now revisions do not identify anything meaningful without some
path. This leads to problems if you try to implement merge. In Git,
it is simple -- merge is a commit with more than one parent. You cannot
do like that in SVN. Instead, you have to track merges per file. This
is not just waste of resources, but this merges is very difficult if
not impossible to visulize in any useful way. But if you cannot see
something, you cannot control it well. So, not accidently, in systems
with inter-file branching, creating feature branches is discouraged.
Besides having fewer commands doesn't necessary mean easier to learn
or to use. If you have one command that conflates different concepts,
it is usually more difficult than having a devote command per concept.
Can you remove the concept of branches and merges and have your VCS
still useful? Well, you can say "we don't use branches, every developer
commits directly on trunk". The consequence of that choice is that a lot
of work-in-progress code is pushed to trunk. But no one has the perfect
foresight. Some ideas will turn out to be not so good. Some developers
will not finish their work and will be reassigned to more urgent tasks.
As result, just as release time approaches, you have a lot of unfinished
crap in your trunk. Of course, if you don't care about quality of your
software, it may be easier for you to work in this way.
However, if you do care about quality, you have to use feature branches
for WIP, and for this workflow to work, you need that merging is really
easy. Git makes that for you, yet you may need to learn new concepts --
branching and merging. Thus comparision of what is easier or difficult
is meaningless without defining goals. It is always easy to be sloppy
and don't care...
Dmitry
^ permalink raw reply
* [PATCH] Add ANSI control code emulation for the Windows console
From: Johannes Sixt @ 2008-07-18 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Peter Harris, Johannes Sixt
In-Reply-To: <1216366485-12201-3-git-send-email-johannes.sixt@telecom.at>
From: Peter Harris <git@peter.is-a-geek.org>
This adds only the minimum necessary to keep git pull/merge's diffstat from
wrapping. Notably absent is support for the K (erase) operation, and support
for POSIX write.
Signed-off-by: Peter Harris <git@peter.is-a-geek.org>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 2 +-
compat/mingw.h | 11 ++
compat/winansi.c | 345 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 357 insertions(+), 1 deletions(-)
create mode 100644 compat/winansi.c
diff --git a/Makefile b/Makefile
index 78e08d3..2c6cc9d 100644
--- a/Makefile
+++ b/Makefile
@@ -740,7 +740,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat
COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
- COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o
+ COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o compat/winansi.o
EXTLIBS += -lws2_32
X = .exe
template_dir = ../share/git-core/templates/
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..5f11114 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -194,6 +194,17 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler);
#define signal mingw_signal
/*
+ * ANSI emulation wrappers
+ */
+
+int winansi_fputs(const char *str, FILE *stream);
+int winansi_printf(const char *format, ...) __attribute__((format (printf, 1, 2)));
+int winansi_fprintf(FILE *stream, const char *format, ...) __attribute__((format (printf, 2, 3)));
+#define fputs winansi_fputs
+#define printf(...) winansi_printf(__VA_ARGS__)
+#define fprintf(...) winansi_fprintf(__VA_ARGS__)
+
+/*
* git specific compatibility
*/
diff --git a/compat/winansi.c b/compat/winansi.c
new file mode 100644
index 0000000..e2d96df
--- /dev/null
+++ b/compat/winansi.c
@@ -0,0 +1,345 @@
+/*
+ * Copyright 2008 Peter Harris <git@peter.is-a-geek.org>
+ */
+
+#include <windows.h>
+#include "../git-compat-util.h"
+
+/*
+ Functions to be wrapped:
+*/
+#undef printf
+#undef fprintf
+#undef fputs
+/* TODO: write */
+
+/*
+ ANSI codes used by git: m, K
+
+ This file is git-specific. Therefore, this file does not attempt
+ to implement any codes that are not used by git.
+
+ TODO: K
+*/
+
+static HANDLE console;
+static WORD plain_attr;
+static WORD attr;
+static int negative;
+
+static void init(void)
+{
+ CONSOLE_SCREEN_BUFFER_INFO sbi;
+
+ static int initialized = 0;
+ if (initialized)
+ return;
+
+ console = GetStdHandle(STD_OUTPUT_HANDLE);
+ if (console == INVALID_HANDLE_VALUE)
+ console = NULL;
+
+ if (!console)
+ return;
+
+ GetConsoleScreenBufferInfo(console, &sbi);
+ attr = plain_attr = sbi.wAttributes;
+ negative = 0;
+
+ initialized = 1;
+}
+
+
+#define FOREGROUND_ALL (FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE)
+#define BACKGROUND_ALL (BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE)
+
+static void set_console_attr(void)
+{
+ WORD attributes = attr;
+ if (negative) {
+ attributes &= ~FOREGROUND_ALL;
+ attributes &= ~BACKGROUND_ALL;
+
+ /* This could probably use a bitmask
+ instead of a series of ifs */
+ if (attr & FOREGROUND_RED)
+ attributes |= BACKGROUND_RED;
+ if (attr & FOREGROUND_GREEN)
+ attributes |= BACKGROUND_GREEN;
+ if (attr & FOREGROUND_BLUE)
+ attributes |= BACKGROUND_BLUE;
+
+ if (attr & BACKGROUND_RED)
+ attributes |= FOREGROUND_RED;
+ if (attr & BACKGROUND_GREEN)
+ attributes |= FOREGROUND_GREEN;
+ if (attr & BACKGROUND_BLUE)
+ attributes |= FOREGROUND_BLUE;
+ }
+ SetConsoleTextAttribute(console, attributes);
+}
+
+static const char *set_attr(const char *str)
+{
+ const char *func;
+ size_t len = strspn(str, "0123456789;");
+ func = str + len;
+
+ switch (*func) {
+ case 'm':
+ do {
+ long val = strtol(str, (char **)&str, 10);
+ switch (val) {
+ case 0: /* reset */
+ attr = plain_attr;
+ negative = 0;
+ break;
+ case 1: /* bold */
+ attr |= FOREGROUND_INTENSITY;
+ break;
+ case 2: /* faint */
+ case 22: /* normal */
+ attr &= ~FOREGROUND_INTENSITY;
+ break;
+ case 3: /* italic */
+ /* Unsupported */
+ break;
+ case 4: /* underline */
+ case 21: /* double underline */
+ /* Wikipedia says this flag does nothing */
+ /* Furthermore, mingw doesn't define this flag
+ attr |= COMMON_LVB_UNDERSCORE; */
+ break;
+ case 24: /* no underline */
+ /* attr &= ~COMMON_LVB_UNDERSCORE; */
+ break;
+ case 5: /* slow blink */
+ case 6: /* fast blink */
+ /* We don't have blink, but we do have
+ background intensity */
+ attr |= BACKGROUND_INTENSITY;
+ break;
+ case 25: /* no blink */
+ attr &= ~BACKGROUND_INTENSITY;
+ break;
+ case 7: /* negative */
+ negative = 1;
+ break;
+ case 27: /* positive */
+ negative = 0;
+ break;
+ case 8: /* conceal */
+ case 28: /* reveal */
+ /* Unsupported */
+ break;
+ case 30: /* Black */
+ attr &= ~FOREGROUND_ALL;
+ break;
+ case 31: /* Red */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_RED;
+ break;
+ case 32: /* Green */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_GREEN;
+ break;
+ case 33: /* Yellow */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_RED | FOREGROUND_GREEN;
+ break;
+ case 34: /* Blue */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_BLUE;
+ break;
+ case 35: /* Magenta */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_RED | FOREGROUND_BLUE;
+ break;
+ case 36: /* Cyan */
+ attr &= ~FOREGROUND_ALL;
+ attr |= FOREGROUND_GREEN | FOREGROUND_BLUE;
+ break;
+ case 37: /* White */
+ attr |= FOREGROUND_RED |
+ FOREGROUND_GREEN |
+ FOREGROUND_BLUE;
+ break;
+ case 38: /* Unknown */
+ break;
+ case 39: /* reset */
+ attr &= ~FOREGROUND_ALL;
+ attr |= (plain_attr & FOREGROUND_ALL);
+ break;
+ case 40: /* Black */
+ attr &= ~BACKGROUND_ALL;
+ break;
+ case 41: /* Red */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_RED;
+ break;
+ case 42: /* Green */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_GREEN;
+ break;
+ case 43: /* Yellow */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_RED | BACKGROUND_GREEN;
+ break;
+ case 44: /* Blue */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_BLUE;
+ break;
+ case 45: /* Magenta */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_RED | BACKGROUND_BLUE;
+ break;
+ case 46: /* Cyan */
+ attr &= ~BACKGROUND_ALL;
+ attr |= BACKGROUND_GREEN | BACKGROUND_BLUE;
+ break;
+ case 47: /* White */
+ attr |= BACKGROUND_RED |
+ BACKGROUND_GREEN |
+ BACKGROUND_BLUE;
+ break;
+ case 48: /* Unknown */
+ break;
+ case 49: /* reset */
+ attr &= ~BACKGROUND_ALL;
+ attr |= (plain_attr & BACKGROUND_ALL);
+ break;
+ default:
+ /* Unsupported code */
+ break;
+ }
+ str++;
+ } while (*(str-1) == ';');
+
+ set_console_attr();
+ break;
+ case 'K':
+ /* TODO */
+ break;
+ default:
+ /* Unsupported code */
+ break;
+ }
+
+ return func + 1;
+}
+
+static int ansi_emulate(const char *str, FILE *stream)
+{
+ int rv = 0;
+ const char *pos = str;
+
+ while (*pos) {
+ pos = strstr(str, "\033[");
+ if (pos) {
+ size_t len = pos - str;
+
+ if (len) {
+ size_t out_len = fwrite(str, 1, len, stream);
+ rv += out_len;
+ if (out_len < len)
+ return rv;
+ }
+
+ str = pos + 2;
+ rv += 2;
+
+ fflush(stream);
+
+ pos = set_attr(str);
+ rv += pos - str;
+ str = pos;
+ } else {
+ rv += strlen(str);
+ fputs(str, stream);
+ return rv;
+ }
+ }
+ return rv;
+}
+
+int winansi_fputs(const char *str, FILE *stream)
+{
+ int rv;
+
+ if (!isatty(fileno(stream)))
+ return fputs(str, stream);
+
+ init();
+
+ if (!console)
+ return fputs(str, stream);
+
+ rv = ansi_emulate(str, stream);
+
+ if (rv >= 0)
+ return 0;
+ else
+ return EOF;
+}
+
+static int winansi_vfprintf(FILE *stream, const char *format, va_list list)
+{
+ int len, rv;
+ char small_buf[256];
+ char *buf = small_buf;
+ va_list cp;
+
+ if (!isatty(fileno(stream)))
+ goto abort;
+
+ init();
+
+ if (!console)
+ goto abort;
+
+ va_copy(cp, list);
+ len = vsnprintf(small_buf, sizeof(small_buf), format, cp);
+ va_end(cp);
+
+ if (len > sizeof(small_buf) - 1) {
+ buf = malloc(len + 1);
+ if (!buf)
+ goto abort;
+
+ len = vsnprintf(buf, len + 1, format, list);
+ }
+
+ rv = ansi_emulate(buf, stream);
+
+ if (buf != small_buf)
+ free(buf);
+ return rv;
+
+abort:
+ rv = vfprintf(stream, format, list);
+ return rv;
+}
+
+int winansi_fprintf(FILE *stream, const char *format, ...)
+{
+ va_list list;
+ int rv;
+
+ va_start(list, format);
+ rv = winansi_vfprintf(stream, format, list);
+ va_end(list);
+
+ return rv;
+}
+
+int winansi_printf(const char *format, ...)
+{
+ va_list list;
+ int rv;
+
+ va_start(list, format);
+ rv = winansi_vfprintf(stdout, format, list);
+ va_end(list);
+
+ return rv;
+}
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* [PATCH] Teach lookup_prog not to select directories
From: Johannes Sixt @ 2008-07-18 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Raible, Johannes Sixt
In-Reply-To: <1216366485-12201-1-git-send-email-johannes.sixt@telecom.at>
From: Eric Raible <raible@gmail.com>
Without this simple fix "git gui" in the git source directory
finds the git-gui directory instead of the tcl script in /usr/bin.
Signed-off-by: Eric Raible <raible@gmail.com>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..bb33c8d 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -536,7 +536,8 @@ static char *lookup_prog(const char *dir, const char *cmd, int isexe, int exe_on
return xstrdup(path);
path[strlen(path)-4] = '\0';
if ((!exe_only || isexe) && access(path, F_OK) == 0)
- return xstrdup(path);
+ if (!(GetFileAttributes(path) & FILE_ATTRIBUTE_DIRECTORY))
+ return xstrdup(path);
return NULL;
}
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Sixt @ 2008-07-18 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216366485-12201-2-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-clone.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 643c7d4..fddf47f 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -115,7 +115,7 @@ static char *guess_dir_name(const char *repo, int is_bundle)
if (!after_slash_or_colon)
end = p;
p += 7;
- } else if (*p == '/' || *p == ':') {
+ } else if (is_dir_sep(*p) || *p == ':') {
if (end == limit)
end = p;
after_slash_or_colon = 1;
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* [PATCH] Windows related patches
From: Johannes Sixt @ 2008-07-18 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
Eric Raible (1):
Teach lookup_prog not to select directories
Johannes Sixt (2):
builtin-clone: Use is_dir_sep() instead of '/'
Windows: set gitexecdir = $(bindir)
Peter Harris (1):
Add ANSI control code emulation for the Windows console
^ permalink raw reply
* [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-18 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216366485-12201-4-git-send-email-johannes.sixt@telecom.at>
The "dash-less" change aims to remove git commands from $PATH. It does so
by defining a GIT_EXEC_PATH that is different from $(bindir). On Windows
we want a relocatable installation of the git tool, so we cannot use an
absolute GIT_EXEC_PATH. Therefore, the implementation of
builtin_exec_path() on Windows derives the exec-path from the command
invocation, and disregards GIT_EXEC_PATH. But this broke when
$(gitexecdir) became different from $(bindir), so we restore the earlier
behavior here.
This counteracts the aims of the "dash-less" change on Windows, but better
this way than having no working git at all.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 36339d3..7d466b3 100644
--- a/Makefile
+++ b/Makefile
@@ -742,6 +742,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o compat/winansi.o
EXTLIBS += -lws2_32
X = .exe
+ gitexecdir = $(bindir)
template_dir = ../share/git-core/templates/
ETC_GITCONFIG = ../etc/gitconfig
endif
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* Re: Re* git-remote SEGV on t5505 test.
From: Junio C Hamano @ 2008-07-18 6:26 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <7vsku7d8ak.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> SungHyun Nam <namsh@posdata.co.kr> writes:
>
>> Is it possible that we can use 'SHELL_PATH' here?
>
> It is not just possible but we really should. There are other test
> scripts that use hardcoded /bin/sh, but by setting SHELL_PATH the user is
> already telling us that what the vendor has in /bin/sh isn't adequately
> POSIX enough, and we really should try to honor that.
>
> "git grep -n /bin/sh t/t*sh | grep -v ':1:#!'" would tell you which ones
> are suspect.
SungHyun, I did not test this patch myself (all my shells grok $() command
substitutions), so I won't be committing this until/unless I see a "tested
on system X and works fine".
^ permalink raw reply
* Re: [PATCH 2/2 v2] git-gui: "Stage Line": Treat independent changes in adjacent lines better
From: Junio C Hamano @ 2008-07-18 6:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <1216300911-5170-1-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Assume that we want to commit these states:
>
> Old state == HEAD Intermediate state New state
> --------------------------------------------------------
> context before context before context before
> old 1 new 1 new 1
> old 2 old 2 new 2
> context after context after context after
Much easier to understand. Thanks.
^ permalink raw reply
* Re* git-remote SEGV on t5505 test.
From: Junio C Hamano @ 2008-07-18 6:18 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <48802DCD.2090704@posdata.co.kr>
SungHyun Nam <namsh@posdata.co.kr> writes:
> Is it possible that we can use 'SHELL_PATH' here?
It is not just possible but we really should. There are other test
scripts that use hardcoded /bin/sh, but by setting SHELL_PATH the user is
already telling us that what the vendor has in /bin/sh isn't adequately
POSIX enough, and we really should try to honor that.
"git grep -n /bin/sh t/t*sh | grep -v ':1:#!'" would tell you which ones
are suspect.
---
t/t9001-send-email.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index de5b980..1c857cf 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -13,7 +13,7 @@ test_expect_success \
test_expect_success \
'Setup helper tool' \
- '(echo "#!/bin/sh"
+ '(echo "#!$SHELL_PATH"
echo shift
echo output=1
echo "while test -f commandline\$output; do output=\$((\$output+1)); done"
@@ -138,7 +138,7 @@ test_expect_success 'Valid In-Reply-To when prompting' '
'
test_expect_success 'setup fake editor' '
- (echo "#!/bin/sh" &&
+ (echo "#!$SHELL_PATH" &&
echo "echo fake edit >>\"\$1\""
) >fake-editor &&
chmod +x fake-editor
@@ -235,7 +235,7 @@ test_expect_success 'sendemail.cc unset' '
test_expect_success '--compose adds MIME for utf8 body' '
clean_fake_sendmail &&
- (echo "#!/bin/sh" &&
+ (echo "#!$SHELL_PATH" &&
echo "echo utf8 body: àéìöú >>\"\$1\""
) >fake-editor-utf8 &&
chmod +x fake-editor-utf8 &&
@@ -254,7 +254,7 @@ test_expect_success '--compose adds MIME for utf8 body' '
test_expect_success '--compose respects user mime type' '
clean_fake_sendmail &&
- (echo "#!/bin/sh" &&
+ (echo "#!$SHELL_PATH" &&
echo "(echo MIME-Version: 1.0"
echo " echo Content-Type: text/plain\\; charset=iso-8859-1"
echo " echo Content-Transfer-Encoding: 8bit"
^ permalink raw reply related
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Junio C Hamano @ 2008-07-18 6:10 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <7v8wvzeojm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nick Andrew <nick@nick-andrew.net> writes:
> ...
>> After fix:
>
> Thanks for noticing, but this replaces one breakage with another.
>
> Your new behaviour is a new "tell me if it is an empty set" option, and it
> means quite different thing from what --quiet does.
And here is how I would do it if I were interested in such a feature.
-- >8 --
rev-list --check-empty
This new option squelches the output entirely and signals if the specified
set is empty by its exit status. E.g.
$ git rev-list --check-empty HEAD..HEAD
will exit with a non-zero status, and
$ git rev-list --check-empty HEAD^..HEAD
will exit with zero status.
---
builtin-rev-list.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 507201e..4f9cce9 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -52,6 +52,7 @@ static const char rev_list_usage[] =
static struct rev_info revs;
+static int check_empty;
static int bisect_list;
static int show_timestamp;
static int hdr_termination;
@@ -161,6 +162,8 @@ static void show_commit(struct commit *commit)
static void finish_commit(struct commit *commit)
{
+ if (check_empty)
+ exit(0);
if (commit->parents) {
free_commit_list(commit->parents);
commit->parents = NULL;
@@ -171,6 +174,8 @@ static void finish_commit(struct commit *commit)
static void finish_object(struct object_array_entry *p)
{
+ if (check_empty)
+ exit(0);
if (p->item->type == OBJ_BLOB && !has_sha1_file(p->item->sha1))
die("missing blob object '%s'", sha1_to_hex(p->item->sha1));
}
@@ -593,6 +598,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
for (i = 1 ; i < argc; i++) {
const char *arg = argv[i];
+ if (!strcmp(arg, "--check-empty")) {
+ check_empty = 1;
+ continue;
+ }
if (!strcmp(arg, "--header")) {
revs.verbose_header = 1;
continue;
@@ -650,6 +659,9 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
+ if (check_empty)
+ quiet = 1;
+
if (revs.tree_objects)
mark_edges_uninteresting(revs.commits, &revs, show_edge);
@@ -699,6 +711,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
traverse_commit_list(&revs,
quiet ? finish_commit : show_commit,
quiet ? finish_object : show_object);
-
+ if (check_empty)
+ exit(1);
return 0;
}
^ 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