* clong an empty repo over ssh causes (harmless) fatal
From: Sitaram Chamarty @ 2009-08-31 11:14 UTC (permalink / raw)
To: git
Hello,
Cloning an empty repo seems to produce a spurious error.
The repo still seems fine though.
Any thoughts?
$ git clone ssh://sitaram@localhost/home/sitaram/t/a b
Initialized empty Git repository in /home/sitaram/t/b/.git/
sitaram@localhost's password:
warning: You appear to have cloned an empty repository.
fatal: The remote end hung up unexpectedly
Thanks,
Sitaram
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Martin Langhoff @ 2009-08-31 10:21 UTC (permalink / raw)
To: Howard Miller; +Cc: Daniele Segato, John Tapsell, Frank Münnich, git
In-Reply-To: <26ae428a0908301206s38b36901y6027486f0d780ebc@mail.gmail.com>
On Sun, Aug 30, 2009 at 9:06 PM, Howard
Miller<howard@e-learndesign.co.uk> wrote:
> With a bit of learning
> can can do most of the stuff that an IDE does, usually faster and with
> less fuss.
Ditto. And with a very modest screen size. Modern IDEs need a huge
monitor, and then more, just to show what they want to show you.
Not what you need.
So when working on webapps, I normally keep my editor (usually an
emacs variant) window small, and have lots of terminal windows tracing
relevant logs (webserver, db server) and 3~4 webbrowsers logged in as
different users.
When working on git itself, it's much easier -- as all you need is
your editor and your terminal to compile & debug so for a simple task
like git itself, an IDE might even work ;-)
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Johan Herland @ 2009-08-31 9:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7viqg48nxi.fsf@alter.siamese.dyndns.org>
On Monday 31 August 2009, Junio C Hamano wrote:
> [Stalled]
>
> * jh/notes (2009-08-27) 12 commits.
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note
> string - notes.c: Implement simple memory pooling of leaf nodes
> - Selftests verifying semantics when loading notes trees with various
> fanouts - Teach the notes lookup code to parse notes trees with various
> fanout schemes - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
>
> I heard the cvs-helper series depends on this one. It seems that the
> fan-out strategy is being rethought?
Yes, I'm experimenting with various mixes of date-based and commit_sha1-
based fanouts. Will send a new series when I have some results to show.
Might not have time to finish before next weekend, though.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Erik Faye-Lund @ 2009-08-31 8:29 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Daniele Segato, John Tapsell, Frank Münnich, git
In-Reply-To: <200908302329.11264.robin.rosenberg.lists@dewire.com>
On Sun, Aug 30, 2009 at 11:29 PM, Robin
Rosenberg<robin.rosenberg.lists@dewire.com> wrote:
> VIM and Emacs are really IDE's. In particular you can login to emacs directly
> and never leave it until you log out. Besdides all you pogramming tools you
> have your email and (yes) your mp3 player there. That's pretty integrated to me.
One could argue that some of these features makes them Integrated
Dicking-around Environments instead of Integrated Development
Environments ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* how to skip branches on git svn clone/fetch when there are errors
From: Daniele Segato @ 2009-08-31 8:26 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm trying to clone a big repository.
I follow this steps:
git init
git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
vim .git/config # edited the svn-remote config as follow (add /root to
branches and tag) to match the repo structure
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
git svn fetch
When I reach revision ~7500 (I don't remember the exact number) I get an error:
$ git svn fetch
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 584.
Authorization failed: at /usr/bin/git-svn line 1415
After some debugging I found out the reason is something strange on
the SVN server: there is a folder in the SVN that give an error when
trying to access:
$ svn info svn://svn.mydomain.com/path/to/repo/BRANCHES/V2.1-A
svn: Authorization failed
The same error with svn list.
I don't know what's wrong with that branch but I just want to skip it...
I tried modifying the .git/config svn-remote configuration adding this:
ignore-paths = path\\/to\\/repo\\/BRANCHES\\/V2\\.1-A
and re-launching git svn fetch.
I had no luck.
Ho do I skip a path on the svn repository?
(I can't provide the real svn repo because it is password protected
and I can't give you the access)
Thanks,
Regards,
Daniele
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Yann Dirson @ 2009-08-31 8:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Yann Dirson, git
In-Reply-To: <20090831050554.GA17197@coredump.intra.peff.net>
> On Sun, Aug 30, 2009 at 10:03:07PM -0700, Junio C Hamano wrote:
>
>> > - "-f" is kind of vague. Would people expect it to force aspects of
>> > the stash? Should it be "--intent-as-empty"?
>>
>> I am not sure if asking for positive confirmation with "-f" is even
>> worth
>> it. As you pointed out in your earlier message, which prompted me to
>> respond with a patch, when this codepath is exercised, the user is in a
>> rush, and I do not see what else the user would want to do other than
>> including it in the stash by rerunning with -f.
>
> I guess it was just to mitigate my fear that we are somehow creating a
> stash that will confuse people when they apply it. But really that fear
> is probably unjustified.
Well, indeed each time I use "add -N" it is mostly to get "git diff" show
me the contents of the new file as part of my WIP, so it would not make
much difference to me if "add -N" would just add the file as empty to the
index in the first place.
Out of curiosity, does anyone make any use of the current difference
between not-added-yet and added-as-empty ?
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Andreas Ericsson @ 2009-08-31 8:11 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
Daniele Segato wrote:
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
>> 2009/8/25 Frank Münnich <git@frank-muennich.com>:
>>> One thing I would like to ask you: what, if any, IDEs are you working with?
>> I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
>
Pre-trained fingers in my case. I quite like simple IDE's such as Geany,
but I get so annoyed when emacs keybindings don't work, or when the auto-
indentation doesn't do what I want it to do that I just revert back to
my simple editor instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Andreas Ericsson @ 2009-08-31 8:05 UTC (permalink / raw)
To: David Chanters; +Cc: git
In-Reply-To: <ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com>
David Chanters wrote:
> Hi,
>
> [Please retain a Cc back to me as I am not currently subscribed to the
> mailing list.]
>
> I've recently been intrigued with workflows, and have read quite a bit
> about them, including various references on git-scm.com,
> gitworkflows(7), and the email "A note from the maintainer" which I
> have some questions on. I'll paste random quotes from that and just
> ask my question, I think, so apologies up front of it reads a little
> disjointed.
>
> I'd often wondered when I have read various posts of the git mailing
> list on gmane, just how it is I am supposed to track:
>
> dc/some-topic-feature
>
> ... Junio, are these topic branches ones you actively have somewhere
> in your own private checkout? Yes, I appreciate that when I read a
> given post to the mailing list, you or other people will sometimes
> make reference to these topic branches, but what do I do if I am
> interested in finding out about one of them? Indeed, perhaps even
> before getting to that question, how do you go about creating and
> maintaining these topic branches -- are you making heavy use of "git
> am"?
>
> I ask because of the following snippet from "MaintNotes":
>
> The two branches "master" and "maint" are never rewound, and
> "next" usually will not be either (this automatically means the
> topics that have been merged into "next" are usually not
> rebased, and you can find the tip of topic branches you are
> interested in from the output of "git log next"). You should be
> able to safely track them.
>
> I am not sure if there's any real use-case for this, but I will ask
> anyway: is the above saying that I am able to *checkout* one of these
> topic-branches just from their presence in "next" alone?
Yes. "git log --grep=dc/some-topic-feature next" would point you to
the merge commit where it gets merged to 'next'. Then you can simply
do "git checkout -b dc/some-topic-feature (the-located-commit)^2" to
create the branch "dc/some-topic-feature" as it was when Junio merged
it. This relies on Junio not tampering with the commit messages git
creates when merging, but since there's no real need for that anyway,
it's a fairly safe practice.
>
> To continue:
>
> The "pu" (proposed updates) branch bundles all the remainder of
> topic branches. The "pu" branch, and topic branches that are
> only in "pu", are subject to rebasing in general. By the above
> definition of how "next" works, you can tell that this branch
> will contain quite experimental and obviously broken stuff.
>
> I'm obviously missing something here -- but why is rebasing these
> existing topic branches (I assume on top of "pu") more useful than
> just merging them into "pu" -- like you do with "next"?
>
Because topics in 'pu' can be dropped on the floor, and are worked
on quite a lot more than the ones in next. Undoing a merge is quite
a lot of work as opposed to just rebuilding the history without that
merge. It's also a lot nicer to have a cleaner history in 'next',
since that makes it easier to merge things to 'master' in such a way
that bisection works nicely.
> When a topic that was in "pu" proves to be in testable shape, it
> graduates to "next". I do this with:
>
> git checkout next
> git merge that-topic-branch
>
> Sometimes, an idea that looked promising turns out to be not so
> good and the topic can be dropped from "pu" in such a case.
>
> Ah -- so if I have this straight in my head -- you continually form
> the local topic-branch on its own branch, and then just merge it into
> "next" only when you know that topic branch is satisfactory?
I *think* the topic branches live until they're merged to master, or
until they're dropped (although I could well imagine them staying
behind quite some time after being dropped). I haven't heard Junio
talk about this afair, but that's how I would do it anyways.
> That
> being the case -- again, I assume the use of "git am" for the topic
> branch?
I should think so, although once a patch is applied in its final
form it'll no longer be necessary to use "git am". It'll be easier
to just use rebase on the topic branch(es), or cherry-pick individual
commits from them in order to get only certain benefits of them.
This isn't *very* usual, but it does happen from time to time that
topic branches refactor something first and then adds a feature on
top of that.
> If regular readers of the git mailing list wish to track this
> topic branch, can they do so from you only until it's merged into
> "next"?
>
Topics that make it to master can be tracked indefinitely. 'next'
is never merged directly to master, since the topics brewing on
next get different amounts of testing and feedback. Junio just
merges the topics to master as they go through all the review and
testing they're thought to need. Try
git log --grep="Merge branch '" master
and you'll see what I mean, or have a look using gitk.
> And a related question: If you decide a given topic in pu is declared
> to "be dropped", is this done by rebasing (as you mentioned earlier)
> so as to remove any trace of the topic branch ever having been in
> "pu", or am I reading too much into "dropping" here? :)
>
AFAIU, 'pu' is dropped in its entirety and re-built from the top of 'next'
by the rather simple expedient of "git reset --hard next" and then merging,
one by one, all branches that aren't already merged to maint, master or
next. Git can list such branches so it's no great chore. Naturally, Junio
knows his way fairly well around git and has scripts to do much of this
work for him.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [Vcs-fast-import-devs] bzr to git syncing
From: Ian Clatworthy @ 2009-08-31 7:49 UTC (permalink / raw)
To: Alex Bennee; +Cc: Sverre Rabbelier, David Reitter, vcs-fast-import-devs, git
In-Reply-To: <fabb9a1e0908281049t64f06a2r5efa114c7bcdc468@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> [+vcs-fast-import-devs]
>
> On Fri, Aug 28, 2009 at 10:47, Alex Bennee<kernel-hacker@bennee.com> wrote:
>> 2009/8/28 Sverre Rabbelier <srabbelier@gmail.com>:
>>> On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
>>>> I've attached the fast-import crash I'm seeing. Are you seeing the
>>>> same sort of failure?
>>> The program you used to generate the stream (I assume git-bzr?) is
>>> generating an invalid mode, git understands '100644', '100755',
>>> '120000', and '160000'; the mode in the stream, '040000', is not
>>> something we understand.
>> Yeah, it seems in bzr land it mean new directory which we don't care
>> about.
> This seems like a fine case for the new 'feature' command on bzr's export side.
Hmm - I only added that 040000 stuff late last week and it *should* only
be output if you explicitly ask for extended metadata from bzr
fast-export via the --no-plain option? If that's not the case, please
raise a bug here: https://bugs.launchpad.net/bzr-fastimport.
Ian C.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-31 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jari.aalto
In-Reply-To: <7vbplw28js.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
I apologize if you though I did not read. I did, but I the separate
paragraph order did not meet here as you might have intended.
To recap, your suggestion, if read correct:
--patch:
-p::
Review the difference between the index and the work tree, and add
modified contents to the index interactively by choosing which
patch hunks to use.
Run ``add --interactive``, but bypass the initial command menu and
directly jump to `patch` subcommand. See ``Interactive mode'' for
details.
For more direct first line, howabout:
--patch:
-p::
In a modified work tree, choose interactively which patch hunks to
add. This gives a change to review the difference between the
index and the work before adding modified contents to the index.
This effectively runs ``add --interactive``, but bypass the
initial command menu and directly jump to `patch` subcommand.
See ``Interactive mode'' for details.
Jari
^ permalink raw reply
* Re: git-svn-Cloning repository with complex nesting
From: Daniele Segato @ 2009-08-31 7:41 UTC (permalink / raw)
To: Git Mailing List
On Thu, Aug 27, 2009 at 10:32 AM, Daniele Segato<daniele.bilug@gmail.com> wrote:
> Hi, this is my first message in the list: this may be a newbie
> question and my English may not be very good.
to prove my sentence:
the subject should have been "git-svn-Cloning repository with
_complex_ nesting" :-)
I received help on IRC (#git) and managed to setup the svn-remote in
an acceptable way
> I've an SVN repository structured like this:
>
> http://<url>/path/to/repo
> |
> HEAD
> |----- root
> |
> BRANCHES
> |----- V1.0
> | |----- root
> |
> |----- V1.1
> | |----- root
> |
> |----- V1.2
> | |----- root
> |
> |----- DEV
> | |----- FEATURE1
> | | |----- root
> | |
> | |----- FEATURE2
> | | |----- root
> | |
> | |----- FEATURE3
> | |----- root
> |
> |----- BUILDS
> |----- BUILD1
> | |----- root
> |
> |----- BUILD2
> | |----- root
> |
> |----- BUILD3
> |----- root
this is my setting:
git init
git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
vim .git/config # edited the svn-remote config as follow:
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
git svn fetch
it seems to work as expected: only those branches that has a "root"
folder got downloaded and fetched.
I still couldn't retrieve the DEV/FEATUREx branches in that way.
On IRC they told me I can add another line for branches:
branches = path/to/repo/BRANCHES/*/*/root:refs/remotes/svnbis/*
but I haven't been successful on this. They told me that I can add
multiple branches lines only on newer versions of git.
Probably that's the reason for that.
I have git version 1.5.6.5.
It is not a big deal: I can live without those branches even if I'll
like to have them too.
I have another problem now on that SVN repo but I'll open another
topic about that because it is not related.
Regards,
Daniele
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-31 7:32 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <873a78a2dc.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> I could offer patches, but not in any time frame to do it in one-swoop
> do-it-all patch. To distribute time and effort to do so, it would be
> sensible to handle one manual at a time. The whole work would eventually
> get done.
Yeah, that's the spirit, and that is why I said you do not necessarily
have to do all the work yourself. It would be expected of that volunteer
to keep an eye on patches other helpful folks may send to cover the issue,
vet them to make sure they do not introduce silly typos, AsciiDoc
breakages, and needless conflicts.
As to guidelines, I think your "spell all top-level headlines in caps" is
a reasonable one, as "man" backend for AsciiDoc does that anyway.
For the ancient "Synopsis" issue, SD5-XCU-ERN-97 would be a reasonable
guideline to follow (http://www.opengroup.org/austin/docs/austin_325.txt).
> There could be section in TODO.
>
> RFH - Request for help: Manual page adjustments
>
> - If you have some spare time, the following manual pages adjustment
> is needed for all git manuals ....
>
> Or 2-weekly RFH post could announce the need. That would be one way to
> coordinate participants.
I would leave such a procedural issue to the volunteer who heads the
effort to decide. If you are asking me to decide, then you are not
volunteering yourself, but you are volunteering _me_ for the job ;-).
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-31 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5usyj3i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>> I think the convention used in git's manual pages deviate from the
>> standard practise. We could make the git manual pages into line of:
>>
>> - write all the first level headings in all caps: "HEADING LIKE THIS"
>> - write second level heading: start Upper-lower: "Heading like this"
>>
>> Cf. rsync(1), ssh(1) etc. many pages prior git's existense.
>
[URL: That's a separate issue. The resolution hung in the air how to
proceed]
Please be patient. I understand that you have lot work. I do care,
therefore I take the time to suggest some chnages.
> Are you volunteering to coordinate such a change (in other words, you do
> not necessarily have to do _all_ the work yourself, alone)
We need resolution first. What would you think about that change?
I could offer patches, but not in any time frame to do it in one-swoop
do-it-all patch. To distribute time and effort to do so, it would be
sensible to handle one manual at a time. The whole work would eventually
get done.
There could be section in TODO.
RFH - Request for help: Manual page adjustments
- If you have some spare time, the following manual pages adjustment
is needed for all git manuals ....
Or 2-weekly RFH post could announce the need. That would be one way to
coordinate participants.
Jari
^ permalink raw reply
* What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Junio C Hamano @ 2009-08-31 7:03 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
--------------------------------------------------
[Graduated to "master"]
* wl/insta-mongoose (2009-08-21) 1 commit
(merged to 'next' on 2009-08-25 at da1d566)
+ Add support for the Mongoose web server.
* as/maint-graph-interesting-fix (2009-08-21) 2 commits.
(merged to 'next' on 2009-08-25 at 9d5e215)
+ Add tests for rev-list --graph with options that simplify history
+ graph API: fix bug in graph_is_interesting()
* jc/maint-unpack-objects-strict (2009-08-13) 1 commit.
(merged to 'next' on 2009-08-23 at 38eb750)
+ Fix "unpack-objects --strict"
* jh/submodule-foreach (2009-08-20) 9 commits
(merged to 'next' on 2009-08-20 at 671bea4)
+ git clone: Add --recursive to automatically checkout (nested) submodules
+ t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
(merged to 'next' on 2009-08-18 at f4a881d)
+ git submodule status: Add --recursive to recurse into nested submodules
+ git submodule update: Introduce --recursive to update nested submodules
+ git submodule foreach: Add --recursive to recurse into nested submodules
+ git submodule foreach: test access to submodule name as '$name'
+ Add selftest for 'git submodule foreach'
+ git submodule: Cleanup usage string and add option parsing to cmd_foreach()
+ git submodule foreach: Provide access to submodule name, as '$name'
* lt/block-sha1 (2009-08-17) 4 commits
(merged to 'next' on 2009-08-18 at 67a1ce8)
+ remove ARM and Mozilla SHA1 implementations
+ block-sha1: guard gcc extensions with __GNUC__
+ make sure byte swapping is optimal for git
+ block-sha1: make the size member first in the context struct
* np/maint-1.6.3-deepen (2009-08-24) 1 commit.
(merged to 'next' on 2009-08-25 at 8e383d4)
+ fix simple deepening of a repo
* jk/maint-1.6.3-checkout-unborn (2009-08-24) 1 commit.
(merged to 'next' on 2009-08-25 at 5f29625)
+ checkout: do not imply "-f" on unborn branches
* mm/reset-report (2009-08-21) 2 commits
(merged to 'next' on 2009-08-25 at f2a4424)
+ reset: make the reminder output consistent with "checkout"
+ Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.
* jc/shortstatus (2009-08-15) 11 commits
(merged to 'next' on 2009-08-15 at 7e40766)
+ git commit --dry-run -v: show diff in color when asked
+ Documentation/git-commit.txt: describe --dry-run
(merged to 'next' on 2009-08-12 at 53bda17)
+ wt-status: collect untracked files in a separate "collect" phase
+ Make git_status_config() file scope static to builtin-commit.c
+ wt-status: move wt_status_colors[] into wt_status structure
+ wt-status: move many global settings to wt_status structure
+ commit: --dry-run
(merged to 'next' on 2009-08-06 at fe8cb94)
+ status: show worktree status of conflicted paths separately
+ wt-status.c: rework the way changes to the index and work tree are summarized
+ diff-index: keep the original index intact
+ diff-index: report unmerged new entries
(this branch is used by jc/1.7.0-status.)
--------------------------------------------------
[New Topics]
* jc/upload-pack-hook (2009-08-28) 2 commits
- upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
- upload-pack: add a trigger for post-upload-pack hook
I do not know if the distinction between fetching some but not all refs
and fetching full set of refs into an empty repository is something worth
making, so in that sense the tip commit is somewhat iffy.
One reason this series makes me somewhat uneasy is that Tom, the original
starter of the discussion went dark after sending a proposed patch. Maybe
he has been too busy, but I have been hoping that GitHub as a stakeholder
has somebody who monitors the list when he is not available.
Does anybody from GitHub have any input? Is there something that needs to
be improved to fill GitHub's needs? Does GitHub want to stick to its own
fork, and were all these discussions for improvements unwanted?
* jk/clone-b (2009-08-26) 1 commit
(merged to 'next' on 2009-08-30 at 10a68d1)
+ clone: add --branch option to select a different HEAD
* pk/import-dirs (2009-08-24) 1 commit
- Add script for importing bits-and-pieces to Git.
This version makes me suspect that the author might regret the choice of
the import format that does not allow escaping of paths, nor does not
allow leading blanks for readability without changing semantics, both of
which make it somewhat limiting and error prone. These issues will be
hard to rectify without breaking the backward compatibility, for a tool
that could otherwise turn out to be useful.
As a contrib/ material, I probably shouldn't be too worried about these
issues, but I am keeping this out of 'next' for now, just in case the
author chooses to polish the usability of the tool for general audience.
It is a different story if the submission was just throwing out a one-time
hack in the open in the hope that some other people might find it useful,
but without any intention of maintaining it. But then I do not have a
strong reason to keep this in my tree, either. The mailing list archive
is a more suitable storage media for such a patch.
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- notes.c: Implement simple memory pooling of leaf nodes
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
I heard the cvs-helper series depends on this one. It seems that the
fan-out strategy is being rethought?
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-27) 9 commits.
(merged to 'next' on 2009-08-27 at d314281)
+ Make test case number unique
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
There was a discussion on better DWIMmery for the above two topics to (1)
forbid "git stash save --anything-with-dash" and (2) redirect with any
option "git stash --opt" to "git stash save --opt", to keep it flexible
and safe at the same time. I think it is a sane thing to do, but nothing
has happened lately.
* db/vcs-helper (2009-08-09) 17 commits
- Allow helpers to request marks for fast-import
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- transport-helper_init(): fix a memory leak in error path
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Use a clearer style to issue commands to remote helpers
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
We had a few messages on what the list consensus was with this series. My
impression, after going back to the archive, is that there wasn't.
* jn/gitweb-blame (2009-08-06) 3 commits
- gitweb: Create links leading to 'blame_incremental' using JavaScript
- gitweb: Incremental blame (WIP)
- gitweb: Add optional "time to generate page" info in footer
Ajax-y blame WIP
--------------------------------------------------
[Cooking]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests to covers the positive case (i.e. as long as the user
says "yes" to the "do you really want to send this message that lacks
subject", the message is sent) of this feature, but the feature itself
needs its own test to verify the negative case (i.e. does it correctly
stop if the user says "no"?)
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
Fixes a few "reasonably formatted but thus-far misparsed" date strings.
With tests by Peff, this should be ready for -rc0.
* mr/gitweb-snapshot (2009-08-25) 3 commits
(merged to 'next' on 2009-08-30 at e4edd0b)
+ gitweb: add t9501 tests for checking HTTP status codes
+ gitweb: split test suite into library and tests
+ gitweb: improve snapshot error handling
* jc/mailinfo-scissors (2009-08-26) 5 commits
(merged to 'next' on 2009-08-30 at 5fc6248)
+ mailinfo.scissors: new configuration
+ am/mailinfo: Disable scissors processing by default
+ Documentation: describe the scissors mark support of "git am"
+ Teach mailinfo to ignore everything before -- >8 -- mark
+ builtin-mailinfo.c: fix confusing internal API to mailinfo()
I didn't pick up the patch to simplify the definition of scissors. I do
not have strong opinion on it either way, but the list would hopefully
decide it before too long.
* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.
(merged to 'next' on 2009-08-26 at 4fc7784)
+ xutils: Fix xdl_recmatch() on incomplete lines
+ xutils: Fix hashing an incomplete line with whitespaces at the end
Will merge.
* cc/sequencer-rebase-i (2009-08-28) 15 commits
- rebase -i: use "git sequencer--helper --cherry-pick"
- sequencer: add "--cherry-pick" option to "git sequencer--helper"
- sequencer: add "do_commit()" and related functions working on "next_commit"
- pick: libify "pick_help_msg()"
- revert: libify cherry-pick and revert functionnality
- rebase -i: use "git sequencer--helper --fast-forward"
- sequencer: let "git sequencer--helper" callers set "allow_dirty"
- sequencer: add "--fast-forward" option to "git sequencer--helper"
- sequencer: add "do_fast_forward()" to perform a fast forward
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
Migrating "rebase -i" bit by bit to C.
* jh/cvs-helper (2009-08-18) 7 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
(this branch uses db/vcs-helper.)
Builds on db/vcs-helper (which is stalled, so this cannot move further at
the moment). There is a re-roll planned, so I did not pick up test fixes
from Brandon myself.
* sr/gfi-options (2009-08-27) 6 commits
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Re-rolled, based on an off-list discussion I was/am not aware of.
Looked ready for 'next'.
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-status (2009-08-15) 3 commits
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
With this, "git status" is no longer "git commit --preview".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
* ne/rev-cache (2009-08-21) 6 commits
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
Updated but seems to break upload-pack tests when merged to 'pu'; given
what this series touches, breakages in that area are expected.
May discard if a working reroll comes, to give it a fresh start.
^ permalink raw reply
* Re: [PATCH v2 1/4] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-31 6:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090831022605.GA5507@coredump.intra.peff.net>
On Mon, Aug 31, 2009 at 04:26, Jeff King<peff@peff.net> wrote:
> From: Alex Riesen <raa.lkml@gmail.com>
>
> The main purpose is to allow predictable testing of the code.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Same as previous 1/3, but rebased onto lt/approxidate topic. The merge
> ended up as quite a mess because of textual differences, so I had to
> fix up a fair bit by hand; Alex, please confirm that I didn't screw
> anything up too badly right before putting your name at the top. ;)
Looks good.
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Dmitry Potapov @ 2009-08-31 5:47 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jakub Narebski, Matthias Andree, git, Matthieu Moy
In-Reply-To: <1251661316.25764.4.camel@maia.lan>
On Mon, Aug 31, 2009 at 07:41:56AM +1200, Sam Vilain wrote:
> On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:
>
> > Also IIRC there is warning (well, at least there was in Subversion 1.5
> > release notes) that merge tracking doesn't work entirely correctly in
> > the face of criss-cross merges (multiple merge bases) and renaming
> > (although I do hope that they fixed problem with silent corruption if
> > there is rename during merge).
>
> Not sure about that one. I also heard - unconfirmed - that things start
> to go awry if you start branching off branches and merging around the
> place. But if that happens it's likely a bug rather than a design flaw
> (I think).
Some of the initial issues that existed in SVN 1.5.0 have been resolved,
but some others remain. Here is one bug report related to merge:
http://subversion.tigris.org/issues/show_bug.cgi?id=2897
It was reported two years ago, but the problem is still not fixed.
And there is a few others (some of them even older but even with less
prospect of being fixed any time soon):
http://subversion.tigris.org/issues/show_bug.cgi?id=2837
http://subversion.tigris.org/issues/show_bug.cgi?id=2898
http://subversion.tigris.org/issues/show_bug.cgi?id=3056
http://subversion.tigris.org/issues/show_bug.cgi?id=3157
I don't think they would exist for long if they were ease to fix. Merge
in Subversion is essence automatic cherry-picking, and it is not easy to
implement that in the way it would be reasonably fast and work correctly
in a general case.
Darcs is probably the best when it comes to cherry-picking but clearly
it is not a speed demon. In case of Subversion, the problem is worse,
because it has to make decision on a per file basis rather than operate
each patch as a unit. So, it is even more difficult to implement that
correctly and efficiently.
What you can do relatively simple is to handle a of one directional
merge, and that was the primary design goal of Subversion merge
tracking feature.
Here is what Daniel Berlin wrote about it:
<<<
The initial merge tracking implementation was not meant to handle
repeated bidirectional merging, at least, as designed.
It was designed to allow cherry picks, and mainly for maintaining
feature branches that were mostly one way merges, with the very
occasional merge in the other direction and then branch death :).
For these cases, it works out fine.
For more complex cyclical merge patterns, you really can't use what
we've got. Trying to work around these cases, or build algorithms
that handle them, is just going to lead you into 20 years of edge
cases that made people come up with changeset dags in the first place.
>>>
Source: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=892215
So, I do not think that SVN merge will ever work correctly for those
edge cases.
But even if Subversion learns how to handle all those complex cases
correctly, it will still come with some surprises. One of the main
advantage of the simple 3-way merge is that it is easy to understand
and it makes the right thing most of time. Linus provided a really good
explanation of it here:
http://thread.gmane.org/gmane.comp.version-control.git/60457/focus=60644
Dmitry
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-31 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7vljl0lgms.fsf@alter.siamese.dyndns.org>
On Sun, Aug 30, 2009 at 10:03:07PM -0700, Junio C Hamano wrote:
> > - "-f" is kind of vague. Would people expect it to force aspects of
> > the stash? Should it be "--intent-as-empty"?
>
> I am not sure if asking for positive confirmation with "-f" is even worth
> it. As you pointed out in your earlier message, which prompted me to
> respond with a patch, when this codepath is exercised, the user is in a
> rush, and I do not see what else the user would want to do other than
> including it in the stash by rerunning with -f.
I guess it was just to mitigate my fear that we are somehow creating a
stash that will confuse people when they apply it. But really that fear
is probably unjustified.
-Peff
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Junio C Hamano @ 2009-08-31 5:03 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git
In-Reply-To: <20090831042724.GA16646@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> My concerns are:
>
> - "-f" is kind of vague. Would people expect it to force aspects of
> the stash? Should it be "--intent-as-empty"?
>
> - the error message is still a bit muddled, because you get the "not
> yet added" files _first_, then some failure cruft from write-tree,
> and _then_ the trying-to-be-helpful message
>
> I dunno. Honestly I am a bit lukewarm about this whole thing, as it
> seems like something that just wouldn't come up that often, and while
> the current error message is a bit disorganized, I think a user who has
> used "git add -N" can figure out that it is related (the only report we
> have is from Yann, who _did_ figure it out, but wanted to know how to
> make git handle the situation better).
I am not sure if asking for positive confirmation with "-f" is even worth
it. As you pointed out in your earlier message, which prompted me to
respond with a patch, when this codepath is exercised, the user is in a
rush, and I do not see what else the user would want to do other than
including it in the stash by rerunning with -f.
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-31 4:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7v63c5f4vs.fsf@alter.siamese.dyndns.org>
On Sun, Aug 30, 2009 at 01:01:11PM -0700, Junio C Hamano wrote:
> One thing I noticed was that while unstashing without --index, we add full
> contents to the index of new files. I think it is because back then when
> stash was written there was no other way, but now we have intent-to-add
> and a way to stash such an entry, I think we should add only the intent to
> add them in that codepath.
>
> Of course we will not do this when unstashing with --index.
And btw, I think your suggestion is reasonable, though I don't feel
strongly either way. I don't know that the current behavior is really
bothering anybody.
-Peff
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-31 4:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7v63c5f4vs.fsf@alter.siamese.dyndns.org>
On Sun, Aug 30, 2009 at 01:01:11PM -0700, Junio C Hamano wrote:
> > And all of this while they are trying to quickly switch contexts to
> > whatever it was that caused them to stash in the first place.
>
> Ok, then probably the "how about" patch would be a part of the right
> solution.
And then something like this on top (assuming you cut the change to
git-stash.sh from yours).
My concerns are:
- "-f" is kind of vague. Would people expect it to force aspects of
the stash? Should it be "--intent-as-empty"?
- the error message is still a bit muddled, because you get the "not
yet added" files _first_, then some failure cruft from write-tree,
and _then_ the trying-to-be-helpful message
I dunno. Honestly I am a bit lukewarm about this whole thing, as it
seems like something that just wouldn't come up that often, and while
the current error message is a bit disorganized, I think a user who has
used "git add -N" can figure out that it is related (the only report we
have is from Yann, who _did_ figure it out, but wanted to know how to
make git handle the situation better).
diff --git a/git-stash.sh b/git-stash.sh
index d61c9d0..963cad0 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -20,6 +20,7 @@ TMP="$GIT_DIR/.git-stash.$$"
trap 'rm -f "$TMP-*"' 0
ref_stash=refs/stash
+force=
no_changes () {
git diff-index --quiet --cached HEAD --ignore-submodules -- &&
@@ -63,7 +64,14 @@ create_stash () {
msg=$(printf '%s: %s' "$branch" "$head")
# state of the index
- i_tree=$(git write-tree) &&
+ if ! i_tree=$(git write-tree ${force:+--intent-as-empty}); then
+ case "$force" in
+ t) die 'Cannot save the current index state';;
+ *) echo >&2 'fatal: unable to create tree; if some files are marked as'
+ echo >&2 '"not added yet", you may override with "git stash save -f"'
+ exit 1
+ esac
+ fi
i_commit=$(printf 'index on %s\n' "$msg" |
git commit-tree $i_tree -p $b_commit) ||
die "Cannot save the current index state"
@@ -104,6 +112,9 @@ save_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ -f|--force)
+ force=t
+ ;;
*)
break
;;
diff --git a/t/t3904-stash-intent.sh b/t/t3904-stash-intent.sh
new file mode 100755
index 0000000..ec7dd12
--- /dev/null
+++ b/t/t3904-stash-intent.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='stash with intent-to-add index entries'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo content >base &&
+ git add base &&
+ git commit -m base &&
+ echo foo content >foo &&
+ echo bar content >bar &&
+ git add foo &&
+ git add -N bar
+'
+
+test_expect_success 'stash save refuses intent-to-add entry' '
+ test_must_fail git stash save
+'
+
+test_expect_success 'stash save -f allows intent-to-add' '
+ git stash save -f &&
+ git show stash^2:foo >foo.stash &&
+ echo foo content >expect &&
+ test_cmp expect foo.stash &&
+ >expect &&
+ git show stash^2:bar >bar.stash &&
+ test_cmp expect bar.stash
+'
+
+test_done
^ permalink raw reply related
* Re: [msysGit] Re: Using VC build git (split patch)
From: Frank Li @ 2009-08-31 2:45 UTC (permalink / raw)
To: Thiago Farina
Cc: Erik Faye-Lund, Marius Storm-Olsen, git, msysGit,
Johannes Schindelin
In-Reply-To: <a4c8a6d00908301324o25d1cb48u12b527ea68e43680@mail.gmail.com>
> Yep, an imap-send vcproject with one file(imap-send.c) was added to
> gitbuild.sln.
Sorry, I add imap-send to sln just for testing at solution.
You can omit this project.
best regards
Frank Li
^ permalink raw reply
* [PATCH v2 4/4] fix approxidate parsing of relative months and years
From: Jeff King @ 2009-08-31 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Alex Riesen, git
In-Reply-To: <20090831022228.GA4833@coredump.intra.peff.net>
These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).
Signed-off-by: Jeff King <peff@peff.net>
---
This one is new from the last series, as it fixes bugs only found in
lt/approxidate.
date.c | 5 ++++-
t/t0006-date.sh | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/date.c b/date.c
index 8e57e5e..e9ee4aa 100644
--- a/date.c
+++ b/date.c
@@ -857,7 +857,9 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm
}
if (match_string(date, "months") >= 5) {
- int n = tm->tm_mon - *num;
+ int n;
+ update_tm(tm, now, 0); /* fill in date fields if needed */
+ n = tm->tm_mon - *num;
*num = 0;
while (n < 0) {
n += 12;
@@ -868,6 +870,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm
}
if (match_string(date, "years") >= 4) {
+ update_tm(tm, now, 0); /* fill in date fields if needed */
tm->tm_year -= *num;
*num = 0;
return end;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 02cd565..a4d8fa8 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -53,8 +53,8 @@ check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
check_approxidate yesterday '2009-08-29 19:20:00'
check_approxidate 3.days.ago '2009-08-27 19:20:00'
check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
-check_approxidate 3.months.ago '2009-05-30 19:20:00' failure
-check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00' failure
+check_approxidate 3.months.ago '2009-05-30 19:20:00'
+check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00'
check_approxidate '6am yesterday' '2009-08-29 06:00:00'
check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
--
1.6.4.2.373.g5881fd
^ permalink raw reply related
* [PATCH v2 3/4] tests: add date printing and parsing tests
From: Jeff King @ 2009-08-31 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Alex Riesen, git
In-Reply-To: <20090831022228.GA4833@coredump.intra.peff.net>
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. Most of the tests are just "this
obvious thing works" to prevent future regressions, with a
few exceptions:
- We confirm the fix in 607a9e8 that relative year/month
dates in the latter half of a year round correctly.
- We confirm that the improvements in b5373e9 and 1bddb25
work.
- A few tests are marked to expect failure, which are
regressions recently introduced by the two commits
above.
Signed-off-by: Jeff King <peff@peff.net>
---
Similar to earlier 3/3, but improvements and regressions from
lt/approxidate included.
Linus, when you posted the approxidate fixes earlier, you mentioned you
might have some other corner cases. I think you were just referring to
the stuff you improved in the followup patch, but if you know of more
broken-ness, we should probably include it here.
t/t0006-date.sh | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t0006-date.sh
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
new file mode 100755
index 0000000..02cd565
--- /dev/null
+++ b/t/t0006-date.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+
+test_description='test date parsing and printing'
+. ./test-lib.sh
+
+# arbitrary reference time: 2009-08-30 19:20:00
+TEST_DATE_NOW=1251660000; export TEST_DATE_NOW
+
+check_show() {
+ t=$(($TEST_DATE_NOW - $1))
+ echo "$t -> $2" >expect
+ test_expect_${3:-success} "relative date ($2)" "
+ test-date show $t >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_show 5 '5 seconds ago'
+check_show 300 '5 minutes ago'
+check_show 18000 '5 hours ago'
+check_show 432000 '5 days ago'
+check_show 1728000 '3 weeks ago'
+check_show 13000000 '5 months ago'
+check_show 37500000 '1 year, 2 months ago'
+check_show 55188000 '1 year, 9 months ago'
+check_show 630000000 '20 years ago'
+
+check_parse() {
+ echo "$1 -> $2" >expect
+ test_expect_${3:-success} "parse date ($1)" "
+ test-date parse '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_parse 2008 bad
+check_parse 2008-02 bad
+check_parse 2008-02-14 bad
+check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
+
+check_approxidate() {
+ echo "$1 -> $2 +0000" >expect
+ test_expect_${3:-success} "parse approxidate ($1)" "
+ test-date approxidate '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_approxidate now '2009-08-30 19:20:00'
+check_approxidate '5 seconds ago' '2009-08-30 19:19:55'
+check_approxidate 5.seconds.ago '2009-08-30 19:19:55'
+check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
+check_approxidate yesterday '2009-08-29 19:20:00'
+check_approxidate 3.days.ago '2009-08-27 19:20:00'
+check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
+check_approxidate 3.months.ago '2009-05-30 19:20:00' failure
+check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00' failure
+
+check_approxidate '6am yesterday' '2009-08-29 06:00:00'
+check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
+check_approxidate '3:00' '2009-08-30 03:00:00'
+check_approxidate '15:00' '2009-08-30 15:00:00'
+check_approxidate 'noon today' '2009-08-30 12:00:00'
+check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
+
+check_approxidate 'last tuesday' '2009-08-25 19:20:00'
+check_approxidate 'July 5th' '2009-07-05 19:20:00'
+check_approxidate '06/05/2009' '2009-06-05 19:20:00'
+check_approxidate '06.05.2009' '2009-05-06 19:20:00'
+
+check_approxidate 'Jun 6, 5AM' '2009-06-06 05:00:00'
+check_approxidate '5AM Jun 6' '2009-06-06 05:00:00'
+check_approxidate '6AM, June 7, 2009' '2009-06-07 06:00:00'
+
+test_done
--
1.6.4.2.373.g5881fd
^ permalink raw reply related
* [PATCH v2 2/4] refactor test-date interface
From: Jeff King @ 2009-08-31 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090831022228.GA4833@coredump.intra.peff.net>
The test-date program goes back to the early days of git,
where it was presumably used to do manual sanity checks on
changes to the date code. However, it is not actually used
by the test suite to do any sort of automatic of systematic
tests.
This patch refactors the interface to the program to try to
make it more suitable for use by the test suite. There
should be no fallouts to changing the interface since it is
not actually installed and is not internally called by any
other programs.
The changes are:
- add a "mode" parameter so the caller can specify which
operation to test
- add a mode to test relative date output from show_date
- allow faking a fixed time via the TEST_DATE_NOW
environment variable, which allows consistent automated
testing
- drop the use of ctime for showing dates in favor of our
internal iso8601 printing routines. The ctime output is
somewhat redundant (because of the day-of-week) which
makes writing test cases more annoying.
Signed-off-by: Jeff King <peff@peff.net>
---
Same as earlier 2/3.
test-date.c | 86 +++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 66 insertions(+), 20 deletions(-)
rewrite test-date.c (63%)
diff --git a/test-date.c b/test-date.c
dissimilarity index 63%
index 62e8f23..5b0a220 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,20 +1,66 @@
-#include "cache.h"
-
-int main(int argc, char **argv)
-{
- int i;
-
- for (i = 1; i < argc; i++) {
- char result[100];
- time_t t;
-
- memcpy(result, "bad", 4);
- parse_date(argv[i], result, sizeof(result));
- t = strtoul(result, NULL, 0);
- printf("%s -> %s -> %s", argv[i], result, ctime(&t));
-
- t = approxidate(argv[i]);
- printf("%s -> %s\n", argv[i], ctime(&t));
- }
- return 0;
-}
+#include "cache.h"
+
+static const char *usage_msg = "\n"
+" test-date show [time_t]...\n"
+" test-date parse [date]...\n"
+" test-date approxidate [date]...\n";
+
+static void show_dates(char **argv, struct timeval *now)
+{
+ char buf[128];
+
+ for (; *argv; argv++) {
+ time_t t = atoi(*argv);
+ show_date_relative(t, 0, now, buf, sizeof(buf));
+ printf("%s -> %s\n", *argv, buf);
+ }
+}
+
+static void parse_dates(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ char result[100];
+ time_t t;
+
+ parse_date(*argv, result, sizeof(result));
+ t = strtoul(result, NULL, 0);
+ printf("%s -> %s\n", *argv,
+ t ? show_date(t, 0, DATE_ISO8601) : "bad");
+ }
+}
+
+static void parse_approxidate(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ time_t t;
+ t = approxidate_relative(*argv, now);
+ printf("%s -> %s\n", *argv, show_date(t, 0, DATE_ISO8601));
+ }
+}
+
+int main(int argc, char **argv)
+{
+ struct timeval now;
+ const char *x;
+
+ x = getenv("TEST_DATE_NOW");
+ if (x) {
+ now.tv_sec = atoi(x);
+ now.tv_usec = 0;
+ }
+ else
+ gettimeofday(&now, NULL);
+
+ argv++;
+ if (!*argv)
+ usage(usage_msg);
+ if (!strcmp(*argv, "show"))
+ show_dates(argv+1, &now);
+ else if (!strcmp(*argv, "parse"))
+ parse_dates(argv+1, &now);
+ else if (!strcmp(*argv, "approxidate"))
+ parse_approxidate(argv+1, &now);
+ else
+ usage(usage_msg);
+ return 0;
+}
--
1.6.4.2.373.g5881fd
^ permalink raw reply related
* [PATCH v2 1/4] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-31 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20090831022228.GA4833@coredump.intra.peff.net>
From: Alex Riesen <raa.lkml@gmail.com>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Same as previous 1/3, but rebased onto lt/approxidate topic. The merge
ended up as quite a mess because of textual differences, so I had to
fix up a fair bit by hand; Alex, please confirm that I didn't screw
anything up too badly right before putting your name at the top. ;)
cache.h | 5 ++
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 92 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index 808daba..5fad24c 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,14 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index e848d96..8e57e5e 100644
--- a/date.c
+++ b/date.c
@@ -86,6 +86,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz,
+ const struct timeval *now,
+ char *timebuf,
+ size_t timebuf_size)
+{
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, timebuf_size, "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, timebuf_size, "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, timebuf_size, "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, timebuf_size, "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, timebuf_size, "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = diff / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, timebuf_size, "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, timebuf_size - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, timebuf_size - n, " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, timebuf_size, "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -97,63 +158,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = diff / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now,
+ timebuf, sizeof(timebuf));
}
if (mode == DATE_LOCAL)
@@ -918,19 +926,13 @@ static void pending_number(struct tm *tm, int *num)
}
}
-unsigned long approxidate(const char *date)
+static unsigned long approxidate_str(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
- char buffer[50];
- if (parse_date(date, buffer, sizeof(buffer)) > 0)
- return strtoul(buffer, NULL, 10);
-
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
@@ -954,3 +956,25 @@ unsigned long approxidate(const char *date)
pending_number(&tm, &number);
return update_tm(&tm, &now, 0);
}
+
+unsigned long approxidate_relative(const char *date, const struct timeval *tv)
+{
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 0);
+
+ return approxidate_str(date, tv);
+}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 0);
+
+ gettimeofday(&tv, NULL);
+ return approxidate_str(date, &tv);
+}
--
1.6.4.2.373.g5881fd
^ 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