* Re: pull into dirty working tree
From: Alex Riesen @ 2007-06-13 20:47 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Bill Lear, git
In-Reply-To: <86645r1wh8.fsf@blue.stonehenge.com>
Randal L. Schwartz, Wed, Jun 13, 2007 21:32:35 +0200:
> Alex> Wont work for new files (not yet known to git) which conflict with the
> Alex> same names from origin. Your method will not put them anywhere and
> Alex> their presence will break git-rebase. You _must_ do a merge.
>
> So I missed git-add for those. Then it'll work. I guess I implied that the
> git-commit initial step should capture all of the "interesting" state.
No, it wont. What files are you going to add? All, but *.o? All, but
*.log? What if user hasn't setup .gitignore yet? What if he meant to
add an ignored file anyway?
> git-rebase *will* do the merge. It must. :)
It won't merge anything which isn't known to git. Now, I come to think
about it, no existing merge method will help you here (and very likely
it shouldn't).
It is actually much simplier doing things right: all this stashing
people keep talking about.
^ permalink raw reply
* Re: [StGIT PATCH 2/4] Abstract a PatchSet object out of Series.
From: Yann Dirson @ 2007-06-13 20:38 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0706121509j5088e164iadedb561501d6a55@mail.gmail.com>
On Tue, Jun 12, 2007 at 11:09:50PM +0100, Catalin Marinas wrote:
> On 11/06/07, Yann Dirson <ydirson@altern.org> wrote:
> >The goal is to move into PatchSet all functionnality that is not
> >dependant of Series being a real stack, paving the way for handling
> >parallel (hydra) stacks, or any other way to organize patches.
>
> Thanks for the patches. I applied this one as well and I like the
> idea. What is your long-term plan with this split?
I have started to work on a Hydra class (available at [1], but be
aware it doesn't do much more than creating an octopus, and breaking
many current StGIT assumptions), with a testcase to demonstrate its
use), which binds together a set of stacks with an octopus, to allow
keeping related patches together, and allow people to pull from one
topic stack without getting unrelated work.
I'm however facing a problem, with the pervasive assumption that we
only have stacks :). Basically, we probably need a factory of
PatchSet objects, which would return a Series or an Hydra according to
the specified name - I'm currently thinking about this, but don't
expect any working code too rapidly.
> The HEAD in my repository fails the test suite. Do you have any
> additional patches pending (some patches were not applied in order as
> I had to manually fix the conflicts). Anyway, please check my
> repository for any missing patches.
Oh, I had not noticed you had applied
bd69feaf7c3c94b6e7e216ea8091064af9cdfa97. Sorry, I was not explicit
enough when posing this, only the cover mail included "RFC" in the
subject. As described in that mail, there are problems both with the
original approach (Karl's test failing), and with that new one (that
exisiting test failing).
Do you have any idea on how we could overcome the problem ? In the
meantime, we could possibly just comment that testcase out (or add
support for continuing the testsuite even with a failure) - the
problem it exhibits is probably less common than the one that was
fixed.
BTW, a02ba4077f12578fe31c99d903488804a656e1c4 has a slight problem: it
is a patch by Karl, which I re-sent in the same group since it was
exhibiting the problem (and with the intent of adding a signed-off-by
line, but my way of adding them trough a buggy template showed its
limits and the commit now have 2 signed-off-by lines with Karl's
name). However, it was applied with myself as author, which is quite
wrong: could that be a but in "stg import" ignoring the Author field ?
Best regards,
--
Yann.
[1] http://repo.or.cz/w/stgit/ydirson.git
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-06-13 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy54tt3l.fsf@assigned-by-dhcp.cox.net>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* lh/submodule (Tue Jun 12 09:05:21 2007 +0200) 5 commits
+ Add gitmodules(5)
+ git-submodule: give submodules proper names
+ Rename sections from "module" to "submodule" in .gitmodules
+ git-submodule: remember to checkout after clone
+ t7400: barf if git-submodule removes or replaces a file
Soon to be merged to 'master' as 1.5.3 material, but still needs a
trivial fix to the Documentation/gitmodules.txt, though.
* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
+ filter-branch: subdirectory filter needs --full-history
+ filter-branch: Simplify parent computation.
+ Teach filter-branch about subdirectory filtering
+ filter-branch: also don't fail in map() if a commit cannot be
mapped
+ filter-branch: Use rev-list arguments to specify revision ranges.
+ filter-branch: fix behaviour of '-k'
+ filter-branch: use $(($i+1)) instead of $((i+1))
+ chmod +x git-filter-branch.sh
+ filter-branch: prevent filters from reading from stdin
+ t7003: make test repeatable
+ Add git-filter-branch
Soon to be merged to 'master' as 1.5.3 material, but still needs
documentation, and culling of empty side branches.
* fl/cvsserver (Thu Jun 7 16:57:01 2007 +0200) 1 commit
+ cvsserver: Add some useful commandline options
To merge.
* gp/branch (Sat Jun 9 12:40:35 2007 +0000) 1 commit
+ git-branch: cleanup config file when deleting branches
To merge.
* jc/remote (Sat Jun 9 11:01:23 2007 -0700) 6 commits
+ git-push: Update description of refspecs and add examples
+ remote.c: "git-push frotz" should update what matches at the
source.
+ remote.c: fix "git push" weak match disambiguation
+ remote.c: minor clean-up of match_explicit()
+ remote.c: refactor creation of new dst ref
+ remote.c: refactor match_explicit_refs()
To merge; this is an fix to fairly annoying breakage.
* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
+ git-svn: allow dcommit to retain local merge information
Hoping to be able to merge it to 'master', as it would be a big
usability improvement for people who use "git to merge because
SVN cannot" (without this, life ater such a merge will
unfortunately be miserable).
* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
+ builtin-add: simplify (and increase accuracy of) exclude handling
+ dir_struct: add collect_ignored option
Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct. Help is
appreciated.
* jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
+ Extend --pretty=oneline to cover the first paragraph,
+ Lift 16kB limit of log message output
Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct. Help is
appreciated.
* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
- Quiet the output from git-init when cloning, if requested.
- Add an option to quiet git-init.
Undecided. I do not have anything against these two patches, as
they are obviously correct. It's just the fact that nobody
complained my keeping these packed on 'pu' suggests there is not
much desire, and it is an extra option we need to maintain.
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
- filter-branch: always export GIT_DIR if it is set
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
- make git barf when an alias changes environment variables
- setup_git_directory: fix segfault if repository is found in cwd
- test GIT_WORK_TREE
- extend rev-parse test for --is-inside-work-tree
- Use new semantics of is_bare/inside_git_dir/inside_work_tree
- introduce GIT_WORK_TREE to specify the work tree
- test git rev-parse
- rev-parse: introduce --is-bare-repository
- rev-parse: document --is-inside-git-dir
Undecided. Some people would want to have a way to have GIT_DIR
point at somewhere unusual and still want to work from within a
subdirectory, which is probably a valid thing to support. This
is not something I would use myself, so I am mostly worried
about the impact these changes may have on people who do not use
this feature.
^ permalink raw reply
* Re: [RFC][PATCH 00/10] Sparse: Git's "make check" target
From: Josh Triplett @ 2007-06-13 20:25 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, linux-sparse
In-Reply-To: <466ED9CE.3000800@ramsay1.demon.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]
Ramsay Jones wrote:
> Josh Triplett wrote:
>> Ramsay Jones wrote:
>>> fix most of those problems. (the output from "make check" was about 16k
>>> lines at one point!). Git also tickled a bug in sparse 0.2, which resulted
>>> in some 120+ lines of bogus warnings; that was fixed in version 0.3 (commit
>>> 0.2-15-gef25961). As a result, sparse version 0.3 + my patches, elicits 106
>>> lines of output from "make check".
>> One note about using Sparse with Git: you almost certainly don't want to pass
>> -Wall to sparse, and current Git passes CFLAGS to Sparse which will do exactly
>> that. -Wall turns on all possible Sparse warnings, including nitpicky
>> warnings and warnings with a high false positive rate.
>
> I have to say that, my initial reaction, was to disagree; I certainly want to
> pass -Wall to sparse! Why not? Did you have any particular warnings in mind?
> (I haven't noticed any that were nitpicky or had a high false positive rate!)
If you don't mind the set of warnings you get, then sure, use -Wall.
Some of the ones I had in mind:
* -Wshadow. Not everyone cares.
* -Wptr-subtraction-blows. This warns any time you do ptr2 - ptr1.
* -Wundefined-preprocessor. This warns if you ever do
#if SYMBOL
when SYMBOL might not actually have a definition. Many projects do exactly
that, and the C standard allows it.
* -Wtypesign. Off by default for the same reason that GCC doesn't give sign
mismatches by default: too many codebases with too many sloppy signedness
issues that drown out other issues.
> ... You should start from
>> the default set of Sparse warnings, and add additional warnings as desired, or
>> turn off those you absolutely can't live with.
>
> Why not "-Wall -Wno-nitpicky -Wno-false-positive" ;-)
If you don't mind that, then sure. You might have to adjust the warning list
to taste from time to time. But please do use -Wall if you feel comfortable
with the warnings it produces.
> ... Current Sparse from Git (post
>> 0.3, after commit e18c1014449adf42520daa9d3e53f78a3d98da34) has a change to
>> cgcc to filter out -Wall, so you can pass -Wall to GCC but not Sparse.
>
> Yes, I noticed that. Again, I'm not sure I agree.
> I didn't comment on that patch, because my exposure to sparse is very limited.
> So far I've only run it on git, so I can hardly claim any great experience with
> the output from sparse. However, 105 lines of output (which represents 71 warnings)
> for 72,974 lines of C (in 179 .c files) did not seem at all unreasonable.
True; for a project the size of Git, you can reasonably handle all the
warnings as you did.
If you want to use -Wall with sparse, you can always pass -Wall to sparse
directly, or use CHECK="sparse -Wall" cgcc.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: pull into dirty working tree
From: Robin Rosenberg @ 2007-06-13 20:17 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, Michael Dressel, git
In-Reply-To: <18032.15862.835008.22589@lisa.zopyra.com>
onsdag 13 juni 2007 skrev Bill Lear:
> On Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes:
> >Hi,
> >
> >On Wed, 13 Jun 2007, Bill Lear wrote:
> >
> >> Not completely: they don't want to commit, as this will then "pollute"
> >> the history in their working repository (which is just temporarily
> >> being used to play with a new feature, idea, bug fix, optimization,
> >> etc.). This pollution with a handful of garbage would then have to be
> >> undone were they to say "ok, that's really not a good idea". If a
> >> pull into a dirty tree were possible, that last step could be just a
> >> simple reset, or continuing to explore with the code, etc.
> >
> >Notice that I am _not_ saying that CVS is bad. I am saying that their
> >workflow is likely bad (and yes, they should change that workflow, since
> >they now _can_).
>
> Yes, I have urged this. But, they are stubborn, smart people, and if
> they see tool X allow something, they wonder why tool Y does not
> support it.
>
> >Two things do they risk happily, which they should not do:
> >
> >- they test their new feature against different references. For example,
> > it might well be that they tested cases A, B, and C before pull, and D,
> > E and F after that. It is really easy to get lost in what you have, and
> > what not. Now, guess what. Merges are known to break things sometimes.
> > Even the best merge algorithm. Now your developers say "we tested it,
> > and the merge broke it, it's not our fault". But it is.
>
> Well, their testing is something along the line of "I'm going to hack
> something here, and then I want to see if Joe's latest changes work
> with it". Then, they want to pull in Joe's changes, run a test, and
> if their changes don't work, fix them, discard them, etc.
>
> >- That new feature will have to be committed at some stage. Either your
> > devs commit at the end, which makes it a monster commit, which is bad.
> > Or they are _already_ using the suggested workflow "commit && pull",
> > which makes your whole complaint moot.
>
> Perhaps: again, they may just be taking stabs that they know are wild,
> and will likely not be committed.
>
> I'm not trying to argue for their point: I do most of my new work
> on branches, very rarely on the master branch, and can handle
> the git pull not working in a dirty tree with merge issues.
>
> Some of the people we work with are not developers per se: they are
> engineers who sometimes like to fiddle (say, with a compiler
> optimization setting) and who never push into our company repo.
> They only see CVS and compare git to it. When git prevents you
> from doing something they see as perfectly reasonable, they get
> annoyed and say "git sucks". I'm battling in the git corner against
> this, but there is only so much I can do.
A typical case I recognize is a few printfs or disabling a feature that makes
it harder to debug with no intentions whatsoever to commit them. What we see
when the tools more or less forces people to "temporarily" commit stuff is
that that stuff is often left there. "Oh, I forgot". Gah.
Git has this ability when checking out, so why not on pull or merge?
With stacked git I typically create a new patch, then I can push it whenever I
want to have some more tracing.
-- robin
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-06-13 20:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v7iqgtt1j.fsf@assigned-by-dhcp.cox.net>
I'll be dormant for the next 72 hours or so, so please do not
get alarmed if no patches sent to the list is applied to my
tree. Please remind me about them after they are commented on,
revised and improved, and final revision got agreed to be good
on the list.
WIth a big usability change to git-gui blame viewer on 'maint',
I think it is time to do 1.5.2.2 this weekend (if I have the
energy, that is).
The 'master' side has quite a lot of clean-ups and improvements
in the fringes, but nothing big has come out of 'next' since
1.5.2. I would want to start the 1.5.3-rc cycle, after merging
at least the submodule Porcelain (Lars) and filter-tree
(Johannes and Pasky). There are other topics already on 'next'
that are probably 1.5.3 material as well.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (2):
Make the installation target of git-gui a little less chatty
Fix clone to setup the origin if its name ends with .git
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Junio C Hamano (1):
checkout: do not get confused with ambiguous tag/branch names
Kristian Høgsberg (1):
Unquote From line from patch before comparing with given from address.
Luiz Fernando N. Capitulino (1):
git-cherry: Document 'limit' command-line option
Matthijs Melchior (1):
New selection indication and softer colors
Sam Vilain (1):
Don't assume tree entries that are not dirs are blobs
Shawn O. Pearce (47):
git-gui: Allow creating a branch when none exists
git-gui: Allow as few as 0 lines of diff context
git-gui: Don't quit when we destroy a child widget
git-gui: Attach font_ui to all spinbox widgets
git-gui: Verify Tcl/Tk is new enough for our needs
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Add a 4 digit commit abbreviation to the blame viewer
git-gui: Cleanup blame::new widget initialization
git-gui: Remove empty blank line at end of blame
git-gui: Improve the coloring in blame viewer
git-gui: Simplify consecutive lines that come from the same commit
git-gui: Use arror cursor in blame viewer file data
git-gui: Display tooltips in blame viewer
git-gui: Highlight the blame commit header from everything else
git-gui: Remove unnecessary reshow of blamed commit
git-gui: Cleanup minor style nit
git-gui: Space the commit group continuation out in blame view
git-gui: Show author initials in blame groups
git-gui: Allow the user to control the blame/commit split point
git-gui: Display a progress bar during blame annotation gathering
git-gui: Allow digging through history in blame viewer
git-gui: Combine blame groups only if commit and filename match
git-gui: Show original filename in blame tooltip
git-gui: Use a label instead of a button for the back button
git-gui: Clip the commit summaries in the blame history menu
git-gui: Remove the loaded column from the blame viewer
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Use lighter colors in blame view
git-gui: Make the line number column slightly wider in blame
git-gui: Automatically expand the line number column as needed
git-gui: Remove unused commit_list from blame viewer
git-gui: Better document our blame variables
git-gui: Cleanup redundant column management in blame viewer
git-gui: Switch internal blame structure to Tcl lists
git-gui: Label the uncommitted blame history entry
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Display the "Loading annotation..." message in italic
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display both commits in our tooltips
git-gui: Jump to original line in blame viewer
git-gui: Use three colors for the blame viewer background
git-gui: Improve our labeling of blame annotation types
git-gui: Favor the original annotations over the recent ones
git-gui: Changed blame header bar background to match main window
git-gui: Include 'war on whitespace' fixes from git.git
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Save geometry before the window layout is damaged
william pursell (1):
Make command description imperative statement, not third-person present.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix push with refspecs containing wildcards
Alexandre Julliard (1):
pack-check: Sort entries by pack offset before unpacking them.
Andy Whitcroft (3):
cvsimport: add support for new style remote layout
cvsimport: update documentation to include separate remotes option
cvsimport: add <remote>/HEAD reference in separate remotes more
Aneesh Kumar K.V (2):
gitview: Fix the blame interface.
gitview: run blame with -C -C
Dan McGee (1):
git-mergetool: Allow gvimdiff to be used as a mergetool
Elvis Pranskevichus (1):
Use git-tag in git-cvsimport
Eric Wong (3):
git-svn: cleanup: factor out longest_common_path() function
git-svn: test for creating new directories over svn://
git-svn: reduce stat() calls for a backwards compatibility check
Frank Lichtenheld (1):
cvsserver: Make req_Root more critical of its input data
Jakub Narebski (6):
gitweb: Provide links to commitdiff to each parent in 'commitdiff' view
gitweb: Improve "next" link in commitdiff view
gitweb: Split git_patchset_body into separate subroutines
gitweb: Create special from-file/to-file header for combined diff
gitweb: Add links to blobdiffs in from-file/to-file header for merges
gitweb: '--cc' for merges in 'commitdiff' view
Jeff King (2):
cmd_log_init: remove parsing of --encoding command line parameter
refactor dir_add_name
Jim Meyering (1):
Don't dereference a strdup-returned NULL
Johan Herland (1):
Remove unnecessary code and comments on non-existing 8kB tag object restriction
Johannes Schindelin (2):
git-merge-file: refuse to merge binary files
Teach diff to imply --find-copies-harder upon -C -C
Johannes Sixt (3):
Avoid double-slash in path names that depend on $(sharedir).
Remove trailing slash from $(template_dir).
git-remote show: Also shorten non-fast-forward refs in the 'push' listing
Junio C Hamano (12):
War on whitespace
Test wildcard push/fetch
More missing static
More missing static
Even more missing static
git-blame: do not indent with spaces.
git-blame -w: ignore whitespace
mktag: minimally update the description.
Makefile: common-cmds.h depends on generate-cmdlist.sh script
Makefile: allow generating git.o for debugging purposes
-Wold-style-definition fix
More static
Lars Hjemli (2):
git-submodule: move cloning into a separate function
git-submodule: clone during update, not during init
Linus Torvalds (1):
Makefile: add an explicit rule for building assembly output
Matthias Lederhofer (1):
gitweb: change filename/directory name of snapshots
Michael Ellerman (2):
gitview: Use new-style classes
gitview: Define __slots__ for Commit
Pierre Habouzit (2):
Active_nr is unsigned, hence can't be < 0
Missing statics.
René Scharfe (1):
t5000: silence unzip availability check
Shawn O. Pearce (10):
git gui 0.8.0
git-gui: GUI support for running 'git remote prune <name>'
git-gui: Show the git-gui library path in 'About git-gui'
git-gui: Enable verbose Tcl loading earlier
git-gui: Provide fatal error if library is unavailable
git-gui: Disable tearoff menus on Windows, Mac OS X
git-gui: Allow users to rename branches through 'branch -m'
git-gui: Allow users to delete remote branches
git-gui: Expose the merge.diffstat configuration option
git-gui: Internalize symbolic-ref HEAD reading logic
Theodore Ts'o (1):
git-mergetool: Make default selection of merge-tool more intelligent
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Jeff King @ 2007-06-13 20:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706131953370.4059@racer.site>
On Wed, Jun 13, 2007 at 07:54:59PM +0100, Johannes Schindelin wrote:
> :-) Since you seem comfortable with regular expressions, maybe you can
> help me: I am looking for a pattern which matches _any_ character, and one
> which matches only non-newlines, both with and without REG_NEWLINE. Hmm?
Without REG_NEWLINE, any character is just '.', but I think you are
stuck with '[^
]' for non-newlines, since POSIX makes no provisions for quoting the
newline (I just skimmed through POSIX chapter 9, and I didn't see
anything useful).
With REG_NEWLINE, non-newlines is of course '.'. Matching both is tricky
without using extended regular expressions (where you could just do '.|
'). In fact, I have been playing with it for a few minutes and I can't
seem to find a good way, since you really want to represent '.' _inside_
a bracketed alternation sequence. But I don't think there's a character
class for "everything".
I think this would be much easier with pcre, but ISTR some opposition to
that a few months back.
So that's probably not very helpful to you, but at least you have
confirmation from one other person that the answer isn't totally
obvious. :)
-Peff
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Junio C Hamano @ 2007-06-13 19:57 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, David Watson
In-Reply-To: <200706132034.29934.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2007, June 13, David Watson wrote:
>> I've got a problem, or maybe annoyance is more the proper term, that
>> I haven't seen solved by any SCM system (at least not to my
>> knowledge). Basically, I may make some changes, e.g. to a Makefile or
>> somesuch, that I want to ignore when looking at what's changed from
>
> So you want to tell git to track a file and then have it not track
> changes to that file? Sounds crazy to me. Don't put files in the
> repository that you don't want tracking.
Actually, that is a sign that either the upstream project is
broken, and/or the user's workflow is broken.
Taking an example closer to home, if we tell tell users "in
config.mk file you can suit your local needs" and at the same
time add config.mk to the official repository, that would be
crazy. The changes to that file is _supposed_ to be local and
the other side will never be interested in getting updates to
that file. So if David is dealing with such a situation, then
the problem is in the project organization.
On the other hand, it is usual to see a comment in the Makefile
that says "# No user tweakable part below this line", with
expectations that users will muck with make variable definitions
in the earlier parts of the Makefile to suit the local
filesystem layout and such.
The changes users will make to such a file fall into one of two
categories:
(1) Local configuration changes to adjust to the user's
particular installation.
(2) Fixes, improvements and enhancements to the generic part
("below that line").
Other people, especially the "upstream" people, are never
interested in ever seeing patches of the former kind, while the
latter are of general use and you would want to feed themback.
You would need to separete out these two kinds at SOME stage
when you need to make changes of both kinds. You can do that at
patch submission time, cleaning up the series, if you are
feeding the changes via patches.
If you are communicating with the other side via pull/push, then
you would need to have two histories that cleanly separates the
two. Probably a good workflow is:
- The tracking branch remotes/origin/master; this holds what is
'pristine';
- Keep 'master' branch for only the changes for general
consumption.
- Have a separate 'local' branch, that is forked from 'master'
branch of yours. Local configuration changes will go to this
branch, never to 'master'.
You would never publish 'local' as it contains the local
configuration changes that are of no interest to others, but the
changes you may want to give back to outside will be readily
available in 'master'.
If I _were_ doing this, I would further use a topic branch that
forked from pristine to hold only the local changes, and use
'local' only as an integration branch between that local
configuration topic and 'master' (i.e. no commits will be made
to 'local' directly -- everything will come from either separate
topics or 'master').
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Andy Parkins @ 2007-06-13 19:34 UTC (permalink / raw)
To: git; +Cc: David Watson
In-Reply-To: <A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com>
On Wednesday 2007, June 13, David Watson wrote:
> I've got a problem, or maybe annoyance is more the proper term, that
> I haven't seen solved by any SCM system (at least not to my
> knowledge). Basically, I may make some changes, e.g. to a Makefile or
> somesuch, that I want to ignore when looking at what's changed from
So you want to tell git to track a file and then have it not track
changes to that file? Sounds crazy to me. Don't put files in the
repository that you don't want tracking.
What you want is an out-of-tree file for that sort of thing. Why can't
you just do
#!/usr/bin/make
-include Makefile.local
Rather than messing around with not tracking tracked files?
git does exactly that in it's own build process with a config.mak file,
which lets you specify, say, an install directory that is obviously
only valid for you.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: pull into dirty working tree
From: Randal L. Schwartz @ 2007-06-13 19:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bill Lear, git
In-Reply-To: <20070613192828.GB3412@steel.home>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> Wont work for new files (not yet known to git) which conflict with the
Alex> same names from origin. Your method will not put them anywhere and
Alex> their presence will break git-rebase. You _must_ do a merge.
So I missed git-add for those. Then it'll work. I guess I implied that the
git-commit initial step should capture all of the "interesting" state.
git-rebase *will* do the merge. It must. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Nicolas Pitre @ 2007-06-13 18:19 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <6D50717E-7FB2-48EE-9B56-42B658ACAD10@mimvista.com>
On Wed, 13 Jun 2007, David Watson wrote:
> It appears that only applies to untracked files. I am specifically interested
> in ignoring changes to files that are already tracked, unless I'm
> misunderstanding what you're suggesting. I just built the most recent git from
> repo.or.cz/git, and did the following:
>
> * edit the file I want to "ignore"
> git-status shows this file as modified
>
> * edit .git/config, set core.excludesfile to myexcludes, containing the name
> of the file I want
> * git add -u
> * git-status
> shows the file I edited as ready to be committed.
I suppose that the behavior of git-add could be modified to honnor the
exclude pattern even for already tracked files. Such change would make
sense to me.
Nicolas
^ permalink raw reply
* Re: pull into dirty working tree
From: Alex Riesen @ 2007-06-13 19:28 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Bill Lear, git
In-Reply-To: <86zm33291h.fsf@blue.stonehenge.com>
Randal L. Schwartz, Wed, Jun 13, 2007 17:01:14 +0200:
> > We have some CVS users who complain that they cannot do a pull
> > into a dirty working tree, as they could under CVS. Here is
> > their scenario: they make a few changes to their code and want
> > to test it out; someone else pushes changes to the central repo
> > that they then want to add to their working tree to test also;
> > they then want to pull in these changes and test everything, as
> > if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
>
> > They would like an option (perhaps a config option) to do a "dirty
> > pull".
>
> Maybe this will do it, presuming they haven't published any of their local
> work, and they're on a topic branch "topic"
>
> git-tag WIP # mark HEAD so we can come back
> git-commit -a -m WIP # commit current work so we can replay it
> git-fetch origin # grabs the upstream
> git-rebase origin # rebase current work-in-progress onto new upstream
> # might need to resolve and commit conflicts repeatedly
> git-reset --soft WIP # next commit will be on top of commit prior to rebase
> git-reset # mark all files as uncommitted as yet
> git-tag -d WIP # no more need for this tag
>
> This effectively puts the upstream changes "under" (or "prior to") the current
> topic branch.
>
Wont work for new files (not yet known to git) which conflict with the
same names from origin. Your method will not put them anywhere and
their presence will break git-rebase. You _must_ do a merge.
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Johannes Schindelin @ 2007-06-13 18:54 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070613184109.GG10941@coredump.intra.peff.net>
Hi,
On Wed, 13 Jun 2007, Jeff King wrote:
> On Wed, Jun 13, 2007 at 01:50:22AM +0100, Johannes Schindelin wrote:
>
> > Earlier, Git interpreted the pattern as a strict prefix, which made
> > the operator unsuited in many cases.
>
> Thank you for working on this...I really like the :/ concept, but find
> myself wishing for a regex all the time. I have been meaning to do it
> since you introduced the original. :)
:-) Since you seem comfortable with regular expressions, maybe you can
help me: I am looking for a pattern which matches _any_ character, and one
which matches only non-newlines, both with and without REG_NEWLINE. Hmm?
Tia,
Dscho
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 18:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael Dressel, git
In-Reply-To: <Pine.LNX.4.64.0706131929020.4059@racer.site>
On Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Wed, 13 Jun 2007, Bill Lear wrote:
>
>> Not completely: they don't want to commit, as this will then "pollute"
>> the history in their working repository (which is just temporarily
>> being used to play with a new feature, idea, bug fix, optimization,
>> etc.). This pollution with a handful of garbage would then have to be
>> undone were they to say "ok, that's really not a good idea". If a
>> pull into a dirty tree were possible, that last step could be just a
>> simple reset, or continuing to explore with the code, etc.
>
>Notice that I am _not_ saying that CVS is bad. I am saying that their
>workflow is likely bad (and yes, they should change that workflow, since
>they now _can_).
Yes, I have urged this. But, they are stubborn, smart people, and if
they see tool X allow something, they wonder why tool Y does not
support it.
>Two things do they risk happily, which they should not do:
>
>- they test their new feature against different references. For example,
> it might well be that they tested cases A, B, and C before pull, and D,
> E and F after that. It is really easy to get lost in what you have, and
> what not. Now, guess what. Merges are known to break things sometimes.
> Even the best merge algorithm. Now your developers say "we tested it,
> and the merge broke it, it's not our fault". But it is.
Well, their testing is something along the line of "I'm going to hack
something here, and then I want to see if Joe's latest changes work
with it". Then, they want to pull in Joe's changes, run a test, and
if their changes don't work, fix them, discard them, etc.
>- That new feature will have to be committed at some stage. Either your
> devs commit at the end, which makes it a monster commit, which is bad.
> Or they are _already_ using the suggested workflow "commit && pull",
> which makes your whole complaint moot.
Perhaps: again, they may just be taking stabs that they know are wild,
and will likely not be committed.
I'm not trying to argue for their point: I do most of my new work
on branches, very rarely on the master branch, and can handle
the git pull not working in a dirty tree with merge issues.
Some of the people we work with are not developers per se: they are
engineers who sometimes like to fiddle (say, with a compiler
optimization setting) and who never push into our company repo.
They only see CVS and compare git to it. When git prevents you
from doing something they see as perfectly reasonable, they get
annoyed and say "git sucks". I'm battling in the git corner against
this, but there is only so much I can do.
Bill
^ permalink raw reply
* [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Alex Riesen @ 2007-06-13 18:54 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Junio C Hamano
In-Reply-To: <81b0412b0706130051l570e6ab7y48d6eea8c6b2d97e@mail.gmail.com>
The function converts the value of h_errno (last error of name
resolver library, see netdb.h).
One of systems which supposedly do not have the function is SunOS.
POSIX does not mandate its presence.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Makefile | 5 +++++
compat/hstrerror.c | 21 +++++++++++++++++++++
git-compat-util.h | 5 +++++
3 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 compat/hstrerror.c
diff --git a/Makefile b/Makefile
index 0f6540c..e054bc7 100644
--- a/Makefile
+++ b/Makefile
@@ -410,6 +410,7 @@ ifeq ($(uname_S),SunOS)
NEEDS_NSL = YesPlease
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
+ NO_HSTRERROR = YesPlease
ifeq ($(uname_R),5.8)
NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
@@ -654,6 +655,10 @@ endif
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
+ifdef NO_HSTRERROR
+ COMPAT_CFLAGS += -DNO_HSTRERROR
+ COMPAT_OBJS += compat/hstrerror.o
+endif
ifeq ($(TCLTK_PATH),)
NO_TCLTK=NoThanks
diff --git a/compat/hstrerror.c b/compat/hstrerror.c
new file mode 100644
index 0000000..069c555
--- /dev/null
+++ b/compat/hstrerror.c
@@ -0,0 +1,21 @@
+#include <string.h>
+#include <stdio.h>
+#include <netdb.h>
+
+const char *githstrerror(int err)
+{
+ static char buffer[48];
+ switch (err)
+ {
+ case HOST_NOT_FOUND:
+ return "Authoritative answer: host not found";
+ case NO_DATA:
+ return "Valid name, no data record of requested type";
+ case NO_RECOVERY:
+ return "Non recoverable errors, FORMERR, REFUSED, NOTIMP";
+ case TRY_AGAIN:
+ return "Non-authoritative \"host not found\", or SERVERFAIL";
+ }
+ sprintf(buffer, "Name resolution error %d", err);
+ return buffer;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 6bd8987..b2ab3f8 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -167,6 +167,11 @@ extern size_t gitstrlcpy(char *, const char *, size_t);
extern uintmax_t gitstrtoumax(const char *, char **, int);
#endif
+#ifdef NO_HSTRERROR
+#define hstrerror githstrerror
+extern const char *githstrerror(int herror);
+#endif
+
extern void release_pack_memory(size_t, int);
static inline char* xstrdup(const char *str)
--
1.5.2.1.270.g288d3f
^ permalink raw reply related
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Jeff King @ 2007-06-13 18:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706130148080.4059@racer.site>
On Wed, Jun 13, 2007 at 01:50:22AM +0100, Johannes Schindelin wrote:
> Earlier, Git interpreted the pattern as a strict prefix, which made
> the operator unsuited in many cases.
Thank you for working on this...I really like the :/ concept, but find
myself wishing for a regex all the time. I have been meaning to do it
since you introduced the original. :)
-Peff
^ permalink raw reply
* Re: How to stage a tree with all changes?
From: Jeff King @ 2007-06-13 18:40 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861wgf964g.fsf@lola.quinscape.zz>
On Wed, Jun 13, 2007 at 06:22:23PM +0200, David Kastrup wrote:
> git-add .
> git-commit -a
>
> seemingly overlooks deletions.
It shouldn't. Try this:
mkdir repo && cd repo
git init
echo foo >foo
git add .
git commit -m initial
rm foo
echo bar >bar
git add .
git commit -a
'bar' is scheduled for addition, and 'foo' is scheduled for deletion.
Have you perhaps removed a file, but it's still in the working
directory, and so picked up by your git-add? Can you give us a test
case?
> What am I overlooking? This should be simple, shouldn't it?
Yes, it should. :)
-Peff
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Johannes Schindelin @ 2007-06-13 18:34 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <200706132017.31379.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 13 Jun 2007, Josef Weidendorfer wrote:
> On Wednesday 13 June 2007, Johannes Schindelin wrote:
> > So, I should have realized earlier that "git-log -z" _without_ anything in
> > the way of "-p", "--stat" or friends does not make sense at all.
>
> But it does make sense: it separates commits using '\0'.
Indeed, I missed that. Of course, you could do something as simple as
this, although it looks really hacky to me:
diff --git a/revision.c b/revision.c
index b12c25e..1f4590b 100644
--- a/revision.c
+++ b/revision.c
@@ -1180,7 +1180,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
if (opts > 0) {
- revs->diff = 1;
+ if (strcmp(argv[i], "-z"))
+ revs->diff = 1;
i += opts - 1;
continue;
}
Ciao,
Dscho
^ permalink raw reply related
* Re: pull into dirty working tree
From: Johannes Schindelin @ 2007-06-13 18:30 UTC (permalink / raw)
To: Bill Lear; +Cc: Michael Dressel, git
In-Reply-To: <18032.13176.649702.276044@lisa.zopyra.com>
Hi,
On Wed, 13 Jun 2007, Bill Lear wrote:
> Not completely: they don't want to commit, as this will then "pollute"
> the history in their working repository (which is just temporarily
> being used to play with a new feature, idea, bug fix, optimization,
> etc.). This pollution with a handful of garbage would then have to be
> undone were they to say "ok, that's really not a good idea". If a
> pull into a dirty tree were possible, that last step could be just a
> simple reset, or continuing to explore with the code, etc.
Notice that I am _not_ saying that CVS is bad. I am saying that their
workflow is likely bad (and yes, they should change that workflow, since
they now _can_).
Two things do they risk happily, which they should not do:
- they test their new feature against different references. For example,
it might well be that they tested cases A, B, and C before pull, and D,
E and F after that. It is really easy to get lost in what you have, and
what not. Now, guess what. Merges are known to break things sometimes.
Even the best merge algorithm. Now your developers say "we tested it,
and the merge broke it, it's not our fault". But it is.
- That new feature will have to be committed at some stage. Either your
devs commit at the end, which makes it a monster commit, which is bad.
Or they are _already_ using the suggested workflow "commit && pull",
which makes your whole complaint moot.
Ciao,
Dscho
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Robin Rosenberg @ 2007-06-13 18:30 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <A30E217A-084E-4019-949F-5918EAA6368E@mimvista.com>
onsdag 13 juni 2007 skrev David Watson:
> I've got a problem, or maybe annoyance is more the proper term, that
> I haven't seen solved by any SCM system (at least not to my
> knowledge). Basically, I may make some changes, e.g. to a Makefile or
> somesuch, that I want to ignore when looking at what's changed from
> the repository. The only problem is, the file I've modified is
> already under version control, so .gitignore doesn't do anything.
>
> Now, I can commit it, so it will stop bugging me, but then when I
> push out it will include that change, unless I back it out. This is a
> change that I don't want propagated anywhere else, because it's
> specific to my machine or development sandbox.
>
> Is there any way to do this? I'd really love to use git-commit -a in
> this situation, and I could hack up a script to undo my change, run
> git-commit -a, and reapply the change, but makes me a bit squirmy. If
> I could put something in a .git config file to say "commit 237ab
> should not be propagated under any circumstances", that would be
> fantastic.
git update-index --assume-unchanged <path>
Then commit -a like you are used to.
-- robin
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Josef Weidendorfer @ 2007-06-13 18:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marco Costalba, Junio C Hamano, Shawn O. Pearce, Linus Torvalds,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706131804080.4059@racer.site>
On Wednesday 13 June 2007, Johannes Schindelin wrote:
> So, I should have realized earlier that "git-log -z" _without_ anything in
> the way of "-p", "--stat" or friends does not make sense at all.
But it does make sense: it separates commits using '\0'.
Josef
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 18:12 UTC (permalink / raw)
To: Michael Dressel; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706131916270.5241@castor.milkiway.cos>
On Wednesday, June 13, 2007 at 19:31:50 (+0200) Michael Dressel writes:
>Hi,
>
>but even if they just play with the code. Why not always commit?
>As long as they don't push nobody else will be affected.
>
>Even if you play with the code it's useful to go back to earlier
>versions. Why would you not want to benefit from this possibility?
>
>So this would really only be two commands the commit and the pull command.
>
>I hope I didn't miss your point completely.
Not completely: they don't want to commit, as this will then "pollute"
the history in their working repository (which is just temporarily
being used to play with a new feature, idea, bug fix, optimization,
etc.). This pollution with a handful of garbage would then have to be
undone were they to say "ok, that's really not a good idea". If a
pull into a dirty tree were possible, that last step could be just a
simple reset, or continuing to explore with the code, etc.
Their benchmark is CVS: CVS lets them do this easily (and yes, I
understand that CVS sucks compared to git, so don't even start), and
so even if they have to have 2 commands to do what they did in CVS
with 1, they complain. My job is to either justify what git does to
them to shut them up, or to speak to the git community to see if their
desires are remotely rational.
It seems to me, based on several posts here, particularly Junio's,
that they are being remotely rational and it might be a reasonable
addition to git to be able to say "git pull --dirty" or whatever...
Bill
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: David Watson @ 2007-06-13 18:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.99.0706131349430.1697@xanadu.home>
It appears that only applies to untracked files. I am specifically
interested in ignoring changes to files that are already tracked,
unless I'm misunderstanding what you're suggesting. I just built the
most recent git from repo.or.cz/git, and did the following:
* edit the file I want to "ignore"
git-status shows this file as modified
* edit .git/config, set core.excludesfile to myexcludes, containing
the name of the file I want
* git add -u
* git-status
shows the file I edited as ready to be committed.
Dave Watson
On Jun 13, 2007, at 1:54 PM, Nicolas Pitre wrote:
> On Wed, 13 Jun 2007, David Watson wrote:
>
>> Because git-commit -a is nice to use, especially if I really want
>> to check in
>> all the files, *except a particular set that is always the same*.
>> Having to
>> specify the files every time gets old pretty quick.
>>
>> If I could do this:
>>
>> $ git-commit -a --exclude=somefile
>>
>> that would be very useful. Or even, if I could set a file in
>> my .git folder
>> that would be an exclude list, then I could run something like
>>
>> $ git-commit -a --use-excludes
>>
>> I suppose the answer is to create the patch myself.
>
> Well, before that I'd suggest you have a look at the git-add man page,
> especially the -u flag and the core.excludesfile config option.
>
>
> Nicolas
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: David Watson @ 2007-06-13 17:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.99.0706131318390.21061@xanadu.home>
Because git-commit -a is nice to use, especially if I really want to
check in all the files, *except a particular set that is always the
same*. Having to specify the files every time gets old pretty quick.
If I could do this:
$ git-commit -a --exclude=somefile
that would be very useful. Or even, if I could set a file in my .git
folder that would be an exclude list, then I could run something like
$ git-commit -a --use-excludes
I suppose the answer is to create the patch myself. Seems like this
would also be a useful feature for git-status, git-ls-files (when
used with --modified), and probably some others that I haven't
thought of yet.
-Dave Watson
On Jun 13, 2007, at 1:21 PM, Nicolas Pitre wrote:
> On Wed, 13 Jun 2007, David Watson wrote:
>
>> I've got a problem, or maybe annoyance is more the proper term,
>> that I haven't
>> seen solved by any SCM system (at least not to my knowledge).
>> Basically, I may
>> make some changes, e.g. to a Makefile or somesuch, that I want to
>> ignore when
>> looking at what's changed from the repository. The only problem
>> is, the file
>> I've modified is already under version control, so .gitignore
>> doesn't do
>> anything.
>>
>> Now, I can commit it, so it will stop bugging me, but then when I
>> push out it
>> will include that change, unless I back it out. This is a change
>> that I don't
>> want propagated anywhere else, because it's specific to my machine or
>> development sandbox.
>>
>> Is there any way to do this? I'd really love to use git-commit -a
>> in this
>> situation, and I could hack up a script to undo my change, run git-
>> commit -a,
>> and reapply the change, but makes me a bit squirmy. If I could put
>> something
>> in a .git config file to say "commit 237ab should not be
>> propagated under any
>> circumstances", that would be fantastic.
>
> Why don't you just use git-commit _without_ -a ?
>
> The whole purpose behind not specifying -a with git-commit is exactly
> for your usage example.
>
>
> Nicolas
^ permalink raw reply
* Re: Any way to ignore a change to a tracked file when committing/merging?
From: Nicolas Pitre @ 2007-06-13 17:54 UTC (permalink / raw)
To: David Watson; +Cc: git
In-Reply-To: <477C424C-009F-46BF-85D4-A0D777FE3CEC@mimvista.com>
On Wed, 13 Jun 2007, David Watson wrote:
> Because git-commit -a is nice to use, especially if I really want to check in
> all the files, *except a particular set that is always the same*. Having to
> specify the files every time gets old pretty quick.
>
> If I could do this:
>
> $ git-commit -a --exclude=somefile
>
> that would be very useful. Or even, if I could set a file in my .git folder
> that would be an exclude list, then I could run something like
>
> $ git-commit -a --use-excludes
>
> I suppose the answer is to create the patch myself.
Well, before that I'd suggest you have a look at the git-add man page,
especially the -u flag and the core.excludesfile config option.
Nicolas
^ 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