* Working copy as a pseudo-head
From: Steven Grimm @ 2006-11-27 8:19 UTC (permalink / raw)
To: git
I was trying to explain to someone today why "git pull" fails if you
have working-copy edits of one of the files that changed in the other
branch, and it occurred to me that there may be a way to model the world
so it doesn't fail. I am still relatively new to git so I hope this is
not a totally idiotic idea.
Right now there is a hard distinction between what's in the working copy
and the revision history of the tree. Merge is an operation on the
revision history, and the working copy doesn't enter into it aside from
the sanity check in git-merge to prevent you from inadvertently
overwriting local edits.
What if instead, we had a notion of a temporary commit, call it WORK,
that is ahead of what we currently think of as HEAD? That is, where now
we have
A----B----C----D(HEAD)
we instead allowed
A----B----C----D(HEAD)----E(WORK)
When you do some operation that currently would complain about
working-copy edits, it instead commits a WORK revision but does not
adjust HEAD. Then it performs the operation against HEAD (advancing HEAD
as needed) and rebases WORK under the newly merged HEAD, updating the
working copy as a normal rebase would. Then, with one exception I'll get
to below, it removes the WORK revision from the version history but
leaves the contents of the working copy alone.
For example, say you have a pristine working copy of a branch with some
history:
A----B----C(HEAD)
and you make some edits to the working copy. Now you want to pull down
the latest changes from upstream, revision "X". So the system silently
commits your work in progress to a temporary revision, which (while the
merge is running) changes your history to:
A----B----C(HEAD)----D(WORK)
Then it merges the new changes with HEAD to form a new "Y" revision:
/--D(WORK)
/
A----B----C----Y(HEAD)
\ /
\-------X--/
Then it rebases WORK:
A----B----C----Y(HEAD)----D(WORK)
\ /
\-------X--/
And finally it removes WORK from the version history.
A----B----C----Y(HEAD) + working-copy edits
\ /
\-------X--/
I believe something like the above is currently how Cogito does its
"update from the origin without losing working copy edits" thing, though
it has to stash the working-copy edits in a temporary branch. Having the
underlying functionality supported in the core git tools would be far
preferable to having to hack around the lack of it in a frontend.
The one exception to the above flow is when you want to switch branches.
Here, we create a WORK temporary commit on the current branch and move
over to the new branch as normal, blowing away the WORK commit on the
*new* branch, if any, and leaving its edits in the working copy. That
allows you to freely switch back and forth between branches without
worrying about whether you need to save your changes in progress, and
without cluttering your repository with intermediate copies of files
you're editing.
This is a behavior change! But I think the proposed behavior makes more
sense. It treats the working copy as an extension of whatever branch
you're on, rather than a separate entity that can flit back and forth
between branches if there aren't conflicts or prevent you from changing
branches at all if there are. It has always seemed confusing and
inconsistent to me that, in some sense, doing a commit makes my changes
LESS sticky -- that is,
echo foo >> testfile
git checkout other-branch
tail -1 testfile
says "foo", but
echo foo >> testfile
git commit -a
git checkout other-branch
tail -1 testfile
doesn't. I know (or I think I do) why it's doing that, but from a user
experience point of view it's just weird, because it makes it look like
"commit" reduces the importance of my change. And it also makes it a lot
less convenient to pop over to another branch for a moment to check out
the old version of some code I'm in the middle of rewriting.
Also, I realize I can use StGIT to get something like the above. But
again, I think it'd be cleaner to support this in the underlying tool;
"pull down some updates while I'm still working" is a very common usage
model that's handled fine by other SCMs (Subversion, etc.) and right now
with Git it requires a bunch of awkward extra commands. And preserving
working-copy edits when switching branches seems like a huge convenience
win to me; I have a hard time imagining how the current behavior is a
time-saver for anyone (though I'm sure I'll hear all about it now!)
Comments? Is this just nuts?
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Jakub Narebski @ 2006-11-27 7:49 UTC (permalink / raw)
To: git
In-Reply-To: <20061127065400.GA19174@spearce.org>
Shawn Pearce wrote:
> Sean <seanlkml@sympatico.ca> wrote:
>> On Sun, 26 Nov 2006 15:27:07 +0100 (CET)
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>>> But there really is no good place to put it: most commands need a git
>>> repository, and those which do not, are inappropriate to put an option
>>> "--show-ps1" into. Except maybe repo-config. Thoughts?
>>
>> What about just making it an option to the git wrapper?
>
> I'm using something like this, and will be adding it to
> git-completion.bash tonight:
>
> __git_ps1 ()
> {
> local b="$(git symbolic-ref HEAD 2>/dev/null)"
> if [ -n "$b" ]; then echo "(${b##refs/heads/})"; fi
> }
> PS1='[\u@\h \W$(__git_ps1)]\$ '
>
> it works very well...
Perhaps, as it was proposed somewhere else in this thread, instead of
\u@\h use $(git repo-config --get user.email)?
And I would add \!: at the beginning of prompt, but that might be
just me.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Junio C Hamano @ 2006-11-27 7:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, catalin.marinas, Git Mailing List
In-Reply-To: <e5bfff550611262238q60d466a3r230c9c4af283b76b@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Could a possible '--all-branches' new option come to rescue?
I doubt it. Next thing people would start talking about is what
to do with the remote tracking branches, and what we are talking
about is rev-list, one of the lower level of plumbing that would
be better left without knowing much about the Porcelain's use of
refs/ namespaces.
If you (as a Porcelain) want to get all refs under refs/heads/,
there are (unfortunately) two ways to get that list. I would
suggest obtain the refs you want that way, pass them as command
line arguments to rev-list.
$ git for-each-ref --format='%(refname)' refs/heads
$ git show-ref --heads | sed -e 's/^[^ ]* //'
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Shawn Pearce @ 2006-11-27 6:54 UTC (permalink / raw)
To: Sean; +Cc: Johannes Schindelin, git, Theodore Tso
In-Reply-To: <20061126094212.fde8cce7.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Sun, 26 Nov 2006 15:27:07 +0100 (CET)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > But there really is no good place to put it: most commands need a git
> > repository, and those which do not, are inappropriate to put an option
> > "--show-ps1" into. Except maybe repo-config. Thoughts?
>
> What about just making it an option to the git wrapper?
I'm using something like this, and will be adding it to
git-completion.bash tonight:
__git_ps1 ()
{
local b="$(git symbolic-ref HEAD 2>/dev/null)"
if [ -n "$b" ]; then echo "(${b##refs/heads/})"; fi
}
PS1='[\u@\h \W$(__git_ps1)]\$ '
it works very well...
--
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-27 6:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611261836250.30076@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think that's actually likely the exception rather than the rule. It's
> much more likely that people have almost _all_ active development done on
> side branches, and that - together with rebasing of the side branches -
> inevitably means that the "main branch" ends up not having such a clean
> set of "topic branch" merges.
You are absolutely right about "Andrew patchbomb" which is
linear and does not have the series boundary. Import from
mostly linear foreign SCM would have the same issue. Merge
topology would not help us at all in these cases.
> In addition, on a more mature tree, a lot (probably _most_) of the commits
> aren't really "topics" at all, but "maintenance", which exacerbates the
> problem: you don't have a "line of development of this feature",
> ...
> Put another way: bugs get fixed one by one, not in a nice linear fashion
> by "topic".
Again, you are right, but that only means topic based grouping
is not for everybody, and certainly is not suitable for a long
stretch of commits on the trunk of a mature project because they
tend to touch everywhere and not all that clustered. If those
bugs were fixed by committing on separate topic branches and
then later merged, the topology based clustering would get the
grouping right, but I would imagine we would end up seeing
hundreds of such short groups which would not be useful at all.
In such cases, it would be much more useful to have one huge
group that says "these are small fixes, each of which may touch
different areas -- they are not related but grouped together
because they are all small, obviously correct and harmless
fixes". So I suspect that is a slightly different issue -- it
just illustrates the need for an "ungrouped" bin.
> So I'm coming at it from a totally different project - where "topic
> branches" simply aren't delineated as much, and even when they are, they
> tend to be merged in multiple steps (and they pull both ways when they
> aren't re-based).
I agree multiple steps merge and merging both ways would happen
in real life, but I had an impression that fpc handles that
topology reasonably well, unless that "merge from upstream" are
of "too frequent, automated and useless" kind of merges.
> ... but in the kernel, I pretty much guarantee
> that you probably get better "topic clustering" by going simply by author,
> like the old standard "git shortlog" does. Because that will tend to get
> the clustering at a finer granularity (ie not just "networking", but
> things like "packet filtering" etc).
>
> So the "sort by people" actually works fairly well, but it's kind of an
> "incidental" thing, and it _would_ be potentially useful to have other
> ways of grouping things.
I think "networking" vs "packet filtering" largely depends on
how the networking subsystem you pull from is managed. If
netfilter comes as e-mailed patches to DaveM and are applied
onto the trunk of networking subsystem, we will face exactly the
same problem as we have with Andrew's patchbomb to your trunk.
If it were managed on a separate topic branch in the networking
subsystem repository (either DaveM manages them in his
repository as a topic, or DaveM pulls from netfilter git
repository -- I do not know how that part of the patchflow
works), I would imagine you would get the same "per topic"
grouping.
Another factor is that the author population of a wide and
mature project like the kernel tends to be more diverse, and a
single person tends to be focused on one thing at a time while
others work on different things. There is enough work in one
specific area for one person to do, and the project is too wide
for one person to be everywhere.
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Marco Costalba @ 2006-11-27 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: catalin.marinas, Git Mailing List
In-Reply-To: <e5bfff550611262231s3eac2d11ke9fcdb0d699093f0@mail.gmail.com>
On 11/27/06, Marco Costalba <mcostalba@gmail.com> wrote:
> >
> > You are looking at .git/refs/bases/ refs that StGIT uses for its
> > internal bookkeeping.
> >
> Ok.
>
> Anyway, getting garbage when asking for a git-rev-list --all if in a
> StGit repo at least could be considered a little integration issue.
>
> Internal bookkeeing should be, well, _internal_ :-)
>
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Marco Costalba @ 2006-11-27 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: catalin.marinas, Git Mailing List
In-Reply-To: <7v7ixit13h.fsf@assigned-by-dhcp.cox.net>
>
> You are looking at .git/refs/bases/ refs that StGIT uses for its
> internal bookkeeping.
>
Ok.
Anyway, getting garbage when asking for a git-rev-list --all if in a
StGit repo at least could be considered a little integration issue.
Internal bookkeeing should be, well, _internal_ :-)
^ permalink raw reply
* Re: [PATCH] Make logAllRefUpdates true by default
From: Shawn Pearce @ 2006-11-27 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anand Kumria, git
In-Reply-To: <7vhcwmt19w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I do not think I can take this patch in its current form.
>
> Although I think majority of users would find it convenient to
> have ref-log enabled by default on repositories to be developed
> in, it does not make sense to enable ref-log by default for bare
> repositories that is used as a distribution point. So at least
> this needs an option to disable it (if you make it the default),
> or enable it.
What about just suggesting that the individual user run:
git repo-config --global core.logAllRefUpdates true
?
This has the effect of enabling reflog by default for any repository
that the user creates or clones, unless its explicitly disabled in
that repository.
I've done this in any account that I use to access working directory
repositories and it works well. But I also just realized that I have
it enabled in one account which also pushes to some bare repositories
through local filesystem URLs and thus those bare repositories are
also getting reflogged. But given that they are used as backups of
my working directory repositories (different drive) and are never
pruned, I actually consider that to be a feature. :-)
Your idea of guessing the intent of the repository and setting up the
configuration based on that intent is a good one, but unfortunately I
have no suggestions for how to solve the (1)..(3) cases you raised.
But setting core.logAllRefUpdates in the global configuration of
an interactive account appears to be a reasonable workaround.
--
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Linus Torvalds @ 2006-11-27 2:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac2dr6ua.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Nov 2006, Junio C Hamano wrote:
>
> I think I should have used the word "topic branch" instead of
> "topic". In other words, I was not interested in sifting the
> various totally unrelated linear commits into groups that deal
> with distinct problems.
Well, I think you're grown slightly jaded by the fact that git has very
active "normal" development, that is actually done by you on the main
branch, and you do basically zero rebasing along the side branches.
I think that's actually likely the exception rather than the rule. It's
much more likely that people have almost _all_ active development done on
side branches, and that - together with rebasing of the side branches -
inevitably means that the "main branch" ends up not having such a clean
set of "topic branch" merges.
In addition, on a more mature tree, a lot (probably _most_) of the commits
aren't really "topics" at all, but "maintenance", which exacerbates the
problem: you don't have a "line of development of this feature", you tend
to have much more of a random "fix this general area", where the only
common theme may be the fact that things are _related_ to some common
subsystem, but not that they are a "topic branch" in the _development_
sense.
Put another way: bugs get fixed one by one, not in a nice linear fashion
by "topic".
So I'm coming at it from a totally different project - where "topic
branches" simply aren't delineated as much, and even when they are, they
tend to be merged in multiple steps (and they pull both ways when they
aren't re-based).
So that's why I don't think the pure branch topology is as interesting. A
single line of development ends up being useful for you, and we'll
certainly see _some_ of that, but in the kernel, I pretty much guarantee
that you probably get better "topic clustering" by going simply by author,
like the old standard "git shortlog" does. Because that will tend to get
the clustering at a finer granularity (ie not just "networking", but
things like "packet filtering" etc).
So the "sort by people" actually works fairly well, but it's kind of an
"incidental" thing, and it _would_ be potentially useful to have other
ways of grouping things.
See? It's not about "superior intelligence", it's about simply a totally
different development phase (and a less strictly defined problem space).
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-27 1:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611261652520.30076@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 26 Nov 2006, Junio C Hamano wrote:
>>
>> This implements an experimental "git log-fpc" command that shows
>> short-log style output sorted by topics.
>>
>> A "topic" is identified by going through the first-parent
>> chains; this ignores the fast-forward case, but for a top-level
>> integrator it often is good enough.
After sending out a response, I re-read your message because I
did not quite get where bayesian would come into the picture.
I think I should have used the word "topic branch" instead of
"topic". In other words, I was not interested in sifting the
various totally unrelated linear commits into groups that deal
with distinct problems.
But again you are showing your superiour intelligence by setting
the problem in a much grander scheme ;-), where there is no such
developer discipline that would help the shortlogger (like use
of topic branches). In such a case, you would need a set of
heuristics that you described.
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Linus Torvalds @ 2006-11-27 1:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejrpr7mw.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Nov 2006, Junio C Hamano wrote:
>
> - a two-commit series on MIPS via Ralf Baechle,
> - a four-commit series on ARM via Russel King,
> - a three-commit series on POWERPC via Paul Mackerras,
> - a seventeen-commit series in net/ area via Dave Miller,
> - a three-commit series on x86_64 via Andi Kleen.
You'll reasonably often see in the kernel:
- a patch-series by Andrew (where nothing but filename clustering really
would help: the committer is me, and the thing is linear)
- linearly on top of that, a git merge that was a fast-forward
(especially from the subset of people who actively rebase their trees:
that notably includes Dave Miller, but also for example the DVB people)
so purely a first-parent logic would not catch that case at all (but the
committer would at least catch the "patch-series by Andrew" -> "Merge of
network tree by Davem" break).
But especially with long patch-series through Andrew, it would be nice to
have some other heuristics (although they _tend_ to be fairly random,
especially at the end of the release cycle - at the beginning, I tend to
have series of 100-200 patches that often _could_ be clearly clustered
into a few clusters).
Anyway, the real win of clusterign would likely be for big releases, ie
soemthing like "v2.6.18..v2.6.19-rc1", where there's definitely some
clustering even apart from just merging (although the merge topology will
definitely get some of it)
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-27 1:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611261652520.30076@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 26 Nov 2006, Junio C Hamano wrote:
>>
>> This implements an experimental "git log-fpc" command that shows
>> short-log style output sorted by topics.
>>
>> A "topic" is identified by going through the first-parent
>> chains; this ignores the fast-forward case, but for a top-level
>> integrator it often is good enough.
>
> Umm. May I suggest that you try this with the kernel repo too..
Have you?
I've compared
gitk HEAD~40..HEAD
and
git-log-fpc --no-merges HEAD~40..HEAD
Admittedly, the first group ("from the tip of the master") tends
to be seriously mixed up without a fixed theme (well the theme
appears to be "fix trivial warnings and compilation breakages
not limited to any particular subsystem"), but I find the other
groups quite a sane representation of what actually happened.
My copy of your tree is a bit old (HEAD is at 1abbfb412), but I
see:
- a two-commit series on MIPS via Ralf Baechle,
- a four-commit series on ARM via Russel King,
- a three-commit series on POWERPC via Paul Mackerras,
- a seventeen-commit series in net/ area via Dave Miller,
- a three-commit series on x86_64 via Andi Kleen.
...
As you said, committer would be a good addition to break a
fast-forward case to make it even better.
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-27 1:21 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611270159.14925.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> I am not so sure about this. IMHO, any user expects to see "pu" branch
> cloned too after cloning git.git (at least me, and a newbie probably too).
I think you are right that we can keep our sanity without
omitting rewinding ones from the tracked set of branches. In
fact, remotes/origin/* hierarchy are not to be checked out
directly anyway, even after we do the "bare SHA-1 stored in
$GIT_DIR/HEAD" update -- that should give you a read-only
checkout that you cannot commit on top of. As long as we warn
users who try to merge from these rewinding branches, there is
no reason not to track them.
> As said, the real problem begins when the user tries to branch off her
> own local branch from "pu". At this point, "git branch" or
> "git checkout -b ..." should warn the user that he has to expect troubles
> when branching off from such a branch, and only allow it with a
> "--force" option.
That is true if you make "git branch my-pu remotes/origin/pu" to
somehow set up the default merge source of "my-pu" branch to be
remotes/origin/pu to encourage merging from it.
I am still not convinced it is a valid assumption that a branch
often want to merge from the branch it was forked off of, and
even less so that "git branch" and "git checkout -b" are the
places to do that configuration.
But for the sake of discussion let's pretend for now that it
were a good idea. If we know remotes/origin/pu is expected to
be rewound, the logic that configures "my-pu" to merge from the
fork origin should be able to notice that situation, and refrain
from doing the configuration, to prevent the user from issuing
"git pull" without saying "from where", which can be done with
your merge.stopsansdefault option in your other message.
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Linus Torvalds @ 2006-11-27 1:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v8xhxsopp.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Nov 2006, Junio C Hamano wrote:
>
> This implements an experimental "git log-fpc" command that shows
> short-log style output sorted by topics.
>
> A "topic" is identified by going through the first-parent
> chains; this ignores the fast-forward case, but for a top-level
> integrator it often is good enough.
Umm. May I suggest that you try this with the kernel repo too..
There, the "first parent chain" tends to be less interesting than a lot of
other heuristics:
- committer
If the committer changes, you should probably consider it a break, the
same way a second parent would be a break. You probably won't see this
in the git archive, because there tends to be a single committer, but
on something like the kernel where we really merge other peoples repos,
it's going to be as good (or better) than looking at "other parents".
- subdirectory heuristics
Again, with git it's not very interesting, but I bet that you'd be able
to use heuristics like "the bulk of the changes were contained within
this directory tree" for projects like the kernel, and automatically
decide on "topics" like drivers/scsi, fs/ext3 etc.
In other words, I don't think the "fpc" decision is even very interesting.
If you _really_ want to do a cool shortlogger, I bet it can be done, but I
suspect that it would be a LOT cooler to do some automatic bayesian
clustering based on committer, author and list of filenames changed.
Of course, such a thing done well would probably be worthy of a doctoral
thesis or something. Maybe somebody on this list who is into bayesian
clustering and doesn't have a thesis subject...
(Of course, since I haven't been in a University setting for the last ten
years, maybe bayesian clustering isn't the cool thing to work on any
more).
Anyway, "topics" really should be something that is extremely open to
various clustering models, bayesian or not ..
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Josef Weidendorfer @ 2006-11-27 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vvel2yi2u.fsf@assigned-by-dhcp.cox.net>
On Sunday 26 November 2006 04:58, Junio C Hamano wrote:
> > git-clone should skip rewinding branches by default, unless the user
> > adds an option (e.g. --include-rewinding-branches). This way new
> > users to git.git don't get the `pu` branch unless they really mean
> > to get it, at which point they have hopefully also read the upstream's
> > description of the `pu` branch and its rewinding policy, and can
> > at least start to grasp what is going to happen if they start to
> > work with the branch.
>
> I like this approach very much.
I am not so sure about this. IMHO, any user expects to see "pu" branch
cloned too after cloning git.git (at least me, and a newbie probably too).
I agree about the remote branch description saying that "pu" branch will
be rewinded. git-clone should set "+" before such a branch.
As said, the real problem begins when the user tries to branch off her
own local branch from "pu". At this point, "git branch" or
"git checkout -b ..." should warn the user that he has to expect troubles
when branching off from such a branch, and only allow it with a
"--force" option.
^ permalink raw reply
* [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-27 0:44 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
This implements an experimental "git log-fpc" command that shows
short-log style output sorted by topics.
A "topic" is identified by going through the first-parent
chains; this ignores the fast-forward case, but for a top-level
integrator it often is good enough.
For example, if the commit ancestry graph looks like this:
x---x---x---X---o---*---o---o---o HEAD
\ /
o---o---o---o---o
and the command line asks for
git log-fpc --no-merges X..
It first finds all the commits 'o'. Then it emits the four
commits on the upper line (assume the merge '*' has the commit
that is a child of X as its first parent in the picture). When
it does so, it the list of authors for these four commits on one
line, followed by the title of these commits. After that, it
does the same for the five commits on the lower line.
---
I initially wanted to do this inside Johannes's enhanced
shortlog, but ended up doing this as a pretty much independent
thing, because the shortlog implementation stringifies the
information from the commits too early to be easily enhanced for
this purpose.
If this turns out to be a better way to present shortlog,
however, this should become an option to git-shortlog.
A sample output from:
git log-fpc --no-merges v1.4.4.1..f64d7fd2
looks like this (f64d7fd2 was the tip of master when the last
"What's in" message was sent out). It shows that many "fixes"
and git-svn enhancements were directly done on "master" (that is
the first group), while many gitweb enhancements, changing the
output from "prune -n", "git branch" enhancements, etc. were
first cooked in separate topic branches and then later merged
into 'master'.
To this output, I can manually add a topic title to the
beginning of each group and it would make a better overview than
what I currently send out in "What's in" message which is
generated with shortlog.
----------------------------------------------------------------
Eric Wong (6), Junio C Hamano (5), Lars Hjemli, Jakub Narebski,
Iñaki Arenaza, Petr Baudis, Andy Parkins, and René Scharfe
git-fetch: exit with non-zero status when fast-forward check fails
git-svn: exit with status 1 for test failures
git-svn: correctly access repos when only given partial read permissions
git-branch -D: make it work even when on a yet-to-be-born branch
Add -v and --abbrev options to git-branch
git-clone: stop dumb protocol from copying refs outside heads/ and tags/.
gitweb: (style) use chomp without parentheses consistently.
gitweb: Replace SPC with also in tag comment
git-svn: handle authentication without relying on cached tokens on disk
git-cvsimport: add support for CVS pserver method HTTP/1.x proxying
Make git-clone --use-separate-remote the default
refs outside refs/{heads,tags} match less strongly.
Increase length of function name buffer
git-svn: preserve uncommitted changes after dcommit
git-svn: correctly handle revision 0 in SVN repositories
git-svn: error out from dcommit on a parent-less commit
archive-zip: don't use sizeof(struct ...)
Junio C Hamano and Andy Parkins
Typefix builtin-prune.c::prune_object()
Improve git-prune -n output
Peter Baumann
config option log.showroot to show the diff of root commits
Andy Parkins
Add support to git-branch to show local and remote branches
Jakub Narebski (7)
gitweb: Finish restoring "blob" links in git_difftree_body
gitweb: Refactor feed generation, make output prettier, add Atom feed
gitweb: Add an option to href() to return full URL
gitweb: New improved formatting of chunk header in diff
gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
gitweb: Protect against possible warning in git_commitdiff
----------------------------------------------------------------
builtin-log.c | 177 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
3 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 7acf5d3..1c2838c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -99,6 +99,183 @@ int cmd_log(int argc, const char **argv, const char *prefix)
return cmd_log_walk(&rev);
}
+/* bits #0..7 in revision.h, #8..11 in commit.c */
+#define FPC_RESULT (1u<<12)
+#define FPC_SHOWN (1u<<13)
+
+struct author_record {
+ char *name;
+ int count;
+};
+struct author_count {
+ int nr, alloc;
+ struct author_record **au;
+};
+
+static int cmp_count(const void *a_, const void *b_)
+{
+ struct author_record **a = (struct author_record **) a_;
+ struct author_record **b = (struct author_record **) b_;
+ return (*b)->count - (*a)->count;
+}
+
+static void add_author(struct commit *c, struct author_count *ac)
+{
+ const char *buf = c->buffer;
+ char *au = strstr(buf, "\nauthor ");
+ char *eon;
+ struct author_record *ar;
+ int i;
+
+ if (!au)
+ return; /* oops */
+ au += 7;
+ while (*au && isspace(*au))
+ au++;
+ if (!*au)
+ return; /* oops */
+ eon = strchr(au, '<');
+ if (!eon)
+ return; /* oops */
+ while (au < --eon && isspace(*eon))
+ ; /* back back back... */
+ eon++;
+ for (i = 0; i < ac->nr; i++)
+ if (!strncmp(ac->au[i]->name, au, eon-au) &&
+ strlen(ac->au[i]->name) == eon - au) {
+ /* found it */
+ ac->au[i]->count++;
+ return;
+ }
+ if (ac->alloc <= ac->nr) {
+ ac->alloc = alloc_nr(ac->alloc);
+ ac->au = xrealloc(ac->au, sizeof(struct author_record *) *
+ ac->alloc);
+ }
+ ar = xcalloc(1, sizeof(struct author_record));
+ ar->name = xmalloc(eon - au + 1);
+ memcpy(ar->name, au, eon - au);
+ ar->name[eon - au] = 0;
+ ar->count = 1;
+ ac->au[ac->nr++] = ar;
+}
+
+static void show_fpc(struct object_array *list)
+{
+ int i;
+ struct author_count ac;
+
+ if (!list->nr)
+ return;
+ memset(&ac, 0, sizeof(ac));
+ for (i = 0; i < list->nr; i++)
+ add_author((struct commit *) list->objects[i].item, &ac);
+ qsort(ac.au, ac.nr, sizeof(struct author_record *), cmp_count);
+
+ for (i = 0; i < ac.nr; i++) {
+ if (i) {
+ if (i < ac.nr - 1)
+ fputs(", ", stdout);
+ else if (ac.nr != 2)
+ fputs(", and ", stdout);
+ else
+ fputs(" and ", stdout);
+ }
+ if (ac.au[i]->count < 2)
+ printf("%s", ac.au[i]->name);
+ else
+ printf("%s (%d)", ac.au[i]->name, ac.au[i]->count);
+ free(ac.au[i]->name);
+ free(ac.au[i]);
+ }
+ free(ac.au);
+ putchar('\n');
+
+ for (i = 0; i < list->nr; i++) {
+ struct commit *c = (struct commit *) list->objects[i].item;
+ char *buf = c->buffer;
+ char *it = "<unnamed>";
+ int len = strlen(it);
+ buf = strstr(buf, "\n\n");
+ if (buf) {
+ char *lineend;
+ while (*buf && isspace(*buf))
+ buf++;
+ if (!*buf)
+ goto emit;
+ lineend = strchr(buf, '\n');
+ if (!lineend)
+ goto emit;
+ while (buf < lineend && isspace(*lineend))
+ lineend--;
+ len = lineend - buf + 1;
+ it = buf;
+ }
+ emit:
+ printf(" %.*s\n", len, it);
+ }
+ putchar('\n');
+}
+
+int cmd_log_fpc(int argc, const char **argv, const char *prefix)
+{
+ struct rev_info rev;
+ struct commit *c;
+ struct object_array result = { 0, 0, NULL };
+ int i;
+
+ git_config(git_log_config);
+ init_revisions(&rev, prefix);
+ rev.always_show_header = 1;
+ cmd_log_init(argc, argv, prefix, &rev);
+
+ prepare_revision_walk(&rev);
+ while ((c = get_revision(&rev)) != NULL)
+ add_object_array(&(c->object), NULL, &result);
+
+ /* clear flags and mark them "relevant" */
+ for (i = 0; i < result.nr; i++)
+ result.objects[i].item->flags |= FPC_RESULT;
+
+ for (;;) {
+ struct object_array current;
+
+ for (i = 0; i < result.nr; i++) {
+ if (!(result.objects[i].item->flags & FPC_SHOWN))
+ break;
+ }
+ if (i >= result.nr)
+ break;
+
+ memset(¤t, 0, sizeof(current));
+ c = (struct commit *) result.objects[i].item;
+ while (c) {
+ int flags = c->object.flags;
+
+ if ((flags & (FPC_RESULT|FPC_SHOWN)) == FPC_RESULT) {
+ add_object_array(&(c->object), NULL, ¤t);
+ c->object.flags |= FPC_SHOWN;
+ }
+ if (!c->object.parsed)
+ parse_object(c->object.sha1);
+ if (!c->parents)
+ break;
+ c = c->parents->item;
+ }
+
+ /* Finally, show the series. */
+ show_fpc(¤t);
+ }
+
+ /* free them */
+ for (i = 0; i < result.nr; i++) {
+ c = (struct commit *) result.objects[i].item;
+ free(c->buffer);
+ free_commit_list(c->parents);
+ }
+ return 0;
+}
+
static int istitlechar(char c)
{
return (c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') ||
diff --git a/builtin.h b/builtin.h
index 43fed32..a94540d 100644
--- a/builtin.h
+++ b/builtin.h
@@ -38,6 +38,7 @@ extern int cmd_grep(int argc, const char **argv, const char *prefix);
extern int cmd_help(int argc, const char **argv, const char *prefix);
extern int cmd_init_db(int argc, const char **argv, const char *prefix);
extern int cmd_log(int argc, const char **argv, const char *prefix);
+extern int cmd_log_fpc(int argc, const char **argv, const char *prefix);
extern int cmd_ls_files(int argc, const char **argv, const char *prefix);
extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 1aa07a5..65d98bd 100644
--- a/git.c
+++ b/git.c
@@ -243,6 +243,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "help", cmd_help },
{ "init-db", cmd_init_db },
{ "log", cmd_log, RUN_SETUP | USE_PAGER },
+ { "log-fpc", cmd_log_fpc, RUN_SETUP | USE_PAGER },
{ "ls-files", cmd_ls_files, RUN_SETUP },
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
{ "mailinfo", cmd_mailinfo },
--
1.4.4.1.ge3fb
^ permalink raw reply related
* Re: [RFD] making separate-remote layout easier to use
From: Josef Weidendorfer @ 2006-11-27 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wnr19do.fsf@assigned-by-dhcp.cox.net>
On Saturday 25 November 2006 22:53, Junio C Hamano wrote:
> - merging the "primary" branch is good only when the user is on
> the corresponding "primary" branch. It is usually a wrong
> thing to do when on another branch.
I vote for a config option
core.pull.stopWithoutDefaultMerge
which would error out on a
git pull
when no branch.<current branch>.merge is set with a message like
"No default remote branch set to merge into current branch <branch>.
Set branch.<branch>.remote/merge to make this work"
It is arguable if this option should change the behavior of
"git pull <repo>". Probably not: I would assume that the
user explicitly wants to merge the primary branch of <repo>.
Additionally, set branch.<primary>.remote/merge on git-clone,
together with core.pull.stopWithoutDefaultMerge=1.
^ permalink raw reply
* Idea for rebase strategy
From: Johannes Schindelin @ 2006-11-27 0:15 UTC (permalink / raw)
To: git
Hi,
an idea hit me today: maybe we can make rebase work nicely with merges
after all. We could record the original branch point and the new branch
point for rebases.
If this information is somehow accessible when doing a merge, git could
check if the old branch point is reachable from the current HEAD, but not
the new branch point, and if both are the case, rebase the changes since
the old branch point on top of the new branch point before trying to
merge.
Does this sound too far-fetched?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Teach git-branch howto rename a branch
From: Josef Weidendorfer @ 2006-11-26 23:56 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1164409429445-git-send-email-hjemli@gmail.com>
On Saturday 25 November 2006 00:03, Lars Hjemli wrote:
> This adds a '--rename' option to git branch. If specified, branch
> creation becomes branch renaming.
This probably also should rename all config keys
branch.<oldname>.*
into
branch.<newname>.*
^ permalink raw reply
* [PATCH] git-clone: Rename --use-immingled-remote option to --no-separate-remote
From: Jakub Narebski @ 2006-11-26 23:22 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-clone.txt | 4 ++--
git-clone.sh | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 4cb4223..d5efa00 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--use-separate-remote | --use-immingled-remote] <repository>
+ [--use-separate-remote | --no-separate-remote] <repository>
[<directory>]
DESCRIPTION
@@ -105,7 +105,7 @@ OPTIONS
of `$GIT_DIR/refs/heads/`. Only the local master branch is
saved in the latter. This is the default.
---use-immingled-remote::
+--no-separate-remote::
Save remotes heads in the same namespace as the local
heads, `$GIT_DIR/refs/heads/'. In regular repositories,
this is a legacy setup git-clone created by default in
diff --git a/git-clone.sh b/git-clone.sh
index d4ee93f..8964039 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--use-immingled-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ die "Usage: $0 [--template=<template_directory>] [--no-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
}
get_repo_base() {
@@ -140,7 +140,7 @@ while
*,--use-separate-remote)
# default
use_separate_remote=t ;;
- *,--use-immingled-remote)
+ *,--no-separate-remote)
use_separate_remote= ;;
1,--reference) usage ;;
*,--reference)
@@ -176,7 +176,7 @@ repo="$1"
test -n "$repo" ||
die 'you must specify a repository to clone.'
-# --bare implies --no-checkout and --use-immingled-remote
+# --bare implies --no-checkout and --no-separate-remote
if test yes = "$bare"
then
if test yes = "$origin_override"
--
1.4.4.1
^ permalink raw reply related
* Re: [PATCH] Make logAllRefUpdates true by default
From: Horst H. von Brand @ 2006-11-26 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anand Kumria, git
In-Reply-To: <7vhcwmt19w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> Having thought about all the above, I think the event to create
> distribution/synchronization point repositories are rare enough
> and the simplest and cleanest way might be to make it default
> and add a --without-reflog option to the command, and forget
> about the guessing.
Looks sanest. I hate stuff that tries to outguess me by being "smart" (part
of the reason I love Unixy systems).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: [PATCH] grep: do not skip unmerged entries when grepping in the working tree.
From: Johannes Sixt @ 2006-11-26 21:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vvel2rl05.fsf@assigned-by-dhcp.cox.net>
On Sunday 26 November 2006 21:49, Junio C Hamano wrote:
> We used to skip unmerged entries, which made sense for grepping
> in the cached copies, but not for grepping in the files on the
> working tree.
>
> Noticed by Johannes Sixt.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes my problem. Thanks!
^ permalink raw reply
* [PATCH] grep: do not skip unmerged entries when grepping in the working tree.
From: Junio C Hamano @ 2006-11-26 20:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <ekc9q7$36e$1@sea.gmane.org>
We used to skip unmerged entries, which made sense for grepping
in the cached copies, but not for grepping in the files on the
working tree.
Noticed by Johannes Sixt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Johannes Sixt <johannes.sixt@telecom.at> writes:
> $ git-grep getSibling -- kdbg/exprwnd.h # this file had a conflict
> $ grep getSibling -- kdbg/exprwnd.h
> { return static_cast<VarTree*>(getSibling()); }
> $ git-update-index kdbg/exprwnd.h
> $ git-grep getSibling -- kdbg/exprwnd.h
> kdbg/exprwnd.h: { return static_cast<VarTree*>(getSibling()); }
This is because unmerged entries were ignored.
builtin-grep.c | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ad7dc00..9873e3d 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -268,7 +268,7 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
char *name;
- if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
+ if (!S_ISREG(ntohl(ce->ce_mode)))
continue;
if (!pathspec_matches(paths, ce->name))
continue;
@@ -280,12 +280,19 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
memcpy(name + 2, ce->name, len + 1);
}
argv[argc++] = name;
- if (argc < MAXARGS)
+ if (argc < MAXARGS && !ce_stage(ce))
continue;
status = exec_grep(argc, argv);
if (0 < status)
hit = 1;
argc = nr;
+ if (ce_stage(ce)) {
+ do {
+ i++;
+ } while (i < active_nr &&
+ !strcmp(ce->name, active_cache[i]->name));
+ i--; /* compensate for loop control */
+ }
}
if (argc > nr) {
status = exec_grep(argc, argv);
@@ -316,14 +323,24 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
for (nr = 0; nr < active_nr; nr++) {
struct cache_entry *ce = active_cache[nr];
- if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
+ if (!S_ISREG(ntohl(ce->ce_mode)))
continue;
if (!pathspec_matches(paths, ce->name))
continue;
- if (cached)
+ if (cached) {
+ if (ce_stage(ce))
+ continue;
hit |= grep_sha1(opt, ce->sha1, ce->name, 0);
+ }
else
hit |= grep_file(opt, ce->name);
+ if (ce_stage(ce)) {
+ do {
+ nr++;
+ } while (nr < active_nr &&
+ !strcmp(ce->name, active_cache[nr]->name));
+ nr--; /* compensate for loop control */
+ }
}
free_grep_patterns(opt);
return hit;
--
1.4.4.1.ge3fb
^ permalink raw reply related
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Junio C Hamano @ 2006-11-26 20:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: catalin.marinas, Git Mailing List, Junio C Hamano
In-Reply-To: <e5bfff550611260827t686a5071w7f050f17f784e5d9@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> In a StGit repository the --all option causes a lot of spurious
> revisions, possibly stgit related.
>
> $ git branch
> * master
> origin
> test
>
> $ git rev-list master origin test -- src/settingsimpl.cpp | wc
> 13 13 533
>
> $ git rev-list --all -- src/settingsimpl.cpp | wc
> 26 26 1066
>
>
> The extra revisions have shortlogs of the kind of:
>
> push a3bc76fd0bdd154149c26a3c208f0344e9cd873b
> new e7baf56544cd8b4f8601a35fad274b8de97fd558
> refresh 8fa01a56a40b04ed9c6d006c669ca9d370176728
>
>>From qgit these are easily seen from file history tab of a file
> modified by stgit patches or when filtering in main view on the same
> file.
>
> Shouldn't 'git-rev-list --all' print *the same output* of when the
> list with all branches is given in command line?
Should it? The "--all" option is about "all refs", not "all
user branches" and it has been so from the beginning. For one
thing it has to do the reachability thing also for tags
(otherwise it cannot be used as the upstream for git-repack
pipeline).
You are looking at .git/refs/bases/ refs that StGIT uses for its
internal bookkeeping.
^ permalink raw reply
* Re: [PATCH] Make logAllRefUpdates true by default
From: Junio C Hamano @ 2006-11-26 20:12 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <11645554033331-git-send-email-wildfire@progsoc.org>
I do not think I can take this patch in its current form.
Although I think majority of users would find it convenient to
have ref-log enabled by default on repositories to be developed
in, it does not make sense to enable ref-log by default for bare
repositories that is used as a distribution point. So at least
this needs an option to disable it (if you make it the default),
or enable it.
Side note. A ref-log at a distribution point _could_ be
used for somebody to say "Hey, I pushed that fix three
days ago -- why are you complaining about the breakage
I've already fixed before checking the public tip?", but
that is a manifestation of lack of communication among
people and a SCM is not about solving that problem.
But having to add an option tends to drive people nuts. We
already have --shared and --template, so adding --with-reflog
would be "just one more option" that we may not have to worry
too much about, but we would have to revisit this as we gain
more experience using git and more best-current-practices are
learned. I wonder if we can infer if a particular invocation of
init-db is to prepare a repository to be developed in without
being told with a command line option. If we can do so, then we
can do the configuratio setting with --with-reflog=[yes|no|guess]
option (and lack of --with-reflog means "guess").
There are three use cases that init-db is run directly from the
command line, and I think you want different behaviours.
(1) you have a directory, perhaps already with many files
there, because you are doing an initial import to prepare a
repository to work in. You obviously want a ref-log there,
and you want --shared=no. You do not care about
denyNonFastForwards because you are not likely to be
pushing into it.
(2) you are preparing a public distribution point for _your_
own tree. You do not want a ref-log, you want --shared=no,
and you _might_ want denyNonFastForwards.
(3) you are preparing a public shared repository for project
members to use to synchronize, CVS-style. You do not want
a ref-log, you do want --shared=group, and and you want
denyNonFastForwards.
Another case that init-db is run indirectly is via git-clone and
via foreign SCM importers. I think enabling ref-log during
non-bare clone, for example, should behave similarly to (1)
because the resulting repository is clearly meant to be used
with a working tree in which to develop. A bare clone is either
(2) or (3) but you do not have to decide what to do with ref-log
(i.e. "don't"). But in these "indirect" cases, the command that
drives init-db can explicitly tell init-db what it is doing, and
we would need to have both --with-reflog and --without-reflog
options so that the command can tell what it wants from init-db
explicitly without having init-db guess.
If you can come up with a reliable way to tell (1)..(3) then we
can make init-db to do the right thing without an end user to
tell what should happen --with-reflog or --without-reflog; and
they do not even have to say --shared anymore as an added bonus.
Having thought about all the above, I think the event to create
distribution/synchronization point repositories are rare enough
and the simplest and cleanest way might be to make it default
and add a --without-reflog option to the command, and forget
about the guessing.
^ 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