* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-09 1:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081742330.3718@g5.osdl.org>
On Mon, 2006-05-08 at 17:45 -0700, Linus Torvalds wrote:
> As long as the "commit <sha1>" id is there (and "--pretty=fuller" does
> have it), I'll be happy.
Ah, right. Those are _commit_ IDs in that strange first line. I'll
reformat those to 'Commit:' and 'Parent:' for the mailing list.
Having 'git-show --pretty=email' would be nice. I think Junio is working
on something which will achieve that, right?
> At some point, the commit mailing list didn't
> actually mention the commit ID itself, just the tree/parent IDs.
Yeah, I know -- and I got complaints :)
--
dwmw2
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejz4c8wm.fsf@assigned-by-dhcp.cox.net>
On 5/9/06, Junio C Hamano <junkio@cox.net> wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > What is --parents for ?
>
> In the part you did not quote, David wanetd a way to grab the
> parents of the commit in question, so I gave it to him.
Ok, sorry. I read too fast.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 0:57 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0605081753r1d9e7cb6u3a9b513bcbf2404a@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> What is --parents for ?
In the part you did not quote, David wanetd a way to grab the
parents of the commit in question, so I gave it to him.
> Is there a way to have a --pretty=fuller with date append to Author
> and Commiter name and email instead of have 1 lign after each ?
sed is your friend.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081715270.3718@g5.osdl.org>
On 5/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Ie you could probably more easily parse the data from something like
>
> git show -B --patch-with-stat --pretty=fuller $commit
>
Is there a way to track merge like that ? Documentation is not very
clear and near from empty.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 0:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes.Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605081731440.3718@g5.osdl.org>
On Mon, 8 May 2006 17:37:29 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> We could easily do
>
> [branch]
> name = "p4/BrAnCH"
> url = git://git.kernel.org/...
> pull = master
>
> ;
> ; Repeating the "[branch]" section here isn't
> ; needed, but doesn't hurt either, and is
> ; more readable
> ;
> [branch]
> name = "origin"
> url = ...
> pull = ...
>
> because the config file is always parsed linearly, and just
> trigger on "branch.name", and keep that around when parsing
> anything else.
That was pretty much what I was suggesting although i overlooked
the fact that you don't actually need to number the sections.
> The problem with _that_ is that "git repo-config" can't add this kind of
> setup sanely: it doesn't understand that kind of statefulness.
Shouldn't be too hard to deal with. So we would allow the following
command to make the url entry above:
$ git repo-config branch.p4/BrAnCH.url git://git.kernel.org/...
> The above would work without any changes what-so-ever to the config format
> and readers - and old versions of git wouldn't react badly either. But the
> writer would need to be taught about state.
Well it seems like maybe the best compromise, and it avoids having to put
files and directories into section names which Johannes was objecting to.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081731440.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 8 May 2006, sean wrote:
>>
>> One option, which I don't really like and comes with its own set of
>> problems, would be to do something like:
>>
>> [branch1]
>> streetname = "p4/BrAnCH"
>> [branch2]
>> streetname = "origin"
>
> You don't actually need that.
>
> We could easily do
>
> [branch]
> name = "p4/BrAnCH"
> url = git://git.kernel.org/...
> pull = master
>
> ;
> ; Repeating the "[branch]" section here isn't
> ; needed, but doesn't hurt either, and is
> ; more readable
> ;
> [branch]
> name = "origin"
> url = ...
> pull = ...
>
> because the config file is always parsed linearly, and just
> trigger on "branch.name", and keep that around when parsing
> anything else.
>
> The problem with _that_ is that "git repo-config" can't add this kind of
> setup sanely: it doesn't understand that kind of statefulness.
Wait a minute... Statefulness is not the issue, I think.
How would you tell your updated repo-config what to update and
what to look up?
- I want the url for branch whose name is "origin"
- I want to fetch their "for-linus" branch when fetching
from the branch whose name is "jgarzik" from now on.
In these query and update, you _are_ naming the branch with
name="xxx"; you just made "name" a special attribute.
Now, how would that compare with:
[branch.jgarzik]
url = git://git.kernel.org/...
fetch = for-linus
or
[branch."JGarzik"]
url = git://git.kernel.org/...
fetch = for-linus
I would say if we are grouping things together, if we can give
name to each group, _and_ if we are going to refer to the group
with its name, we are better off making the groups into distinct
sections _and_ make the syntax obvious that what name refers to
the section. I think [branch.jgarzik] syntax is more obvious
than your example where "name =" line is implicitly used as a
keyword to differenciate multiple occurrences of [branch]
sections.
Having said that, perhaps you have something more elaborate in mind,
e.g.
repo-config --get branch.url where name = 'origin'
repo-config --get branch.name where url like 'git://%'
repo-config branch.url 'git://git.kernel.org/...' where name = foo
;-) ;-) ;-) ??? If that is what you are after, then I agree
your syntax is more generic and suitable. But otherwise I fail
to see its point.
On a related topic, I have always been torn about the "for"
convention. While I think it was a cute hack, it would break
quite badly once we start doing anything complex.
[branch]
url = git://git.kernel.org/... for jgarzik
fetch = for-linus for jgarzik
proxy = none
url = git://git.kernel.org/... for torvalds
fetch = master for torvalds
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git
In-Reply-To: <7vu080c9uv.fsf@assigned-by-dhcp.cox.net>
On 5/9/06, Junio C Hamano <junkio@cox.net> wrote:
>
> If you are going to parse it anyway, this would probably be easier.
>
> $ git show --patch-with-stat --pretty=fuller --parents "$commit"
>
> Why would you want -B, by the way?
What is --parents for ?
Is there a way to have a --pretty=fuller with date append to Author
and Commiter name and email instead of have 1 lign after each ?
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 0:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147134522.2694.45.camel@shinybook.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
>
> Anyone got any objections to switching the kernel git-commits-* lists to
> this format?
As long as the "commit <sha1>" id is there (and "--pretty=fuller" does
have it), I'll be happy. At some point, the commit mailing list didn't
actually mention the commit ID itself, just the tree/parent IDs.
The "fuller" format should be fine, if you care about committer. Otherwise
just use the standard "--pretty", which drops committer info.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 0:37 UTC (permalink / raw)
To: sean; +Cc: Johannes Schindelin, git
In-Reply-To: <BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE>
On Mon, 8 May 2006, sean wrote:
>
> One option, which I don't really like and comes with its own set of
> problems, would be to do something like:
>
> [branch1]
> streetname = "p4/BrAnCH"
> [branch2]
> streetname = "origin"
You don't actually need that.
We could easily do
[branch]
name = "p4/BrAnCH"
url = git://git.kernel.org/...
pull = master
;
; Repeating the "[branch]" section here isn't
; needed, but doesn't hurt either, and is
; more readable
;
[branch]
name = "origin"
url = ...
pull = ...
because the config file is always parsed linearly, and just
trigger on "branch.name", and keep that around when parsing
anything else.
The problem with _that_ is that "git repo-config" can't add this kind of
setup sanely: it doesn't understand that kind of statefulness.
The above would work without any changes what-so-ever to the config format
and readers - and old versions of git wouldn't react badly either. But the
writer would need to be taught about state.
Linus
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 0:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1147134522.2694.45.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> ... I think I
> have to add the commit and the parent manually, but that's easy enough
> to do -- the commit is obviously known, and the parent is just
> $(git-rev-parse $commit^1).
If you are going to parse it anyway, this would probably be easier.
$ git show --patch-with-stat --pretty=fuller --parents "$commit"
Why would you want -B, by the way?
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-09 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081715270.3718@g5.osdl.org>
On Mon, 2006-05-08 at 17:19 -0700, Linus Torvalds wrote:
> Well, you might choose to just not use "git-cat-file commit" but instead
> ask git to format the thing for you.
>
> Ie you could probably more easily parse the data from something like
>
> git show -B --patch-with-stat --pretty=fuller $commit
>
> instead of using "git-cat-file commit $commit" and generating the stat and
> diff manually.
>
> That way you get the dates etc pretty-printed for you by git.
Aha, thanks. Git has learned to do a lot more since I first started
hacking up a copy of git-log.sh to feed the mailing lists, and it even
had to walk the commit tree manually :)
The output of (the undocumented) '--pretty=fuller' is probably good
enough that I can just feed the mailing list with it directly. I think I
have to add the commit and the parent manually, but that's easy enough
to do -- the commit is obviously known, and the parent is just
$(git-rev-parse $commit^1).
Anyone got any objections to switching the kernel git-commits-* lists to
this format?
--
dwmw2
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-09 0:23 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE>
Hi,
On Mon, 8 May 2006, sean wrote:
> [branch1]
> streetname = "p4/BrAnCH"
> [branch2]
> streetname = "origin"
Conceptually, it feels just wrong to me that a section name should contain
a filename. A section is something which contains data regarding a certain
concept. Such as "core", which has values concerning the core of git.
In that sense, I stay with my preferance:
[branch]
defaultRemote = bla for bloop
defaultRemote = connery for sean
No need to extend the simple config file. And remember, it is so simple,
because it is so strict.
Ciao,
Dscho
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 0:19 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147131877.2694.37.camel@shinybook.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
>
> The remaining problem is that the invocation of 'date' doesn't work with
> new versions of coreutils. This...
>
> date=(${rest#*> })
> sec=${date[0]}; tz=${date[1]}
> dtz=${tz/+/+ }; dtz=${dtz/-/- }
> pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
>
> ... doesn't work any more on FC-5, because:
Well, you might choose to just not use "git-cat-file commit" but instead
ask git to format the thing for you.
Ie you could probably more easily parse the data from something like
git show -B --patch-with-stat --pretty=fuller $commit
instead of using "git-cat-file commit $commit" and generating the stat and
diff manually.
That way you get the dates etc pretty-printed for you by git.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605090142280.5778@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 9 May 2006 01:44:31 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 8 May 2006, sean wrote:
>
> > There's no good reason for git to break with traditional and common
> > practice in this case.
>
> It is well established common practice that ini files (and everything in
> config resembles an ini file) have case insensitive section headers as
> well as keys.
Not in ini files that support section headers that represent filenames
and directories. Exactly because those things _are_ case sensitive
and include more characters than just alnums. But we're not just
talking about the config file syntax we're talking about how the
user must ultimately refer to branches with uppercase character.
Now everytime a person wants to add a branch attribute via repo-config
they have to remember that git thinks uppercase characters should
be quoted. Doesn't that sound ridiculous to you?
The point is that we should make the config file and the repo-config
command easy for the _users_. Instead we're going to make them use
some crazy extra syntax because we refuse to come to terms with the
limitations of the choices we've made so far.
One option, which I don't really like and comes with its own set of
problems, would be to do something like:
[branch1]
streetname = "p4/BrAnCH"
[branch2]
streetname = "origin"
And then allow reference to it from git-repo-config by either branch#
or the value of street name. While it would take some extra coding
but at least it lives within the current restrictions for key names.
It just seems that once you have to even consider options like this,
a big red flag should be raised about some of the assumptions we've
built into the system.
Sean
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-08 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzdy9zl2.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Wed, 2006-05-03 at 21:35 -0700, Junio C Hamano wrote:
> If you were to do bashism local, don't you want to also localize
> other variables like key, SUBHEX, NEWSUB,...?
>
> It may make sense to enhance format-patch to do the Q encoding,
> so that you do not have to do this part by hand...
Yes, that would be useful. We should perhaps to the From: and To:
headers too. Here's my current version (thanks for the feedback)...
The remaining problem is that the invocation of 'date' doesn't work with
new versions of coreutils. This...
date=(${rest#*> })
sec=${date[0]}; tz=${date[1]}
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
... doesn't work any more on FC-5, because:
$ date -Rud '1970-01-01 UTC + 1147104611 sec + 0100'
date: invalid date `1970-01-01 UTC + 1147104611 sec + 0100'
--
dwmw2
[-- Attachment #2: git-feed-mail-list.sh --]
[-- Type: application/x-shellscript, Size: 3600 bytes --]
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 23:44 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0453E2D70B10C6D116167EAEA80@CEZ.ICE>
Hi,
On Mon, 8 May 2006, sean wrote:
> There's no good reason for git to break with traditional and common
> practice in this case.
It is well established common practice that ini files (and everything in
config resembles an ini file) have case insensitive section headers as
well as keys.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 23:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081905240.6713@iabervon.org>
Hi,
On Mon, 8 May 2006, Daniel Barkalow wrote:
> You could tell people always to use:
>
> [branch."name"]
I find this utterly ugly.
> I don't think that people are likely to use older versions of git on the
> same repository they've used newer versions on. (Clones of it, sure, but
> that doesn't matter here.) But we should, in any case, make the code
> ignore sections or lines with syntax errors, under the assumption that
> they're a later extension and possibly legal but not anything the code
> could be interested in getting from a parser that doesn't support them.
I have to bisect git sometimes, just because I have some local changes.
Older gits do barf with a fatal error when encountering a bad config.
Further, it is probably not a good idea to relax error-checking. It is too
easy to overlook.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 23:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605081905240.6713@iabervon.org>
On Mon, 8 May 2006 19:20:17 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
> You could tell people always to use:
>
> [branch."name"]
>
> even if the branch name is all lowercase anyway. They could even use:
>
> [Branch."MyMixedCaseBranch"]
>
> Then when you refer to something case-sensitive with the possibility of
> funny characters, you put it in quotes, regardless of what it is.
>
> For that matter, we could retain the quotes when we parse the file, and
> reject [branch.master] for lacking the quotes, so that people who are only
> exposed to branch names all in lowercase letters don't get habits that
> will fail when they have a v2.6.16.x branch.
>
> I don't think that people are likely to use older versions of git on the
> same repository they've used newer versions on. (Clones of it, sure, but
> that doesn't matter here.) But we should, in any case, make the code
> ignore sections or lines with syntax errors, under the assumption that
> they're a later extension and possibly legal but not anything the code
> could be interested in getting from a parser that doesn't support them.
Unfortunately that's not the only place where you have to use the
excessive quoting; you also have to do the same when using the git
repo-config command line. All because we're clinging to case
insensitivity and a very restrictive set of characters for
identifiers in the config file. And just why are we clinging?
Believe when Linus offered the code originally he said that it was
easier to start out very restrictive and loosen up later than it was
to start loose and become restrictive later. That makes a lot of
sense, but somewhere along the way we seem to have made a virtue
out of something that is actually getting in the way of natural
syntactic usage. There's no good reason for git to break with
traditional and common practice in this case.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Daniel Barkalow @ 2006-05-08 23:20 UTC (permalink / raw)
To: sean; +Cc: Junio C Hamano, git
In-Reply-To: <BAYC1-PASMTP110777A694DAF1D7623895AEA80@CEZ.ICE>
On Sun, 7 May 2006, sean wrote:
> On Sun, 07 May 2006 19:29:50 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>
> > Not at all. Whatever Porcelain that runs repo-config to record
> > the branch name needs to spell that branch name with proper
> > quoting, like:
>
> Okay. It just seems nuts to require quoting because you happen
> to use an uppercase character. People are used to quoting
> special characters like * and $, not uppercase letters.
You could tell people always to use:
[branch."name"]
even if the branch name is all lowercase anyway. They could even use:
[Branch."MyMixedCaseBranch"]
Then when you refer to something case-sensitive with the possibility of
funny characters, you put it in quotes, regardless of what it is.
For that matter, we could retain the quotes when we parse the file, and
reject [branch.master] for lacking the quotes, so that people who are only
exposed to branch names all in lowercase letters don't get habits that
will fail when they have a v2.6.16.x branch.
I don't think that people are likely to use older versions of git on the
same repository they've used newer versions on. (Clones of it, sure, but
that doesn't matter here.) But we should, in any case, make the code
ignore sections or lines with syntax errors, under the assumption that
they're a later extension and possibly legal but not anything the code
could be interested in getting from a parser that doesn't support them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH/RFC] Teach git-clean optional <paths>... parameters.
From: Pavel Roskin @ 2006-05-08 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wv4gx0r.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-05-08 at 12:02 -0700, Junio C Hamano wrote:
> When optional paths arguments are given, git-clean passes them
> to underlying git-ls-files; with this, you can say:
>
> git clean 'temp-*'
>
> to clean only the garbage files whose names begin with 'temp-'.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
> * I usually do not use clean myself, so I am not sure if this
> is the kind of thing people who do use 'clean' regularly
> would generally want, hence this RFC.
I'm not likely to use this feature, but I think it's OK to have it.
It would be nice to have "--" support (see e.g. git-commit).
> + -X remove only ignored files as well
That's my stupid error, "as well" should be removed.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: (patch) calloc->xcalloc in read-cache.c
From: Junio C Hamano @ 2006-05-08 20:54 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0605081101w3dc3a60cof5a524e9b4a3f555@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> --- read-cache.c.000 2006-05-08 15:13:57.000000000 +0000
> +++ read-cache.c 2006-05-08 15:15:35.000000000 +0000
> @@ -557,7 +557,7 @@
>
> active_nr = ntohl(hdr->hdr_entries);
> active_alloc = alloc_nr(active_nr);
> - active_cache = calloc(active_alloc, sizeof(struct cache_entry *));
> + active_cache = xcalloc(active_alloc, sizeof(struct cache_entry *));
>
> offset = sizeof(*hdr);
> for (i = 0; i < active_nr; i++) {
>
> Yakov
While I do not mind hand generated patch, your mailer setting
seems to be seriously broken.
Mind checking Documentation/SubmittingPatches and try again?
^ permalink raw reply
* Re: [patch] munmap-before-rename, cygwin need
From: Junio C Hamano @ 2006-05-08 20:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Yakov Lerner, Junio C Hamano, git
In-Reply-To: <81b0412b0605080635r40868f18ua88b33558368f82b@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> You really want "NO_MMAP = YesPlease" in your config.mak.
> Take a look into compat/mmap.c. That's why Junio has never seen
> the breakage.
I do not have custom config.mak for my Cygwin builds and NO_MMAP
is disabled in the default Makefile, so that does not explain
why it does not break for me. Very puzzled.
^ permalink raw reply
* Re: [patch] munmap-before-rename, cygwin need
From: Junio C Hamano @ 2006-05-08 20:51 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Junio C Hamano, git
In-Reply-To: <f36b08ee0605080747r24668152t20cc406e017454a9@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> You are right. Apply did not work when I gave it more than one
> patchfile on commandline (and --index option). I fixed this by
> zeroing active_nr and freeing active_cache in
> unmap_cache().
I suspect that essentially means you are forcing the cache to be
read again after writing it out, in which case I think you are
better off using NO_MMAP as Alex suggests.
^ permalink raw reply
* Re: Command to list commits that point to a given tree.
From: Junio C Hamano @ 2006-05-08 20:34 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20060508163437.GA17390@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> ... In particular, I am
> looking for a command that will return a list of commits that point to a
> particular tree.
>
> Right now I plan to brute force it.
You might want to explain what problem you are trying to solve,
by knowing which commit contains a particular tree object.
There might be a solution to that unstated problem which does
not require the reverse lookup.
^ permalink raw reply
* [PATCH/RFC] Teach git-clean optional <paths>... parameters.
From: Junio C Hamano @ 2006-05-08 19:02 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
When optional paths arguments are given, git-clean passes them
to underlying git-ls-files; with this, you can say:
git clean 'temp-*'
to clean only the garbage files whose names begin with 'temp-'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I usually do not use clean myself, so I am not sure if this
is the kind of thing people who do use 'clean' regularly
would generally want, hence this RFC.
Documentation/git-clean.txt | 5 ++++-
git-clean.sh | 13 +++++++++----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 36890c5..b95545f 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from
SYNOPSIS
--------
[verse]
-'git-clean' [-d] [-n] [-q] [-x | -X]
+'git-clean' [-d] [-n] [-q] [-x | -X] <paths>...
DESCRIPTION
-----------
@@ -16,6 +16,9 @@ Removes files unknown to git. This allo
from files that are not under version control. If the '-x' option is
specified, ignored files are also removed, allowing to remove all
build products.
+When optional `<paths>...` arguments are given, the paths
+affected are further limited to those that match them.
+
OPTIONS
-------
diff --git a/git-clean.sh b/git-clean.sh
index b200868..6c818f4 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -3,13 +3,15 @@ #
# Copyright (c) 2005-2006 Pavel Roskin
#
-USAGE="[-d] [-n] [-q] [-x | -X]"
+USAGE="[-d] [-n] [-q] [-x | -X] <paths>..."
LONG_USAGE='Clean untracked files from the working directory
-d remove directories as well
-n don'\''t remove anything, just show what would be done
-q be quiet, only report errors
-x remove ignored files as well
- -X remove only ignored files as well'
+ -X remove only ignored files as well
+When optional <paths>... arguments are given, the paths
+affected are further limited to those that match them.'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -44,8 +46,11 @@ do
-X)
ignoredonly=1
;;
- *)
+ -*)
usage
+ ;;
+ *)
+ break
esac
shift
done
@@ -64,7 +69,7 @@ if [ -z "$ignored" ]; then
fi
fi
-git-ls-files --others --directory $excl ${excl_info:+"$excl_info"} |
+git-ls-files --others --directory $excl ${excl_info:+"$excl_info"} "$@" |
while read -r file; do
if [ -d "$file" -a ! -L "$file" ]; then
if [ -z "$cleandir" ]; then
--
1.3.2.gb012
^ 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