* Re: qgit question: tagged commits not on a branch
From: Michael J Gruber @ 2009-11-27 15:15 UTC (permalink / raw)
To: Chris.Cheney; +Cc: git
In-Reply-To: <Xns9CCFDEF02D061ChrisCheneytesconet@80.91.229.13>
Chris.Cheney venit, vidit, dixit 26.11.2009 22:54:
> My commit graph has a number of forks (I can't use the word "branches"
> here) that are referenced only by a tag. Whereas gitk --all displays this
> graph including those forks, qgit does not display those forks - I don't
> see a way to make it do so, other than by adding branches to those tagged
> commits.
>
> Have I overlooked something?
>
qgit --all does it for me. It may not be the newest qgit, though.
I use tags like that to mark a version of a topic branch before
rebasing, so that on old version won't be gc'ed away and the branch name
space is not too crowded. Poor man's topgit, so to say. I guess it's a
common use case.
Michael
^ permalink raw reply
* Re: change URL
From: Michael J Gruber @ 2009-11-27 15:09 UTC (permalink / raw)
To: Jan Krüger; +Cc: Rakotomandimby Mihamina, git
In-Reply-To: <20091127122228.660131af@perceptron>
Jan Krüger venit, vidit, dixit 27.11.2009 12:22:
> Hi,
>
> Rakotomandimby Mihamina <mihamina@gulfsat.mg> wrote:
>
>> When I first cloned a project, I used the non fully qualified hostname
>> if the repo:
>> $ git clone ssh://git/git/Mailaka
>> [...]
>> What should I edit to make "git push" uses "git.rktmb.org" rather
>> than "git.domainsearch-in-resolv.conf"?
>
> it's in .git/config, and it's rather easy to find there.
>
> Jan
:)
git config remote.origin.url ssh://git.rktmb.org/git/Mailaka
Cheers,
Michael
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 07/11] run-command: support input-fd
From: Erik Faye-Lund @ 2009-11-27 14:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911262253.59641.j6t@kdbg.org>
On Thu, Nov 26, 2009 at 10:53 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> @@ -327,7 +327,10 @@ int start_async(struct async *async)
>> {
>> int pipe_out[2];
>>
>> - if (pipe(pipe_out) < 0)
>> + if (async->out) {
>> + pipe_out[0] = dup(async->out);
>> + pipe_out[1] = dup(async->out);
>> + } else if (pipe(pipe_out) < 0)
>> return error("cannot create pipe: %s", strerror(errno));
>> async->out = pipe_out[0];
>
> Hm. If async->out != 0:
>
> pipe_out[0] = dup(async->out);
> async->out = pipe_out[0];
>
> This is confusing.
What do you find confusing about it? The idea is to use a provided
bi-directional fd instead of a pipe if async->out is non-zero. The
currently defined rules for async is that async->out must be zero
(since the structure should be zero-initialized).
> Moreover, you are assigning (a dup of) the same fd to the writable end. This
> assumes a bi-directional channel. I don't yet know what I should think about
> this (haven't studied the later patches, yet).
>
Indeed it does. Do we want to extend it to support a set of
unidirectional channels instead?
> It would be great if you could add a few words to
> Documentation/technical/api-runcommand.txt.
>
Ah, yes. I know I should update the documentation and all, I'm just
usually really bad (*cough* lazy *cough*) at documenting stuff. But
I'll give it a go and if people hate what I write, they can suggest
changes.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Breaking expectations in 1.7.0, was Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Johannes Schindelin @ 2009-11-27 14:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091127144553.GA24366@progeny.tock>
Hi,
On Fri, 27 Nov 2009, Jonathan Nieder wrote:
> If --full-tree does become the default, I think it should be in 1.7.0,
> when it is expected for some habits to break (with a configuration
> variable for the transition, I guess).
I recently read more and more about 1.7.0 being expected to break
expectations, and more and more expectations about more and more being
expected to be broken there.
This is a very slippery slope. You have been warned.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Jonathan Nieder @ 2009-11-27 14:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091127065904.GE20844@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 05:03:33PM -0800, Junio C Hamano wrote:
>> * jc/grep-full-tree (2009-11-24) 1 commit.
>> - grep: --full-tree
>>
>> We probably would want test, doc and a configuration variable to make it
>> default (or non-default) before we can merge it to 'master'.
>
> I can try to pick this up. But did we reach a decision on having a
> configuration variable?
I am not sure, but I will say I would prefer not to have one. Surely
we can come up with a UI that does not require searching through
git-config(1) to be made convenient.
Couldn’t we just add the option (with test and documentation) first,
to get some experience with how we end up using the two forms?
If --full-tree does become the default, I think it should be in 1.7.0,
when it is expected for some habits to break (with a configuration
variable for the transition, I guess). This might be okay, since
constructions like 'git grep foo -- "./*.h"' should still work.
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 08/11] daemon: use explicit file descriptor
From: Erik Faye-Lund @ 2009-11-27 14:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911262303.57228.j6t@kdbg.org>
Sorry for the long delay in the reply, but I'm a little low on time
these days (and I've already spent some time trying to figure out what
I was thinking - I wrote these patches a while ago).
On Thu, Nov 26, 2009 at 11:03 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> @@ -372,37 +372,35 @@ static int run_service_command(const char **argv)
>> cld.argv = argv;
>> cld.git_cmd = 1;
>> cld.err = -1;
>> + cld.in = cld.out = fd;
>
> You shouldn't do that. In fact, the next patch 9 has a hunk that correctly
> calls dup() once.
>
OK, as long as it works as expected, sure. But perhaps this needs a
little change (see discussion later)
>> - close(0);
>> - close(1);
>
> Here, stdin and stdout were closed and start_command() used both. But these
> two new calls
>
>> + exit(execute(0, addr));
>> ...
>> + return execute(0, peer);
>
> are the only places where a value is assigned to fd. Now it is always only
> stdin. Where does the old code initialize stdout? Shouldn't this place need a
> change, too?
The "dup2(incoming, 0)"-call in handle() is AFAICT what makes it work
to use the forked process' stdin as both stdin and stdout for the
service-process pipe (since fd 0 now becomes a pipe that is both
readable and writable). This isn't exactly a pretty mechanism, and I
guess I should rework it. At the very least, I should remove the
"dup2(incoming, 1)"-call, but I'm open to other suggestions. Perhaps I
can change this patch to do the entire socket-passing (which is
currently in the next patch)?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] pull: clarify advice for the unconfigured error case
From: Jonathan Nieder @ 2009-11-27 14:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jan Krüger, Jeff King, Jan Nieuwenhuizen, Tomas Carnecky,
git list
In-Reply-To: <20091113040754.GA3255@progeny.tock>
From: Jan Krüger <jk@jk.gs>
When pull --rebase fails because it cannot find what branch to
merge against, the error message implies we are trying to merge.
Say "rebase against" instead of "merge with" to avoid confusion.
The configuration suggested to remedy the situation uses a
confusing syntax, with variables specified in the dotted form
accepted by 'git config' but separated from their values by the
'=' delimiter used by config files. Since the user will have to
edit this output anyway, it is more helpful to provide a config
file snippet to paste into an editor and modify.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> Jan Krüger wrote:
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
>[...]
>> if [ $# -gt 1 ]; then
>> - echo "There are no candidates for merging in the refs that you just fetched."
>> + echo "There are no candidates for using the refs that you just fetched."
>> echo "Generally this means that you provided a wildcard refspec which had no"
>> echo "matches on the remote end."
>
> This sounds a little awkward to me, maybe because all the remote refs
> are being used to populate the remotes/<remote>/* hierarchy.
Scratch that --- I was confused.
I still find pull pretty confusing. In its three forms, it does
different things:
- 'git pull' fetches from the current branch’s remote (both its
standard fetch refspec and the current branch’s), then merges any
branches that match the current branch’s refspec.
- 'git pull foo' fetches from the specified remote. If it is
the current branch’s remote, this is just a synonym for
'git pull'; otherwise, it first fetches and then complains.
- 'git pull foo refspec' does a fetch according to the specified
refspec, and if any branches match, merges them into the
current branch.
I was worried about the first form before (but who uses wildcards
in their branches’ refspecs?), but as Peff explains in commit
a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) the third one should be much more common.
In the --rebase case, exactly one branch would have to match for
this to make any sense (there is no such thing as an octopus
rebase), so I reworded the message accordingly.
git-pull.sh | 48 +++++++++++++++++++++++++++++++++---------------
1 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..2c384c4 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,63 @@ error_on_no_merge_candidates () {
esac
done
+ if test true = "$rebase"
+ then
+ op_type=rebase
+ op_prep=against
+ else
+ op_type=merge
+ op_prep=with
+ fi
+
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
- echo "There are no candidates for merging in the refs that you just fetched."
+ if [ "$rebase" = true ]; then
+ printf "There is no candidate for rebasing against "
+ else
+ printf "There are no candidates for merging "
+ fi
+ echo "among the refs that you just fetched."
echo "Generally this means that you provided a wildcard refspec which had no"
echo "matches on the remote end."
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
echo "You asked to pull from the remote '$1', but did not specify"
- echo "a branch to merge. Because this is not the default configured remote"
+ echo "a branch. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which branch you want to merge on the command"
+ echo "Please specify which remote branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "specify which branch you want to merge on the command line and"
+ echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me, either. Please"
+ echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
+ echo "If you often $op_type $op_prep the same branch, you may want to"
+ echo "use something like the following in your configuration file:"
+ echo
+ echo " [branch \"${curr_branch}\"]"
+ echo " remote = <nickname>"
+ echo " merge = <remote-ref>"
+ test rebase = "$op_type" &&
+ echo " rebase = true"
echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
+ echo " [remote \"<nickname>\"]"
+ echo " url = <url>"
+ echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
- echo "remote, but no such ref was fetched."
+ echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+ echo "from the remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.3
^ permalink raw reply related
* Re: change URL
From: Jan Krüger @ 2009-11-27 11:22 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B0FA253.6060804@gulfsat.mg>
Hi,
Rakotomandimby Mihamina <mihamina@gulfsat.mg> wrote:
> When I first cloned a project, I used the non fully qualified hostname
> if the repo:
> $ git clone ssh://git/git/Mailaka
> [...]
> What should I edit to make "git push" uses "git.rktmb.org" rather
> than "git.domainsearch-in-resolv.conf"?
it's in .git/config, and it's rather easy to find there.
Jan
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 10:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <vpq8wdsqmm4.fsf@bauges.imag.fr>
Hi,
On Fri, 27 Nov 2009, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Guess what. I have a similar problem, only it is that my "git status"
> > output is _always_ too long, so I always have to page it.
> >
> > Once upon a time, Junio applied a patch that implied -p with status.
> > I was overjoyed. He reverted that patch later. Yes, exactly.
>
> In this particular example, a config variable was added (pager.status =
> true). But one big difference is that while pager.status = true can be
> /annoying/ for some users, it can never really harm (since the pager
> will automatically disable itself in the cases where you'd really don't
> want it).
It changes behavior. And worse: it changes behavior _in a different
manner_ in different repositories. I have too many of them to remember
what I set where.
So it is harmful in a very real sense.
> > So I end up doing "git config --global ps '-p status'" on every new
> > account (I usually even forget to curse!), and I really cannot see why you
> > do not do the equivalent "git config fullgrep grep --full-tree" in your
> > repositories (or even the global thing).
>
> (I guess you meant alias.fullgrep)
You guessed right, and likewise alias.ps.
Ciao,
Dscho
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Martin Langhoff @ 2009-11-27 10:56 UTC (permalink / raw)
To: Thomas Singer; +Cc: Jay Soffian, Daniel Barkalow, git
In-Reply-To: <4B0FA7D7.1050302@syntevo.com>
On Fri, Nov 27, 2009 at 11:20 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
>> toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
>> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
>
> OK, I've found it. This works (I have to complete the file name after having
> typed an U):
>
> toms-mac-mini:git-umlauts tom$ git rm --cached Überlänge.txt
Tom,
have you tried calling git-update-index --add
--stdin -z? Your original email stated
> we've got a problem report regarding our SmartGit GUI client
so it sounds like you are building a porcelain. In that case, the
sanest approach is to invoke git-update-index and write to its stdin.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 10:53 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127095914.GA4865@sigill.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:
>
> > Guess what. I have a similar problem, only it is that my "git status"
> > output is _always_ too long, so I always have to page it.
> >
> > Once upon a time, Junio applied a patch that implied -p with status.
> > I was overjoyed. He reverted that patch later. Yes, exactly.
> >
> > So I end up doing "git config --global ps '-p status'" on every new
>
> If only somebody had written a "pager.status" configuration variable,
> you could use that. Oh wait. I did. And it shipped in v1.6.0.
And it makes things inconsistent. That is why I do not use it. Do you
work on 10 different computers? I do. And nothing is more unnerving than
the same command producing something different on the different computers.
Sure, after a few minutes of fiddling I find out that it was my fault to
begin with, but dammit! if the tool makes it that hard already for an
expert, it is outright unusable for new users.
I, for one, do not like Git's reputation, but I am tired of trying to
fight for the users. BTW quick question: how many Git _users_ were at the
GitTogether at MV? 0?
> > account (I usually even forget to curse!), and I really cannot see why
> > you do not do the equivalent "git config fullgrep grep --full-tree" in
> > your repositories (or even the global thing).
> >
> > The further benefit is that we stop talking about breaking backwards
> > compatibility, and we stop talking about making it hard for Git
> > experts to help newbies.
>
> I guess you missed the part of the thread where I already discussed
> this. It was here:
>
> http://article.gmane.org/gmane.comp.version-control.git/133672
I only skimmed it, yes. And I did not plan to participate in this thread.
But it seems that my views are not represented enough, even if gitzilla
chimed in with the very valid, under-acknowledged and over-ignored
message: consistency is good. Corollary: inconsistency is bad.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Matthieu Moy @ 2009-11-27 10:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Guess what. I have a similar problem, only it is that my "git status"
> output is _always_ too long, so I always have to page it.
>
> Once upon a time, Junio applied a patch that implied -p with status. I
> was overjoyed. He reverted that patch later. Yes, exactly.
In this particular example, a config variable was added (pager.status
= true). But one big difference is that while pager.status = true can
be /annoying/ for some users, it can never really harm (since the
pager will automatically disable itself in the cases where you'd
really don't want it).
OTOH, a config variable that actually changes the beahvior of the
command can indeed harm. Those who ever tried doing portable
programming in PHP, where the apache config can actually change the
semantics of the language probably understand what I mean ;-).
> So I end up doing "git config --global ps '-p status'" on every new
> account (I usually even forget to curse!), and I really cannot see why you
> do not do the equivalent "git config fullgrep grep --full-tree" in your
> repositories (or even the global thing).
(I guess you meant alias.fullgrep)
Maybe "mygrep" or "dwimgrep" would be a better name, except for the
difficulty to type it: the same alias can be defined to different
things on different machines.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-27 10:20 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0FA388.4030507@syntevo.com>
Thomas Singer wrote:
> Jay Soffian wrote:
>>> toms-mac-mini:git-umlauts tom$ git status
>>> # On branch master
>>> #
>>> # Initial commit
>>> #
>>> # Changes to be committed:
>>> # (use "git rm --cached <file>..." to unstage)
>>> #
>>> # new file: "U\314\210berla\314\210nge.txt"
>>> #
>> Wait, what's the problem here? It's staged according to the above,
>> just commit it.
>
> You are completely right and I feel quite foolish.
>
> What about this one:
>
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
> toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
OK, I've found it. This works (I have to complete the file name after having
typed an U):
toms-mac-mini:git-umlauts tom$ git rm --cached Überlänge.txt
--
Tom
^ permalink raw reply
* change URL
From: Rakotomandimby Mihamina @ 2009-11-27 9:56 UTC (permalink / raw)
To: git
Hi all,
When I first cloned a project, I used the non fully qualified hostname
if the repo:
$ git clone ssh://git/git/Mailaka
When pushing, it was OK:
$ git push
mihamina@git's password:
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 825 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git/git/Mailaka
1e91a44..8af5c57 master -> master
Now, I am on a slow network, with a different search domain in resolv.conf.
What should I edit to make "git push" uses "git.rktmb.org" rather than "git.domainsearch-in-resolv.conf"?
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-27 10:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Barkalow, git
In-Reply-To: <76718490911260927h9ff796bgbebcccab7e52ffbe@mail.gmail.com>
Jay Soffian wrote:
>> toms-mac-mini:git-umlauts tom$ git status
>> # On branch master
>> #
>> # Initial commit
>> #
>> # Changes to be committed:
>> # (use "git rm --cached <file>..." to unstage)
>> #
>> # new file: "U\314\210berla\314\210nge.txt"
>> #
>
> Wait, what's the problem here? It's staged according to the above,
> just commit it.
You are completely right and I feel quite foolish.
What about this one:
toms-mac-mini:git-umlauts tom$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: "U\314\210berla\314\210nge.txt"
#
toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
--
Thanks in advance,
Tom
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-27 9:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302>
On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:
> Guess what. I have a similar problem, only it is that my "git status"
> output is _always_ too long, so I always have to page it.
>
> Once upon a time, Junio applied a patch that implied -p with status. I
> was overjoyed. He reverted that patch later. Yes, exactly.
>
> So I end up doing "git config --global ps '-p status'" on every new
If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.
> account (I usually even forget to curse!), and I really cannot see why you
> do not do the equivalent "git config fullgrep grep --full-tree" in your
> repositories (or even the global thing).
>
> The further benefit is that we stop talking about breaking backwards
> compatibility, and we stop talking about making it hard for Git experts to
> help newbies.
I guess you missed the part of the thread where I already discussed
this. It was here:
http://article.gmane.org/gmane.comp.version-control.git/133672
-Peff
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Johannes Schindelin @ 2009-11-27 9:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B0F8825.3040107@viscovery.net>
Hi,
On Fri, 27 Nov 2009, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> The list of header files was incomplete because a number of header files
> were added to the code base, but were not added to the list LIB_H that we
> have in the Makefile. This meant that no rebuild was triggered if one of
> the missing headers was changed because we do not have automatic
> dependency tracking, either.
>
> Sidestep the issue by computing the list using $(wildcard).
Funny; I thought that not all header files are library header files, i.e.
not all header changes should trigger a full new build of libgit.a.
Am I wrong?
Ciao,
Dscho
P.S.: Something that comes to mind is the http.h header, which should
really be independent of libgit.a. Which reminds me: do we _still_ tell
libgit.a at _compile time_ whether git-remote-http is compiled with cURL?
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 9:31 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127062013.GA20844@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:
>
> > On Wed, Nov 25, 2009 at 3:20 PM, Jeff King <peff@peff.net> wrote:
> > > Sure, there are all those downsides. But what is the other option?
> > > Making me use the command line option (or pathspec magic) every
> > > single time I invoke git grep?
> >
> > Yes, but only when you want non-default behavior, not every single
> > time.
>
> Did you miss the part of the thread where I explained that in certain
> repos, I want it one way every single time, and in others, I want it the
> other way?
Guess what. I have a similar problem, only it is that my "git status"
output is _always_ too long, so I always have to page it.
Once upon a time, Junio applied a patch that implied -p with status. I
was overjoyed. He reverted that patch later. Yes, exactly.
So I end up doing "git config --global ps '-p status'" on every new
account (I usually even forget to curse!), and I really cannot see why you
do not do the equivalent "git config fullgrep grep --full-tree" in your
repositories (or even the global thing).
The further benefit is that we stop talking about breaking backwards
compatibility, and we stop talking about making it hard for Git experts to
help newbies.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a notice that only certain functions can print color escape codes
From: Michael J Gruber @ 2009-11-27 9:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B0F82E1.80402@viscovery.net>
Johannes Sixt venit, vidit, dixit 27.11.2009 08:42:
> Junio C Hamano schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Like this?
>>
>> Yeah, and in addition to "puts", "write(2)" is also not supported, right?
>
> Correct, good catch!
>
> --- 8< ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] Add a notice that only certain functions can print color escape codes
>
> We emulate color escape codes on Windows by overriding printf, fprintf,
> and fputs. Warn users that these are the only functions that can be used
> to print them.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> color.h | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/color.h b/color.h
> index 7d8da6f..3cb4b7f 100644
> --- a/color.h
> +++ b/color.h
> @@ -4,6 +4,11 @@
> /* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
> #define COLOR_MAXLEN 24
>
> +/*
> + * IMPORTANT: Due to the way these color codes are emulated on Windows,
> + * write them only using printf(), fprintf(), and fputs(). In particular,
> + * do not use puts() or write().
Nor putchar nor putc... but they're part of the puts family, of course.
More worthwhile then listing those negatives could be a hint on another
positive: color_fprintf and friends which are declared at the end of
color.h.
> + */
> #define GIT_COLOR_NORMAL ""
> #define GIT_COLOR_RESET "\033[m"
> #define GIT_COLOR_BOLD "\033[1m"
^ permalink raw reply
* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-11-27 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vws1cwnu0.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.11.2009 06:15:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> * Should I rename wt-status.c's color() into something more unique when
>> I export it?
>
> Is it an option to instead move short_unmerged(), short_status() and
> friends to wt-status.c from builtin-commit.c? It's been quite a while
> since I worked on the code, so I don't recall why it needs such cross
> references at low level between two files.
I didn't notice, but I'll look into it during the rewrite.
>> * Is there any policy regarding use of putchar/puts vs. printf?
>
> J6t addressed it. You have mixture of putchar(' ') and printf(" ") which
> looks somewhat funny ;-)
;) I'm happy with printf("c"), I just thought someone would find printf
overkill for a format less char.
>> * The way it is done now I "color" a space, otherwise one would need to
>> break down the print statements even more. Since we always color the
>> foreground only it is no problem, is it?
>
> Some people do configure to use "reverse". For example, I have:
>
> [diff.color]
> old = red reverse
> whitespace = blue reverse
>
> [status.color]
> updated = green
> changed = red
> untracked = blue reverse
>
> The output should be consistent between long and short format (I do not
> offhand recall what we do for the long format, though).
Oh, I didn't know about reverse. In this case I have to change the code
and leave the space alone. (The one between ?? and the filename.) Will do.
In the long format, only the file name is colored. Note that in the
short format, it does not make sense to color the file name because one
line may represent two pieces of status information. That is why I color
the two status letters and not the file name.
Michael
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-27 8:59 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Jeff King, git
In-Reply-To: <36ca99e90911270044o68375902l3a0d2a4afa726a91@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> Maybe you missed v2 (Message-Id:
> <1258557087-31540-1-git-send-email-bert.wesarg@googlemail.com>)? Which
> fixed the test and also a small bug.
Yeah, that was what happened. Thanks for clarifying.
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Mike Hommey @ 2009-11-27 8:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B0F92E7.8090403@viscovery.net>
On Fri, Nov 27, 2009 at 09:50:47AM +0100, Johannes Sixt wrote:
> Mike Hommey schrieb:
> > I don't know if the current Makefile works with Solaris' make,...
>
> No, it doesn't. You have to use GNU make anyway.
Then it's fine. But shouldn't that be noted somewhere, like in the
INSTALL file ?
Mike
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Johannes Sixt @ 2009-11-27 8:50 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20091127082624.GA19875@glandium.org>
Mike Hommey schrieb:
> I don't know if the current Makefile works with Solaris' make,...
No, it doesn't. You have to use GNU make anyway.
-- Hannes
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-27 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v3a40tl9t.fsf@alter.siamese.dyndns.org>
On Fri, Nov 27, 2009 at 09:38, Junio C Hamano <gitster@pobox.com> wrote:
> I was slightly surprised that this seems to have differences other than
> the flipping of the default color since the last one, especially after you
> sounded like you would be sending with only that change.
v3 does only that and adopt the change to the t/t4034-diff-words.sh
test. There I set an explicit value of func to magenta for testing.
Maybe you missed v2 (Message-Id:
<1258557087-31540-1-git-send-email-bert.wesarg@googlemail.com>)? Which
fixed the test and also a small bug.
Bert
>
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-27 8:38 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Jeff King, git
In-Reply-To: <1259304918-12600-1-git-send-email-bert.wesarg@googlemail.com>
I was slightly surprised that this seems to have differences other than
the flipping of the default color since the last one, especially after you
sounded like you would be sending with only that change.
^ 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