* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 1:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <119540238994-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Often you want to push only the current branch to the default
> remote. This was awkward to do in the past.
While I think --current is a handy shorthand to have, I do not
think the above description is correct.
Wouldn't your earlier patch have allowed the configuration setting:
[remote "$there"]
push = HEAD
[branch "$current"]
remote = $there
to work very well already?
I do not think it is "Often you want" that makes it awkward.
Instead, the awkward case is if you do the "only the current"
push NOT often enough. If it is often enough, you set the
configuration once and the awkwardness is behind you.
If however it is not often enough, you cannot afford to have the
configuration above, because that would force you to tell from
the command line which branches, not just the current one, to
push, and that is inconvenient because it is not rare enough.
Together with your [PATCH 1/2], I like the general direction
these patckes are taking us, but it feels a bit too hasty. I
personally am not convinced that switching to --current for
everybody is a good move.
> ...
> Maybe in two years (that's twice an eternity in git time scales):
>
> 4) make "git push --current" the default.
If these, both the uncertainly expressed by "Maybe" and "twice
an eternity" are true, which they are, the new warning in the
current patch are inappropriate. Many people's settings depend
on a working "push the matching refs" behaviour, and we need a
very good excuse to annoy the existing happy users with such a
warning.
Remember, how much vocal the dissenters might have been on the
list in the recent discussions, we need to consider the needs of
the silent majority that has been content with the current
behaviour for a long time.
The "warning" to annoy them may be a way to get their attention
and get them involved in a discussion to decide what the default
should be. But changing the default without giving the people
who do not like the _new_ default a way to avoid inconvenience
of always typing --matching or --current is not nice. And
honestly, I do not think there is one single default that is
good for everybody.
We should be doing better.
A smoother transition route would be:
- Keep "matching" the built-in default for now;
- Take your patches (but drop "warning" bits at this point) to
introduce 'matching' and 'current' behaviours, and a way to
override the built-in default from the command line;
- Introduce a configuration 'push.defaultRefs' ('matching' or
'current') to override that built-in default, so people who
prefer 'current' can override the built-in default, without
having to type --current every time.
After all that happens, we can start discussing what the
built-in default should be. When it is changed after the
discussion concludes (which may never happen), people who want
to keep 'matching' behaviour would have had the configuration
mechanism to override that built-in default for some time during
the discussion period. So the beginning of that discussion
period is when we should start talking about "We might change
the default soon; set the configuration to your liking if you do
not want to get affected" in the warning.
Then after that, we may or may not decide to change the default.
Even if we end up not changing the default, 'current' people
will then have a way (push.matching = false) to tailor their git
for their liking, so everybody wins.
> DESCRIPTION
> @@ -63,6 +63,12 @@ the remote repository.
> Instead of naming each ref to push, specifies that all
> refs under `$GIT_DIR/refs/heads/` be pushed.
>
> +\--matching::
> + Instead of naming each ref to push, specifies that matching
> + refs under `$GIT_DIR/refs/heads/` be pushed. Matching means
> + the branch exists locally and at the remote under the same name.
> + Currently, this is the default. But this will change in the future.
For the above reason, "But this will..." is a bit premature.
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: J. Bruce Fields @ 2007-11-19 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Smith, git
In-Reply-To: <7vtznqrlrb.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 13, 2007 at 11:25:12AM -0800, Junio C Hamano wrote:
> Michael Smith <msmith@cbnco.com> writes:
>
> > +You can fix situations like these by doing a merge that isn't really a
> > +merge, using the "ours" merge strategy. Look through the history on the
> > +third-party branch and try to find the exact commit that matches the
> > +last snapshot you imported. Often there's a tag close to the commit, or
> > +on the commit, if you're lucky--but don't trust it blindly; check the
> > +diffs. Check out your local branch and tell Git about the relationship:
> > +
> > +------------------------------------------------
> > +$ git remote add upstreamgit git://upstream.org/project.git
> > +$ git fetch upstreamgit
> > +$ git tag
> > +v1.0
> > +v1.1
> > +v1.2
> > +$ git checkout master
> > +$ git merge --strategy=ours \
> > + -m "Tie old v1.1 into our history by merging with strategy=ours." \
> > + v1.1
> > +------------------------------------------------
> > +
> > +You'll see the branches merge together in `gitk --all` or `git
> > +show-branch master upstreamgit/master`. Now you'll be able to merge any
> > +changes from the remote branch since v1.1 with `git merge
> > +upstreamgit/master`.
> > +
>
> This would work only when your 'master' happens to be at v1.1
> (and identical to it) isn't it? Which means that as an example
> it will be of very limited scope.
>
> People would want to know "But my 'master' is _not_ at v1.1 but
> is _based_ on v1.1. How would I handle that case?" and the
> above does not answer that question.
>
> Even worse, most people are probably not careful enough to ask
> the above question, but just say "Heh, my 'master' is based on
> v1.1, so I'll blindly follow that example to bind the histories
> together".
>
> I did not find any technical problem in the other parts of your
> description, but I did not read the resulting document from
> cover to cover, so I do not know if your change fits in the
> entire organization of the document very well.
A mention of git-cherry or --left-right someplace might make sense,
maybe in chapter 2 somewhere (maybe in "Browsing revisions"?), but it
might also be useful to discuss this kind of stuff in the "sharing
development with others" section. (E.g. at the end of "Submitting
patches to a project", it might help to have some hints about how to
recognize when they've been accepted and what to do then.)
The trick of using a merge (possibly with -s ours) to tie together two
independent paths to the same state is more generally useful. (I've
been using it sometimes to keep track of the revision history of a patch
series, for example). I'm not sure where that should go.
I like the tips on importing snapshots or other history. I've long been
wanting an "interoperating with other SCM's" section (rough beginnings
at git://linux-nfs.org/~bfields/git.git docwork-foreign-scms), and maybe
some of this would fit here.
All of these things seem more generally useful even to an audience that
hasn't worked with CVS vendor branches before, so I'd prefer
explanations that didn't reference the CVS stuff. (With CVS-specific
stuff moved somewhere else, maybe to cvs-migration.txt.)
--b.
^ permalink raw reply
* git-daemon fatal error running with monit
From: Glenn Rempe @ 2007-11-19 1:09 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
hello git masters.
I am having a problem running git-daemon from within 'monit' (http://www.tildeslash.com/monit/index.php
). I can run git-daemon every time without error if I manually issue
the command to run it in a terminal. However, if I have monit execute
the exact same command I get an error from git-daemon in syslog and
the client request fails every time. Running on Ubuntu 7.04. Can you
take a look?
Unfortunately the error info in the logs is minimal. All details of
my config and the error can be found here in this pastie: http://git.pastebin.com/m20fab0a9
Thanks in advance.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2411 bytes --]
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: J. Bruce Fields @ 2007-11-19 0:48 UTC (permalink / raw)
To: Michael Smith; +Cc: git, gitster
In-Reply-To: <11949569992214-git-send-email-msmith@cbnco.com>
On Tue, Nov 13, 2007 at 07:29:59AM -0500, Michael Smith wrote:
> +You can view all your local changes--b, d, h, and i--with the
> +gitlink:git-diff[1] command:
> +
> +------------------------------------------
> +$ git diff origin/master...master
> +------------------------------------------
> +
> +The three-dot `\...` tells gitlink:git-diff[1] to show the changes on the
> +master branch since the last common ancestor with origin/master. (If you
> +used two dots instead of three, you'd see the entire patch to go from
> +origin/master to master, including reversing commits "f" and "g".)
I missed the "..." thing when on my first attempt at the manual. It
really should be mentioned in the "Generating diffs" section; I've added
the following to my
git://linux-nfs.org/~bfields/git.git maint
--b.
>From 5b98d9bca16e19710380d2d03f704de9eb98621d Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 18 Nov 2007 19:18:27 -0500
Subject: [PATCH] user-manual: mention "..." in "Generating diffs", etc.
We should mention the use of the "..." syntax for git-diff here. The
note about the difference between diff and the combined output of
git-format-patch then no longer fits so well, so remove it. Add a
reference to the git-format-patch[1] manpage.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e399685..c027353 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -658,16 +658,23 @@ gitlink:git-diff[1]:
$ git diff master..test
-------------------------------------------------
-Sometimes what you want instead is a set of patches:
+That will produce the diff between the tips of the two branches. If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+-------------------------------------------------
+$ git diff master...test
+-------------------------------------------------
+
+Sometimes what you want instead is a set of patches; for this you can
+use gitlink:git-format-patch[1]:
-------------------------------------------------
$ git format-patch master..test
-------------------------------------------------
will generate a file with a patch for each commit reachable from test
-but not from master. Note that if master also has commits which are
-not reachable from test, then the combined result of these patches
-will not be the same as the diff produced by the git-diff example.
+but not from master.
[[viewing-old-file-versions]]
Viewing old file versions
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Junio C Hamano @ 2007-11-19 0:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, git
In-Reply-To: <200711190005.49990.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> So the question is: how to unpack branches, and how to prevent
> branches from being packed by "git-gc"?
I am afraid that is a wrong question. How long have we had the
packed-refs anyway?
The question is "How to get the list of refs from a Porcelain if
it wants to be compatible with GIT v1.4.4-rc1 (Nov 7, 2006) and
later?", and the answer is for-each-ref.
Having said that, you could explode it by hand like this:
git for-each-ref --format='%(objectname) %(refname)' refs/heads |
while read sha1 refname
do
test -f "$GIT_DIR/$refname" ||
git update-ref "$refname" "$sha1"
done
^ permalink raw reply
* Re: [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..."
From: J. Bruce Fields @ 2007-11-18 23:18 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Benoit Sigoure, Andreas Ericsson, Johannes Sixt,
git
In-Reply-To: <C5A2CF54-7055-461A-86B6-5A68489DA2C3@zib.de>
On Sun, Nov 18, 2007 at 10:47:24AM +0100, Steffen Prohaska wrote:
>
> On Nov 18, 2007, at 4:59 AM, J. Bruce Fields wrote:
>
>> On Sat, Nov 10, 2007 at 02:49:54PM +0100, Steffen Prohaska wrote:
>>> +[[bisect-merges]]
>>> +Why bisecting merge commits can be harder than bisecting linear history
>>> +-----------------------------------------------------------------------
>>> +
>>> +This section discusses how gitlink:git-bisect[1] plays
>>> +with differently shaped histories. The text is based upon
>>> +an email by Junio C. Hamano to the git mailing list
>>> +(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
>>> +It was adapted for the user manual.
>>
>> This is not the only text that's been taken from someplace else, but if
>> we attributed them all in the text it would get a little cumbersome....
>> I think the place for that kind of thing is in the commit message, but
>> if we really think we need to include it in the main text, we could add
>> a separate "'acknowledgements" section.
>
> ack for this change.
>
> And a general comment: I had two purposes in\x05 mind when I
> added this paragraph
> 1) Attribution;
> 2) Giving a reference to the original discussion. If someone disagrees,
> or has further questions, the original discussion on the mailing
> list could be useful.
>
> I believe the commit message is sufficient for attribution.
> I don't think we need more. Maybe if the manual goes to print
> we need to reconsider. But who know if this ever will happen.
>
> However, adding a References section with links to other
> resources could be a useful thing. Such resources could give
> additional information, without sacrificing the conciseness of
> the manual. An example are links to the original discussion on
> the list. Often they contain more details, which may sometimes
> be useful.
>
> Does asciidoc provide a mechanism for this? Something like
> \cite{} in LaTeX.
We could add a "for more details, see link:..." at the end, though I
don't think it's necessary in this case.
>>> +Using gitlink:git-bisect[1] on a history with merges can be
>>> +challenging. Bisecting through merges is not a technical
>>> +problem. The real problem is what to do when the culprit turns
>>> +out to be a merge commit. How to spot what really is wrong, and
>>> +figure out how to fix it. The problem is not for the tool but
>>> +for the human, and it is real.
>>
>> I think we can pare that down a little.
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +The gitlink:git-bisect[1] commands deals fine with history that includes
> +merge commits. However, when the final commit that ends on is a merge
> +commit, the user may need to work harder than usual to figure out
> +exactly what the problem was.
>
> If you don't take the text below, first line: s/commands/command/
Whoops, thanks!
>
> I'd reverse the order of the sentences. The section is about
> the difficulty, not about praising git-bisect. How about
>
> When the final commit that a bisect ends on is a merge commit,
> the user may need to work harder than usual to figure out
> exactly what the problem was. This is not a technical
> problem. In principle, the gitlink:git-bisect[1] command
> deals fine with history that includes merge commits.
>
> It's your call. I'm also fine with your version.
OK; I see your point but I think I'll stick with my version (with
another minor fix or two)--the order seems more natural: first dismiss
the obvious objection to the title, then introduce the problem that
leads to the following discussion.
>>> +
>>> +Imagine this history:
>>> +
>>> +................................................
>>> + ---Z---o---X---...---o---A---C---D
>>> + \ /
>>> + o---o---Y---...---o---B
>>> +................................................
>>> +
>>> +Suppose that on the upper development line, the meaning of one
>>> +of the functions that existed at Z was changed at commit X. The
>>> +commits from Z leading to A change both the function's
>>> +implementation and all calling sites that existed at Z, as well
>>> +as new calling sites they add, to be consistent. There is no
>>> +bug at A.
>>> +
>>> +Suppose that in the meantime the lower development line somebody
>>> +added a new calling site for that function at commit Y. The
>>> +commits from Z leading to B all assume the old semantics of that
>>> +function and the callers and the callee are consistent with each
>>> +other. There is no bug at B, either.
>>> +
>>> +Suppose further that the two development lines were merged at C
>>> +and there was no textual conflict with this three way merge.
>>> +The result merged cleanly.
>>> +
>>> +Now, during bisect you find that the merge C is broken. You
>>> +started to bisect, because you found D is bad and you know Z was
>>> +good. The breakage is understandable, as at C, the new calling
>>> +site of the function added by the lower branch is not converted
>>> +to the new semantics, while all the other calling sites that
>>> +already existed at Z would have been converted by the merge. The
>>> +new calling site has semantic adjustment needed, but you do not
>>> +know that yet.
>>> +
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +Nevertheless, the code at C is broken, because the callers added
> +on the lower line of development have not been converted to the new
> +semantics introduced on the upper line of development. So if all
> +you know is that D was bad, Z was good, and that a
>
> s/a//? I'm not sure; you are the native speaker ;)
I agree, it's better without the "a", thanks.
>
> +gitlink:git-bisect[1] identified C as the culprit, how will you
> +figure out that the problem was due to this change in semantics?
>
>
>
>>> +You need to find out what is the cause of the breakage by looking
>>> +at the merge commit C and the history leading to it. How would
>>> +you do that?
>>> +
>>> +Both "git diff A C" and "git diff B C" would be an enormous patch.
>>> +Each of them essentially shows the whole change on each branch
>>> +since they diverged. The developers may have well behaved to
>>> +create good commits that follow the "commit small, commit often,
>>> +commit well contained units" mantra, and each individual commit
>>> +leading from Z to A and from Z to B may be easy to review and
>>> +understand, but looking at these small and easily reviewable
>>> +steps alone would not let you spot the breakage. You need to
>>> +have a global picture of what the upper branch did (and
>>> +among many, one of them is to change the semantics of that
>>> +particular function) and look first at the huge "diff A C"
>>> +(which shows the change the lower branch introduces), and see if
>>> +that huge change is consistent with what have been done between
>>> +Z and A.
>>> +
>
> From your 7df716bec6bf6e3dafe4c36a6313a4346de2585a
>
> +When the result of a git-bisect is a non-merge commit, you should
> +normally be able to discover the problem be examining just that commit.
>
> s/be examining/by examining/
Oops, thanks.
>> I'd say "partly for this reason", as I don't think this is the only
>> reason people do that.
>>
>> I've done the above revisions and a few others and pushed them to
>>
>> git://linux-nfs.org/~bfields/git.git maint
>>
>> I'll take another look in the morning.
>
> Besides the minor fixes above, ack from me. We already spend
> a lot of time on this section. It improved compared to the
> first version and I think it's now ready for the manual.
OK, thanks for your patience! This plus an unrelated trivial fix are
available for Junio to pull from
git://linux-nfs.org/~bfields/git.git maint
(Full history also available from the maint-history branch).
--b.
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.6
From: Junio C Hamano @ 2007-11-18 23:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vpryugb7i.fsf@gitster.siamese.dyndns.org>
The latest maintenance release GIT 1.5.3.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.6.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.6.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.6-1.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.5.3.6 Release Notes
==========================
Fixes since v1.5.3.5
--------------------
* git-cvsexportcommit handles root commits better.
* git-svn dcommit used to clobber when sending a series of
patches.
* git-svn dcommit failed after attempting to rebase when
started with a dirty index; now it stops upfront.
* git-grep sometimes refused to work when your index was
unmerged.
* "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
* git-hash-object did not honor configuration variables, such as
core.compression.
* git-index-pack choked on a huge pack on 32-bit machines, even when
large file offsets are supported.
* atom feeds from git-web said "10" for the month of November.
* a memory leak in commit walker was plugged.
* When git-send-email inserted the original author's From:
address in body, it did not mark the message with
Content-type: as needed.
* git-revert and git-cherry-pick incorrectly refused to start
when the work tree was dirty.
* git-clean did not honor core.excludesfile configuration.
* git-add mishandled ".gitignore" files when applying them to
subdirectories.
* While importing a too branchy history, git-fastimport did not
honor delta depth limit properly.
* Support for zlib implementations that lack ZLIB_VERNUM and definition
of deflateBound() has been added.
* Quite a lot of documentation clarifications.
----------------------------------------------------------------
Changes since v1.5.3.5 are as follows:
Alex Riesen (1):
stop t1400 hiding errors in tests
Ask Bjørn Hansen (1):
When exec() fails include the failing command in the error message
Benoit Sigoure (2):
git-send-email: Change the prompt for the subject of the initial message.
git-svn: prevent dcommitting if the index is dirty.
Brad King (1):
cvsexportcommit: fix for commits that do not have parents
Christian Couder (1):
for-each-ref: fix off by one read.
David D Kilzer (2):
RelNotes-1.5.3.5: fix typo
RelNotes-1.5.3.5: fix another typo
David Symonds (1):
Improve accuracy of check for presence of deflateBound.
Eric Wong (2):
git-svn: fix dcommit clobbering when committing a series of diffs
git-svn: t9114: verify merge commit message in test
Gerrit Pape (4):
git-diff.txt: add section "output format" describing the diff formats
git-cvsimport: really convert underscores in branch names to dots with -u
git-daemon: fix remote port number in log entry
git-mailsplit: with maildirs not only process cur/, but also new/
Jakub Narebski (1):
gitweb: Update config file example for snapshot feature in gitweb/INSTALL
Jeff King (2):
git-branch: remove mention of non-existent '-b' option
git-send-email: add charset header if we add encoded 'From'
Jing Xue (1):
replace reference to git-rm with git-reset in git-commit doc
Johannes Schindelin (1):
Add Documentation/CodingGuidelines
Jonas Fonseca (3):
Remove escaping of '|' in manpage option sections
instaweb: Minor cleanups and fixes for potential problems
Documentation: Fix man page breakage with DocBook XSL v1.72
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Junio C Hamano (12):
grep with unmerged index
refresh_index_quietly(): express "optional" nature of index writing better
Makefile: add missing dependency on wt-status.h
Start preparing for 1.5.3.6
t/t3404: fix test for a bogus todo file.
revert/cherry-pick: allow starting from dirty work tree.
git-clean: honor core.excludesfile
core.excludesfile clean-up
Fix per-directory exclude handing for "git add"
Update draft release notes for 1.5.3.6
grep -An -Bm: fix invocation of external grep command
GIT 1.5.3.6
Kristian Høgsberg (1):
Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.
Marco Costalba (1):
Remove a couple of duplicated include
Mike Hommey (1):
Delay pager setup in git blame
Nicolas Pitre (3):
print warning/error/fatal messages in one shot
git-hash-object should honor config variables
fix index-pack with packs >4GB containing deltas on 32-bit machines
Ralf Wildenhues (3):
git-clone.txt: Improve --depth description.
Avoid a few unportable, needlessly nested "...`...".
Fix sed string regex escaping in module_name.
Sergei Organov (6):
git-filter-branch.txt: fix a typo.
git-format-patch.txt: fix explanation of an example.
Documentation: quote commit messages consistently.
SubmittingPatches: improve the 'Patch:' section of the checklist
core-tutorial.txt: Fix argument mistake in an example.
git-remote.txt: fix typo
Shawn O. Pearce (2):
Fix memory leak in traverse_commit_list
Don't allow fast-import tree delta chains to exceed maximum depth
Vincent Zanotti (1):
gitweb: correct month in date display for atom feeds
Wincent Colaiuta (2):
Grammar fixes for gitattributes documentation
Fix t9101 test failure caused by Subversion "auto-props"
^ permalink raw reply
* StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Jakub Narebski @ 2007-11-18 23:05 UTC (permalink / raw)
To: Catalin Marinas, git
I use Stacked GIT 0.13 with git 1.5.3.5 (and Python 2.4.3).
StGIT does recognize old StGIT branches (and converts them),
but "stg branch -l" list only one branch. I guess that is
cause by the fact that all the rest of branches are packed.
So the question is: how to unpack branches, and how to prevent
branches from being packed by "git-gc"?
Another StGIT question: how to check if given branch is controlled
by StGIT (needed for my bash prompt)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: preserving mtime
From: David Brown @ 2007-11-18 21:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike Hommey, Wayne Davison, Andreas Ericsson, git
In-Reply-To: <46a038f90711181236o1acd00d4id9c5aeffd3065b80@mail.gmail.com>
On Mon, Nov 19, 2007 at 09:36:52AM +1300, Martin Langhoff wrote:
>Hmmm. After a bit of googling I've found conflicting descriptions of
>the mtime/ctime semantics (I thought - for 10 years now - that ctime
>was "creation time", it is "changed time"). Some people think that
>anything that updates mtime also updates ctime, and others say the
>opposite.
One of them is wrong. All modifications to the file change the ctime.
Some modifications change the mtime. There is also a call to change the
mtime (which will touch the ctime). It's been this way for a long time.
I think most of the confusion comes from the 'c' in ctime.
It doesn't help that the Posix spec is so hard to read on this. Basically,
you have to look up every command that might modify a file to figure out
which time changes it is supposed to modify.
>Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and
>http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the
>content, and ctime about metadata (owner, permissions, moved inode,
>etc). Changes in content "touch" mtime + ctime.
>
>With that in mind, I think it makes sense for things like make and
>amanda to read mtime as referring to a real change of that concrete
>file. The abstract notion of the file having changed in the big DSCM
>in the sky is useful, but putting that data in mtime messes things up.
Backup software should _never_ look at the mtime (other than to save it).
Both GNU tar and dump use the ctime field exclusively for incremental
purposes.
Think about this:
wget .../linux-2.4.tar.gz
tar -xzf linux-2.4.tar.gz
I've just expanded lots of files on my machine. Tar is going to set the
mtime to the date they were at when the tarball was made, which was
probably several years ago. It is crucial, though, that any backup
software I run still back these files up, since they are newly added.
There are backup programs that use mtime, but they are just broken, plain
and simple.
>> However, it will make 'make' very confusing, since it uses the mtime to
>> determine if files are out of date. If moving to an older version of a
>> file causes the file to become older, make won't recompile. This is
>> arguably a defect in make, but that is how it works.
>
>It's not a bug in make. mtime has a definite meaning, and make is
>using that meaning. Same with amanda.
It is very much a bug (well, a feature) in make. But the whole date
comparison model of make is completely wrong. It should rebuild a file if
it has changed, not if it is newer. Most make replacements do something
more intelligent (often similar to the index cache git uses).
I haven't used Amanda for a while, but it at least used to do the right
thing (using ctime). They might have had to break things to support FAT,
but I would guess it still works on a real filesystem.
David
^ permalink raw reply
* Re: preserving mtime
From: Martin Langhoff @ 2007-11-18 20:36 UTC (permalink / raw)
To: Martin Langhoff, Mike Hommey, Wayne Davison, Andreas Ericsson,
git
In-Reply-To: <20071118184724.GA494@old.davidb.org>
On Nov 19, 2007 7:47 AM, David Brown <git@davidb.org> wrote:
> On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:
>
> >I do hope anyone doing those things is _very_ aware that the mtime
> >metadata has a specific meaning -- when did this specific file in this
> >filesystem last change -- and is used by many tools in that sense. You
> >are trying to use it for something else. Lots of things will break.
> >
> >Like incremental backups, for example.
>
> 'mtime' does _not_ have the specific meaning of 'when did this specific
> file last change'. That is the 'ctime' field. 'mtime' is also updated
> when a file is modified, but can be changed by the user. Many utilities
> restore mtime to older values, including tar.
Hmmm. After a bit of googling I've found conflicting descriptions of
the mtime/ctime semantics (I thought - for 10 years now - that ctime
was "creation time", it is "changed time"). Some people think that
anything that updates mtime also updates ctime, and others say the
opposite.
Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and
http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the
content, and ctime about metadata (owner, permissions, moved inode,
etc). Changes in content "touch" mtime + ctime.
With that in mind, I think it makes sense for things like make and
amanda to read mtime as referring to a real change of that concrete
file. The abstract notion of the file having changed in the big DSCM
in the sky is useful, but putting that data in mtime messes things up.
> However, it will make 'make' very confusing, since it uses the mtime to
> determine if files are out of date. If moving to an older version of a
> file causes the file to become older, make won't recompile. This is
> arguably a defect in make, but that is how it works.
It's not a bug in make. mtime has a definite meaning, and make is
using that meaning. Same with amanda.
cheers,
m
^ permalink raw reply
* [PATCH] builtin-commit: run commit-msg hook with correct message file
From: Junio C Hamano @ 2007-11-18 20:30 UTC (permalink / raw)
To: git; +Cc: krh, Johannes.Schindelin
In-Reply-To: <7vejenuy4i.fsf@gitster.siamese.dyndns.org>
It should run with $GIT_DIR/COMMIT_EDITMSG, not just COMMIT_EDITMSG.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Other things I noticed that are still broken:
- "git commit -v" does not give you the diff in the message
template for your final review;
- message_is_empty() is bogus. It does run stripspace() but
does not strip out the diff "git commit -v" would produce
before doing its comparison;
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 058cd32..439fcc2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -753,7 +753,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
rollback_index_files();
die("could not read commit message\n");
}
- if (run_hook(index_file, "commit-msg", commit_editmsg)) {
+ if (run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
rollback_index_files();
exit(1);
}
--
1.5.3.5.1815.g9445b
^ permalink raw reply related
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Junio C Hamano @ 2007-11-18 20:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711182101.53936.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sunday 18 November 2007 19:39, Junio C Hamano wrote:
> ...
>> I would imagine that would work as long as it can be controlled
>> when all the involved repositories are repacked and pruned, such
>> as on repo.or.cz case (but on the other hand it is not really
>> controlled well there and that is the reason you wrote the
>> message X-<).
>
> Well, I think in many situations pack and prune can be controlled. To be
> precise, if alternates are used pack and prune *must* be controlled.
> Currently, the control is very simple: "don't prune" (and I don't recall ATM
> what you must not do when you repack).
>
> Anyway, judging from the responses so far it seems that people can live
> with "don't prune" (or not using alternates) ;-)
Because my point was not "don't prune is good enough", I think
you are judging from too small number of responses (in fact,
zero).
My point was that even the existing setup that is well known to
the public (i.e. repo.or.cz) does not seem to be controlled, and
adding a nicer mechanism (e.g. I do not think there currently is
a canned way to prepare a pack that contains only unreachable
objects --- you need to script it anew) for a better control may
not help the situation much, unless it is actually used.
^ permalink raw reply
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Johannes Sixt @ 2007-11-18 20:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3av3wg7h.fsf@gitster.siamese.dyndns.org>
On Sunday 18 November 2007 19:39, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > Then the strategy of garbage collection can be arranged in the following
> > way:
> >
> > - Repack by starting at the "most complete" repo and work towards the
> > "most borrowing" ones. During this phase "attic" packs are created.
> > Borrowing repos get a chance to salvage objects before the alternates
> > prune them away.
> >
> > - Prune by starting at the "most borrowing" repo and work towards the
> > "most complete" ones. During this phase the "attic" packs are cleaned up.
> >
> > What do you think? Is this a way for a solution?
>
> I would imagine that would work as long as it can be controlled
> when all the involved repositories are repacked and pruned, such
> as on repo.or.cz case (but on the other hand it is not really
> controlled well there and that is the reason you wrote the
> message X-<).
Well, I think in many situations pack and prune can be controlled. To be
precise, if alternates are used pack and prune *must* be controlled.
Currently, the control is very simple: "don't prune" (and I don't recall ATM
what you must not do when you repack).
Anyway, judging from the responses so far it seems that people can live
with "don't prune" (or not using alternates) ;-) Repositories getting broken
this way isn't exactly my itch, either, so... I spelled out a possible
solution if someone wants to pick up the topic.
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-commit: Fix git-commit honoring status.color
From: Junio C Hamano @ 2007-11-18 19:55 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195405834-1469-1-git-send-email-pkufranky@gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> status.color shouldn't be honored when committing since the run-status
> output is fed to the editor.
> ---
> builtin-commit.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 8db74ed..4396e7d 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -45,6 +45,7 @@ static int quiet, verbose, untracked_files, no_verify;
> static int no_edit, initial_commit, in_merge;
> const char *only_include_assumed;
> struct strbuf message;
> +extern int wt_status_use_color;
>
> static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> {
> @@ -325,6 +326,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
> if (only_include_assumed)
> fprintf(fp, "# %s\n", only_include_assumed);
>
> + wt_status_use_color = 0;
> commitable = run_status(fp, index_file, prefix);
>
> fclose(fp);
Although I admit I do not care much about the "status color", I
suspect this patch is not quite right.
When prepare_log_message() returns "no committable changes" and
we are not in merge, the calling cmd_commit() does another
run_status() to show the status of the index and the work tree
to the stdout, and at that point, we _do_ want to honor the
configuration setting you are discarding with this assignment.
---
builtin-commit.c | 5 ++++-
wt-status.h | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 4e2f4aa..058cd32 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -300,7 +300,7 @@ static const char sign_off_header[] = "Signed-off-by: ";
static int prepare_log_message(const char *index_file, const char *prefix)
{
struct stat statbuf;
- int commitable;
+ int commitable, saved_color_setting;
struct strbuf sb;
char *buffer;
FILE *fp;
@@ -383,7 +383,10 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
+ saved_color_setting = wt_status_use_color;
+ wt_status_use_color = 0;
commitable = run_status(fp, index_file, prefix);
+ wt_status_use_color = saved_color_setting;
fclose(fp);
diff --git a/wt-status.h b/wt-status.h
index f58ebcb..225fb4d 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -27,6 +27,7 @@ struct wt_status {
};
int git_status_config(const char *var, const char *value);
+int wt_status_use_color;
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
^ permalink raw reply related
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Junio C Hamano @ 2007-11-18 18:52 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195407366-1610-1-git-send-email-pkufranky@gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> When 'FILE *fp' is assigned to child_process.out and then start_command or
> run_command is run, the standard output of the child process is expected to
> be outputed to fp. However, sometimes fp is not expected to be closed since
> further IO may be still performmed on fp.
Could you clarify "However, sometimes" with a concrete codepath
that has this problem in the proposed commit log message, and
Sign-off your patch please?
^ permalink raw reply
* Re: only accessing some git repos: Am I configuring daemon wrong?
From: Junio C Hamano @ 2007-11-18 18:48 UTC (permalink / raw)
To: Henrik Vendelbo; +Cc: git
In-Reply-To: <9732aadb0711180518n26c2681aqe7f0a823012c6fe3@mail.gmail.com>
"Henrik Vendelbo" <hvendelbo.dev@googlemail.com> writes:
> I run the daemon against a base directory with all my repos.
>
> /repositories
> + /blingon
> + /config
> + /thepia
> + /config
>
> The config directories are git repositories, and the repos are made
> available with the following command:
>
> henrik-computer:~ x$ git daemon --export-all --verbose --base-path=/repositories
> [337] Connection from 192.168.9.130:56583
> [337] Extended attributes (20 bytes) exist <host=192.168.9.165>
> [337] Request upload-pack for '/blingon/all'
> [337] Disconnected
>
> For some reason when I try to pull over the git protocol to a
> different machine using clone, I get a failure telling me that there
> is 'no matching remote head'
>
> I tried specifying the actual repo directories, but that made no difference.
>
> Any ideas?
Lack of any whitelist on the command line and --export-all?
Do you see "not in whitelist" in your error log?
^ permalink raw reply
* Re: preserving mtime
From: David Brown @ 2007-11-18 18:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike Hommey, Wayne Davison, Andreas Ericsson, git
In-Reply-To: <46a038f90711180134j411bb9c9uf2476f564f9abb6@mail.gmail.com>
On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:
>I do hope anyone doing those things is _very_ aware that the mtime
>metadata has a specific meaning -- when did this specific file in this
>filesystem last change -- and is used by many tools in that sense. You
>are trying to use it for something else. Lots of things will break.
>
>Like incremental backups, for example.
'mtime' does _not_ have the specific meaning of 'when did this specific
file last change'. That is the 'ctime' field. 'mtime' is also updated
when a file is modified, but can be changed by the user. Many utilities
restore mtime to older values, including tar.
Any competent backup program would use 'ctime' for incremental backups,
unless they don't mind missing a vast majority of files on many machines.
The main thing I've seen mess up backup software is if the mtime is set
into the future.
However, it will make 'make' very confusing, since it uses the mtime to
determine if files are out of date. If moving to an older version of a
file causes the file to become older, make won't recompile. This is
arguably a defect in make, but that is how it works.
Preserving mtime definitely should not be a default.
David
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix partial-commit support
From: Junio C Hamano @ 2007-11-18 18:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6inx1m8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 3e7d281..e487bc0 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
There was another...
> +static int list_paths(struct path_list *list, const char *with_tree,
> + const char *prefix, const char **pattern)
> +{
> + struct dir_struct dir;
> + int i;
> + char *m;
> +
> + for (i = 0; pattern[i]; i++)
> + ;
> + m = xcalloc(1, i);
> +
> + memset(&dir, 0, sizeof(dir));
> + if (with_tree)
> + overlay_tree_on_cache(with_tree, prefix);
> +
> + for (i = 0; i < active_nr; i++) {
> + struct cache_entry *ce = active_cache[i];
> + if (ce->ce_flags & htons(CE_UPDATE))
> + continue;
> + if (!pathspec_match(pattern, m, ce->name, 0))
> + continue;
> + if (excluded(&dir, ce->name))
> + continue;
> + path_list_insert(ce->name, list);
> + }
This "excluded", and the whole "struct dir" business is
unneeded, as we are walking on the index and finding the set of
paths the user cares about.
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Jon Smirl @ 2007-11-18 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7ikfwhkj.fsf@gitster.siamese.dyndns.org>
On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > What's causing this? I'm using stgit on the master branch.
> > I'm fixing it each time on the remote server by deleting the ref to master.
> >
> > jonsmirl@terra:~/ds$ git push digispeaker
> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> > ! [rejected] master -> master (non-fast forward)
> > error: failed to push to
> > 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> > jonsmirl@terra:~/ds$
>
> A "non-fast forward" means that you had this history earlier:
>
> o---o---A
> /
> ---o
>
> pushed "A" to the remote's 'master', then built this history:
>
> o---o---A
> /
> ---o---o---o---o---A'
>
> by rewinding and rebuilding, and the tip of the branch now
> points at A', which you tried to push to the remote.
stgit must be doing this when I rebase. It pops all of it's patches,
moves to head of linus/master and then rebases them.
I'm the only person with write access to the repo.
> Which often causes troubles for people who are fetching from the
> branch you are pushing into, and forbidden by default as a
> safety measure.
What is the right way to share repositories using stgit? I have a set
of patches which I am working on for kernel inclusion. I have them
applied as a stgit stack on top of linus/master. I need to share this
patch stack with other developers. These developers may want to change
one of my patches. Right now they are emailing me deltas and I apply
them to the appropriate stgit patch. I have seventeen patches in my
stack currently.
I am starting to see why several people have made comments about
integrating stgit into git. When other developers clone my repo the
stgit setup doesn't come with it. It would be great it we could use
git to push the stgit patches around and work on them.
> As long as the people who fetch from the branch knows that you
> will regularly rewinding the tip of the branch, there is no
> confusion, and you can "force" a non-fast forward update. There
> are two independent safety mechanisms:
>
> - the sending end safety can be overriden by "git push --force"
> and/or by using a refspec prefixed with a '+');
>
> - the receiving end safety can be overriden by the config
> variable receive.denynonfastworwards of the repository you
> are pushing into.
>
> The latter defaults to "unsafe", but if the safety is activated
> in the repository, forcing from the sending side will not
> deactivate it. IOW, both ends need to agree to allow the unsafe
> behaviour.
>
> > On the server I have:
> > [core]
> > repositoryformatversion = 0
> > filemode = true
> > bare = true
> > logallrefupdates = true
> >
> > bare was set false, I just flipped it to true. The server repo was
> > originally created via a clone from kernel.org and then renamed to be
> > a bare repo. Why do we need a 'bare' attribute?
>
> There are a few things that change behaviour depending on the
> bareness of the repository. One example is that "git fetch"
> that updates to the current branch (i.e. what HEAD points at) by
> having it as the RHS of a refspec is accepted only for bare
> repositories (for non-bare repositories such a fetch would make
> the HEAD and the work tree go out-of-sync).
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] Alternates and broken repos: A pack and prune scheme to avoid them
From: Junio C Hamano @ 2007-11-18 18:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711181225.52288.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Then the strategy of garbage collection can be arranged in the following way:
>
> - Repack by starting at the "most complete" repo and work towards the "most
> borrowing" ones. During this phase "attic" packs are created. Borrowing repos
> get a chance to salvage objects before the alternates prune them away.
>
> - Prune by starting at the "most borrowing" repo and work towards the "most
> complete" ones. During this phase the "attic" packs are cleaned up.
>
> What do you think? Is this a way for a solution?
I would imagine that would work as long as it can be controlled
when all the involved repositories are repacked and pruned, such
as on repo.or.cz case (but on the other hand it is not really
controlled well there and that is the reason you wrote the
message X-<).
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Alex Riesen @ 2007-11-18 18:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com>
Jon Smirl, Sun, Nov 18, 2007 16:12:10 +0100:
> What's causing this? I'm using stgit on the master branch.
> I'm fixing it each time on the remote server by deleting the ref to master.
>
> jonsmirl@terra:~/ds$ git push digispeaker
> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> ! [rejected] master -> master (non-fast forward)
> error: failed to push to
the branch you are pushing does not fast-forward to the one on
digispeaker. IOW, the master on digispeaker has changed since you made
changes on your local master.
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Junio C Hamano @ 2007-11-18 18:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> What's causing this? I'm using stgit on the master branch.
> I'm fixing it each time on the remote server by deleting the ref to master.
>
> jonsmirl@terra:~/ds$ git push digispeaker
> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> ! [rejected] master -> master (non-fast forward)
> error: failed to push to
> 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> jonsmirl@terra:~/ds$
A "non-fast forward" means that you had this history earlier:
o---o---A
/
---o
pushed "A" to the remote's 'master', then built this history:
o---o---A
/
---o---o---o---o---A'
by rewinding and rebuilding, and the tip of the branch now
points at A', which you tried to push to the remote.
Which often causes troubles for people who are fetching from the
branch you are pushing into, and forbidden by default as a
safety measure.
As long as the people who fetch from the branch knows that you
will regularly rewinding the tip of the branch, there is no
confusion, and you can "force" a non-fast forward update. There
are two independent safety mechanisms:
- the sending end safety can be overriden by "git push --force"
and/or by using a refspec prefixed with a '+');
- the receiving end safety can be overriden by the config
variable receive.denynonfastworwards of the repository you
are pushing into.
The latter defaults to "unsafe", but if the safety is activated
in the repository, forcing from the sending side will not
deactivate it. IOW, both ends need to agree to allow the unsafe
behaviour.
> On the server I have:
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = true
> logallrefupdates = true
>
> bare was set false, I just flipped it to true. The server repo was
> originally created via a clone from kernel.org and then renamed to be
> a bare repo. Why do we need a 'bare' attribute?
There are a few things that change behaviour depending on the
bareness of the repository. One example is that "git fetch"
that updates to the current branch (i.e. what HEAD points at) by
having it as the RHS of a refspec is accepted only for bare
repositories (for non-bare repositories such a fetch would make
the HEAD and the work tree go out-of-sync).
^ permalink raw reply
* Re: [RFH] Solaris portability
From: Junio C Hamano @ 2007-11-18 17:46 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git, Shawn O Pearce, Jason Riedy, Dennis Stosberg
In-Reply-To: <Pine.LNX.4.64.0711181302360.3945@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
> On Fri, 16 Nov 2007, Junio C Hamano wrote:
>> This makes me wonder if treating it just like strcasestr() might be
>> simpler. Could folks with access to Solaris boxes of different
>> vintages please see if the attached patch makes sense?
>
> I think the patch makes sense as neither Solaris 8, 9 nor 10 supports
> mkdtemp().
>
>> Can we also unify UNSETENV, SETENV, C99_FORMAT and STRTOUMAX, by the
>> way?
>
> No.
>
> I've just checked on our Solaris Sparc systems, and found that the
> C-library provides unsetenv(), setenv() and strtoumax() beginning with
> Solaris 10; also the 'man sprintf' page mentions the 'z' and 't'
> specifiers for printf (which is what is behind C99_FORMAT) only
> beginning with Solaris 10.
>
> So workarounds are needed for all 4 cases for Solaris 8 and 9 but not 10.
Thank you very much for detailed information.
^ permalink raw reply
* [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-18 17:36 UTC (permalink / raw)
To: git; +Cc: Ping Yin
When 'FILE *fp' is assigned to child_process.out and then start_command or
run_command is run, the standard output of the child process is expected to
be outputed to fp. However, sometimes fp is not expected to be closed since
further IO may be still performmed on fp.
---
run-command.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/run-command.c
index 476d00c..4e5f58d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
if (need_in)
close(fdin[0]);
- else if (cmd->in)
- close(cmd->in);
if (need_out)
close(fdout[1]);
- else if (cmd->out > 1)
- close(cmd->out);
if (need_err)
close(fderr[1]);
--
1.5.3.5.1876.g7ba19-dirty
^ permalink raw reply related
* [PATCH] builtin-commit: Fix git-commit honoring status.color
From: Ping Yin @ 2007-11-18 17:10 UTC (permalink / raw)
To: git; +Cc: Ping Yin
status.color shouldn't be honored when committing since the run-status
output is fed to the editor.
---
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 8db74ed..4396e7d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -45,6 +45,7 @@ static int quiet, verbose, untracked_files, no_verify;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
struct strbuf message;
+extern int wt_status_use_color;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
@@ -325,6 +326,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
+ wt_status_use_color = 0;
commitable = run_status(fp, index_file, prefix);
fclose(fp);
--
1.5.3.5.1876.g7ba19-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox