* Re: Pull request for sub-tree merge into /contrib/gitstats
From: David Symonds @ 2008-11-03 7:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, sverre, git
In-Reply-To: <alpine.DEB.1.00.0811030729071.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sun, Nov 2, 2008 at 11:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Actually, I suggested that the end result be submitted as a single patch
> against contrib/, but dsymonds objected that that would lose all history,
> and I concurred that it would be nice to have all changes with the design
> decisions recorded as commit messages, too.
I chatted to Sverre separately, and I think we concluded that we could
probably just do a single patch (no history, no changelogs, etc.), and
just point to the complete git-stats.git repo for folk who want the
detail.
Dave.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-03 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, David Symonds, git, Stephan Beyer
In-Reply-To: <7vprle1qdl.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 01:30:46AM -0700, Junio C Hamano wrote:
> A flag "--staged" that means "staged changes and changes in the work tree"
> is no worse than the current "--index". If we were to shoot for clarity,
Well, there is another flag state to be considered, of course, which is
"no flag". So I think "--staged" is fine to mean the working tree and
staged, as long as the default (i.e., no option given) is to operate on
the working tree.
I can't think offhand of any commands that violate that assumption.
> how about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?
>
> I am actually actively unhappy about the latter, but I like more
> descriptive --staged-only for the former a lot better.
Agreed. --staged-only is fine to me, but --staged-and-unstaged just
seems too long.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-03 6:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081103065636.GB10772@coredump.intra.peff.net>
On Mon, Nov 03, 2008 at 01:56:36AM -0500, Jeff King wrote:
> So my statement was not anything about "git push $there HEAD", but just
> that adding "--matching" was reasonable.
And btw, I am not saying I necessarily disagree with Sam's proposal
about bare "git push". I am undecided about the best course of action
there.
I just wanted to make clear that it was not what I was talking about in
the original mail.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-03 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 02:27:57PM -0800, Junio C Hamano wrote:
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I think you are reading more into my statement than I intended. I meant
that adding an explicit --matching was reasonable, _even if it matches
the default_. I can think of two reasons:
1. Even if it is a no-op, it is more explicit for showing newbies what
is going on. And it also means that _if_ we wanted to introduce
new behavior or configurability, we will have already had
"--matching" for some time. So it will be safe(r) at that point to
immediately start saying "--matching" in your scripts to specify the
behavior you want, without as much worry about confusing an older
version.
2. Even today, the behavior of push can be modified with configuration
in remote.*.mirror. I would expect "git push --matching" to override
this. Though perhaps that is too confusing a behavior, as mirroring
does more than just ref selection, including force-updating.
So my statement was not anything about "git push $there HEAD", but just
that adding "--matching" was reasonable.
> I think I was neutral in the discussion that led to the removal of
> "git-export", but the rationale IIRC was exactly because "git-export" can
> be done by simply piping "git-tar" to tar. On the other hand, if all you
> had was "export" and you wanted to create a release tar/zip ball, you have
> to first create a (potentially huge) hierarchy in the filesystem only to
> archive it. This change needs to defend that the benefit of being able to
> create a new non-git checkout elsewhere on the filesystem far outweighs
> the downside of addition of another command (i.e. "eek, why does git have
> that many commands" from new people).
I think the complaint is just that it is awkward to have to pipe to tar
(and harder to check error status), when "export to directory" is a
reasonably common request.
If the concern is about another command, then perhaps rather than "git
export" it would be simpler to have "git archive --format=dir" as a
convenience (and it could even use the checkout-index optimization in
the local case, rather than generating a tar).
-Peff
^ permalink raw reply
* Re: Git and Media repositories....
From: Johannes Schindelin @ 2008-11-03 6:56 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1225655428.11693.10.camel@vaio>
Hi,
On Sun, 2 Nov 2008, Tim Ansell wrote:
> Last week at the gittogether I lead some discussions about how we could
> make Git better support large media repositories (which is one area
> where Subversion still make sense). It was suggested that I post to this
> list to get a discussion going.
>
> The general idea is that we always clone the complete meta-data (tags,
> commits and trees) and then only clone blobs when they are needed (using
> something like alternates). This allows us to support shallow, narrow
> and sparse checkouts while still being able to perform operations such
> as committing and merging.
>
> You can find a copy of the summary presentation at
> http://www.thousandparsec.net/~tim/media+git.pdf
>
> I have started working on adapting git to check a remote http alternate
> to provide a proof of concept.
>
> I appreciate any help or suggestions.
You might find this message (and others from the same time frame and
author) pretty interesting:
http://article.gmane.org/gmane.comp.version-control.git/48485
Ciao,
Dscho
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Johannes Schindelin @ 2008-11-03 6:51 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0811021716y37ba999fkc2085b1060fbea2d@mail.gmail.com>
Hi,
On Mon, 3 Nov 2008, Geoff Russell wrote:
> On Thu, Oct 30, 2008 at 1:40 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 29 Oct 2008, Geoff Russell wrote:
> >
> >> I want to export "the last N days" of a repository to create a copy
> >> which has an origin which is the state of the repository N days ago
> >> and has all the history between then and now.
> >>
> >> Can fast-export do this?
> >
> > Yes. See the --since=... option.
>
> Sorry, I didn't explain what I want very well. N days ago I had a
> working directory in a state S with files F1,F2,F3,... I want to dump
> all the history before then so that this is my new starting point, so I
> want to keep all changes since then.
Well, if you are interested in the history of your _local_ ref, then you
should use reflogs:
$ git log --since=HEAD@{10.days.ago}
Hth,
Dscho
P.S.: man git-reflog
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: Johannes Schindelin @ 2008-11-03 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, git, dsymonds
In-Reply-To: <bd6139dc0811021124q5ba22d6bm6655f735aaeb379b@mail.gmail.com>
Hi,
On Sun, 2 Nov 2008, Sverre Rabbelier wrote:
> On Thu, Oct 30, 2008 at 20:24, Junio C Hamano <gitster@pobox.com> wrote:
> > I have a mixed feeling about this. From a longer-term perspective, do
> > you really want this to be a part of git.git repository?
>
> My main reason for wanting to have it in git.git is getting additional
> exposure, being in /contrib seems like a good way to do that.
>
> > I do not mind having notes to endorse and advocate "stats" as one of
> > the "Third party packages that may make your git life more
> > pleasuable", just like tig, stgit, guilt and topgit, but I cannot
> > convince myself that merging it as a subtree is the right thing to do
> > at this point.
>
> Heh, blame Johannes for that one; the main reason for not doing
> something like this earlier was my uncertaincy as to -what- to do. Dscho
> suggested to request-pull a subtree merge, which is what I did.
Actually, I suggested that the end result be submitted as a single patch
against contrib/, but dsymonds objected that that would lose all history,
and I concurred that it would be nice to have all changes with the design
decisions recorded as commit messages, too.
Actually, in the meantime, I am of two minds. On the one hand, I would
just like to have the scripts in contrib/ (as a result of one commit), and
on the other hand, I would not like to lose history of gitstats.
So I roll the ball back into your (Junio's) half, albeit gently.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document that git-log takes --all-match.
From: Junio C Hamano @ 2008-11-03 6:17 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List
In-Reply-To: <237967ef0811021032j15f7d9cbudfdf9350bc521cd6@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> It's already listed in the bash completion. Feel free to reword.
This is a bad strategy to get your patch accepted except on a rare
occasion when I'm not too lazy nor busy to "feel free". Besides, the
patch is whitespace damaged.
I fixed it up and queued it nevertheless. Thanks.
^ permalink raw reply
* Re: [PATHv3 2/3] gitweb: retrieve snapshot format from PATH_INFO
From: Junio C Hamano @ 2008-11-03 6:17 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <1225617699-30004-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> + # It's also useless to try any matching unless $refname has a dot,
> + # so we check for that too
> + if ($input_params{'action'} eq 'snapshot' &&
This broke t9500 because $input_params{'action'} can be undef. What I'll
be pushing out on 'pu' has a fixup on it (I am rewinding and rebuilding
'pu' right now so it will be a while).
Next time, please make sure that your patches pass the tests before sending
them out.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 6:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pierre Habouzit, Nicolas Pitre, Matthieu Moy, Theodore Tso, git
In-Reply-To: <7vabch22ou.fsf@gitster.siamese.dyndns.org>
On Sun, 2008-11-02 at 14:17 -0800, Junio C Hamano wrote:
> I'd agree that 'reset' is rather unfortunate. It very originally was all
> about the index (the "mixed" semantics, specifically "git reset" without
> any committish nor any pathspec, was the original use case) and nothing
> else. IOW, "I staged a wrong change, let's start over by discarding all
> staged changes". A logical extension to it is "git reset -- pathspec",
> IOW, "I know which paths I fubared, please reset only these paths, as
> other staged changes are Ok".
>
> So "reset <file>" is very much useful.
>
> Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still
> mixed, without any pathspec) can be used to amend the latest commit but
> without losing the state you would eventually want to arrive at. A
> logical extension to this was "git reset --hard HEAD^" to nuking instead
> of amending the mistake, and "git reset --soft HEAD^" to save the trouble
> of staging the changes when the mistake you are fixing is small compared
> to the entire change.
>
> "checkout [$committish] $path" came much later, and the command is all
> about index and files, and never about resetting HEAD. "checkout $path"
> does "reset --hard $path" (notice there is no $committish in either one)
> would have done, so we stopped enhancing the "reset" command in that
> direction.
Interesting.
I'm wondering whether the important thing here is not making a new
command, but simply deprecating "revert", and pointing the user to "git
reset" - then making sure that you can do everything revert-like (eg, as
Elijah points out) from that command.
Sam.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 5:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I don't think it's about laziness, it's more about making sure that
without specifying behaviour, the action of the command is conservative.
Pushing all matching refs is not conservative; it's "magic". And in my
experience, people get bitten by it, because they think, "ok, time to
push this branch", type "git push" and then a lot more than they
expected gets pushed.
I can see that some people want this behaviour by default; but to me
"push the current branch back to where it came from" seems like far more
a rational default for at least 90% of users.
Sam.
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Junio C Hamano @ 2008-11-03 4:58 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, pasky, srabbelier
In-Reply-To: <1225445204-28000-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> +case "$prune_empty,$filter_commit" in
> +',')
> + filter_commit='git commit-tree "$@"';;
> +'t,')
> + filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
> +','*)
> + ;;
> +*)
> + die "Cannot set --prune-empty and --filter-commit at the same time"
> +esac
This is only style issue, but I find the above extremely difficult to
read. If it were either:
case ... in
,) do "neither set case" ;;
t,) do "prune but not filter case" ;;
*) do "both set case" ;;
esac
or (rather amateurish but conveys what it wants to do more clearly):
case ... in
'','') do "neither set case" ;;
t,'') do "prune but not filter case" ;;
t,t) do "both set case" ;;
esac
I wouldn't have to wonder which sq pairs with which one.
> diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> index b0a9d7d..352b56b 100755
> --- a/t/t7003-filter-branch.sh
> +++ b/t/t7003-filter-branch.sh
> @@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
> test_cmp expect actual
> '
>
> +test_expect_success 'Prune empty commits' '
> + make_commit to_remove &&
> + (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
I am not sure what this one is doing.
- Isn't this the same as "git rev-list HEAD^"?
- Do you need a subshell?
^ permalink raw reply
* [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-03 3:22 UTC (permalink / raw)
To: git; +Cc: bain
Hi people,
I have just tagged the teamgit repo as v0.0.4
The improvements over v0.0.3 include
rudimentary blame support, sign-off support, apply-mailbox support,
send patch using desktop email client service support (makes mailto:
request to desktop service).
One minor but "i find it really usefull" features is that if you
select a commit in log and quit, it will print the commit hash to
stdout.
So now you can embed it in git commands or scirpts to fire up a visual
commit selection,
like
git-show `teamigt ./` will show the selected commit etc.
This is really helpful and (correct me if i am wrong) i couldn't find
other gui that does this, may be will be a good addition to gitk?
Links:
http://www.devslashzero.com/teamgit
http://www.devslashzero.com/teamgit/download
Abhijit,
Short log follows
---
Abhijit Bhopatkar (36):
Added .desktop file and icons to install target
Added support files for running checkinstall
Don't depend on qt 4.4.1 we can do with just 4.4
Changed the signoff check box label
Added auto "add sign off line" to commit
Added auto sign off option to general settings
Added auto sign off option in settings
Change libqt-core to libqtcore4 for intrepid in checkinstall
script
Make default new project directory ~/linux-2.6
Add base dir selection for new project dialog
Current project is no longer used
Add base dir selection to the new projects dialog
Fix new project stuff to open up correct repo after clone
Cleaned up icons directory
Removed unneeded icon pngs
Qdevelop cleaned up the project fine
Added git blam support to backend gitprocess
Added file annotation support with commit search
Make sure first column is visible when searching
Scrool annotation text box to top after receiving annotaion
Cleanup: we no longer use mutex
Bring annotated file to front when received
FIX: Open dialog failed to refresh the UI
Added apply mailbox function to git process backend
Added support to push to a selected remote
Removed an uneeded debug output message
Added apply mail action in tools
Added apply mail functionality
Fix: apply mail didn't use the file provided in path and did
nothing
Fix: Make apply mail actully store the last path for it to
remember later
Fix: apply mail did not refresh after operation completed
Added send patch by email functionality
Added send patch by mail in toolbar menu
Activated send patch by mail menu action
Added quit action to file menu and activated it
teamGit will now print sha id of the selected commit while
exiting to stdout
Horst H. von Brand (1):
Fix typo in src/mainwindowimpl.cpp
^ permalink raw reply
* error: non-monotonic index
From: Peter Teoh @ 2008-11-03 2:32 UTC (permalink / raw)
To: git
I git pull and got errors, then git repack and pull again......the
error increased....what happened?
/hdc1/download/2.6/linux26-acer>git pull
remote: Counting objects: 3959, done.
remote: Compressing objects: 100% (668/668), done.
remote: Total 2422 (delta 1934), reused 2154 (delta 1702)
Receiving objects: 100% (2422/2422), 409.97 KiB | 8 KiB/s, done.
Resolving deltas: 100% (1934/1934), completed with 757 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
e946217..45beca0 master -> origin/master
* [new tag] v2.6.28-rc3 -> v2.6.28-rc3
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
fatal: Needed a single revision
45beca08dd8b6d6a65c5ffd730af2eac7a2c7a03 - not something we can merge
/hdc1/download/2.6/linux26-acer>git repack
Counting objects: 9, done.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), done.
Total 9 (delta 0), reused 0 (delta 0)
/hdc1/download/2.6/linux26-acer>git pull
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
fatal: Needed a single revision
45beca08dd8b6d6a65c5ffd730af2eac7a2c7a03 - not something we can merge
--
Regards,
Peter Teoh
^ permalink raw reply
* Re: commit type
From: 7rans @ 2008-11-03 1:34 UTC (permalink / raw)
To: git
In-Reply-To: <3e8340490811021502p70ab40a1ocdc9fca012769a29@mail.gmail.com>
bd_ <bdonlan <at> gmail.com> writes:
> The problem with this approach is that it begins to dictate a set of
> annotations which are considered 'more important' by the git core than
> others. By allowing in your 'commit type', it sets a precedent that
> git will add random, possibly not backwards compatible metadata
> changes just to support the local policies of some subset of git
> users. It's far better to provide a generic feature that will cover
> all users; and using the commit description, with hooks to enforce
> proper format according to local policy, is just that.
>
> If using the commit description, with hooks to enforce whatever
> formatting you prefer, is not sufficient for your needs, then it would
> be useful to discuss exactly how this would be deficient, and then
> possibly think about adding a /generic/ feature that meets your needs.
Except for going so far as to add full-on tagging to commits, I'd don't see how
it could be more generic. Perhaps I'm misunderstood. I'm not suggesting any
particular set of types, if that's what you think. Just the ability to add one.
For example:
git commit -m "describe some change" --type anything-at-all
So the types *I* would use are 'major', 'minor' and 'bug', but others could use
whatever types they'd like. Ie. developers could have their one type policies.
And I agree, it would be cool to define hooks to enforce the policy.
The problem with adding them to the description is that other tools have no idea
about them and so can't not display them when they aren't wanted --a logging
tool is a good example. It is also means more complicated scripting is required
to do anything with them, not a huge deal, but a pita nonetheless.
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-03 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810291610340.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Thu, Oct 30, 2008 at 1:40 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 29 Oct 2008, Geoff Russell wrote:
>
>> I want to export "the last N days" of a repository to create a copy
>> which has an origin which is the state of the repository N days ago and
>> has all the history between then and now.
>>
>> Can fast-export do this?
>
> Yes. See the --since=... option.
Sorry, I didn't explain what I want very well. N days ago I had a
working directory in
a state S with files F1,F2,F3,... I want to dump all the history
before then so that
this is my new starting point, so I want to keep all changes since
then. In general,
this is impossible if there are multiple branches which influence what
happens between
N and now, but in the simple non-branching case it should be possible.
Fast-export with From..To revisions (or with --since=...) just gives changes
since the point N days ago.
Basically I'm trying to do an "rcs -o:1.xyz" where xyz is
a version and I want to prune before that to shrink a large and unwanted
history.
Thanks,
Geoff Russell
>
> Hth,
> Dscho
>
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: [PATCH] asciidoc: add minor workaround to add an empty line after code blocks
From: Kalle Olavi Niemitalo @ 2008-11-03 0:12 UTC (permalink / raw)
To: git
In-Reply-To: <18071eea0811011642g6bc36530sf2036ef15ce0df82@mail.gmail.com>
"Thomas Adam" <thomas.adam22@gmail.com> writes:
> Something the ELinks project does is distribute a fixed version
> of the asciidoc script to avoid annoying asciidoc errors each
> time there's a new asciidoc release.
Actually, we only distribute the AsciiDoc configuration files.
I should perhaps add the actual asciidoc Python script to the
ELinks source tree as well. That seems to be the recommendation
in the AsciiDoc manual.
http://www.methods.co.nz/asciidoc/userguide.html#_shipping_stand_alone_asciidoc_source
^ permalink raw reply
* [RFC PATCH] git-svn: proper detection of bare repositories
From: Deskin Miller @ 2008-11-03 0:09 UTC (permalink / raw)
To: git; +Cc: normalperson
I keep coming across commands like this, which don't work properly in bare
repositories, and thinking that they need to be patched (see e.g. ddff8563, or
Duy's comments on the thread starting at
http://thread.gmane.org/gmane.comp.version-control.git/98849), but now I'm not
so sure. For one, despite this patch working, it turns out that 'git --bare
svn <cmd>' also works (and presumably has) for some time.
Is git --bare the correct way to deal with this situation? That is to say, do
we intend commands to 'just work' regardless of whether the repo is bare or
not, or should the user be thinking about the difference and including --bare
in the command invocation when necessary? I'm a vote for the 'just work' camp,
but it seems a lot of things aren't necessarily that way. On the other hand,
the majority of commands do just work.
I guess I'm asking for a sanity check before I write any more such patches;
certainly I find them useful, as the issues come up during my normal use of
Git, but I don't want to be pursuing things of no use to anyone else, or
(worse) things that are fundamentally wrong for some reason I don't understand
yet.
-- 8< --
When in a bare repository (or .git, for that matter), git-svn would fail
to initialise properly, since git rev-parse --show-cdup would not output
anything. However, git rev-parse --show-cdup actually returns an error
code if it's really not in a git directory.
Fix the issue by checking for an explicit error from git rev-parse, and
setting $git_dir appropriately if instead it just does not output.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
git-svn.perl | 14 ++++++++++----
t/t9100-git-svn-basic.sh | 9 +++++++++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..d25e9be 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -42,6 +42,7 @@ use File::Path qw/mkpath/;
use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
use IPC::Open3;
use Git;
+use Error qw/:try/;
BEGIN {
# import functions from Git into our packages, en masse
@@ -214,11 +215,16 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
"but it is not a directory\n";
}
my $git_dir = delete $ENV{GIT_DIR};
- chomp(my $cdup = command_oneline(qw/rev-parse --show-cdup/));
- unless (length $cdup) {
- die "Already at toplevel, but $git_dir ",
- "not found '$cdup'\n";
- }
+ my $cdup = undef;
+ try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ $git_dir = '.' unless ($cdup);
+ chomp $cdup if ($cdup);
+ $cdup = "." unless ($cdup && length $cdup);
+ }
+ catch Git::Error::Command with {
+ die "Already at toplevel, but $git_dir not found\n";
+ };
chdir $cdup or die "Unable to chdir up to '$cdup'\n";
unless (-d $git_dir) {
die "$git_dir still not found after going to ",
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 843a501..fdbc23a 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -265,4 +265,13 @@ test_expect_success 'able to set-tree to a subdirectory' "
test -z \"\`git diff refs/heads/my-bar refs/remotes/bar\`\"
"
+test_expect_success 'git-svn works in a bare repository' '
+ mkdir bare-repo &&
+ ( cd bare-repo &&
+ git init --bare &&
+ GIT_DIR=. git svn init "$svnrepo" &&
+ git svn fetch ) &&
+ rm -rf bare-repo
+ '
+
test_done
--
1.6.0.3.524.g47d14
^ permalink raw reply related
* PHP購物車資料庫網站專案
From: 姚佳真 @ 2008-11-02 23:57 UTC (permalink / raw)
To: gipsylisa
山鉧科技網頁設計
我們的宗旨：客戶的每ㄧ件小事情，都是山鉧的大事情
我們在推出企業形象網站包含前台網頁美工+後台管理程式
限時限量專案價 只要$29,900
(在送ㄧ年100MB不限流量網站空間)
我們做的不只是網站，而是您企業的入口
ㄧ個好的企業網站資料即時更新的速度是很重要的
企業ｅ化的高品質團隊，打造您的網路門面
選擇山鉧成就您的夢想
～～～～～～～～～～～～～～～～～～～～～～～～～～
PS: 線上購物網站我們還可提供刷卡機制，
與線上列印帳單全省超商+郵局繳費......等金流服務機制
～～～～～～～～～～～～～～～～～～～～～～～～～～
歡迎來電洽詢黃專員（Sam）：0980119812 / 0938764395
上網搜尋『 網頁設計山鉧 』即可找到我們
～～～～～～～～～～～～～～～～～～～～～～～～～～
本公司另外提供關鍵字SEO排序服務
保證將您的網站在Yx / Gx ...排在第一頁
歡迎來電詢問!!!
～～～～～～～～～～～～～～～～～～～～～～～～～～
^ permalink raw reply
* [EGIT PATCH 1/1] Some error handling for GitDocument
From: Robin Rosenberg @ 2008-11-02 23:46 UTC (permalink / raw)
To: Shawn O. Pearce, git
We sometimes (rarely) gets errors from unresolvable trees. Do not just
throw a NullPointerException.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
This is primarily necessary to track down a rare problem, but we
should have error handling here anyway.
.../egit/ui/internal/decorators/GitDocument.java | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
index 3724304..6e10144 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
@@ -21,6 +21,7 @@
import org.spearce.jgit.lib.RefsChangedEvent;
import org.spearce.jgit.lib.Repository;
import org.spearce.jgit.lib.RepositoryListener;
+import org.spearce.jgit.lib.Tree;
import org.spearce.jgit.lib.TreeEntry;
class GitDocument extends Document implements RepositoryListener {
@@ -52,7 +53,14 @@ void populate() throws IOException {
String baseline = GitQuickDiffProvider.baseline.get(repository);
if (baseline == null)
baseline = "HEAD";
- TreeEntry blobEnry = repository.mapTree(baseline).findBlobMember(gitPath);
+ Tree baselineTree = repository.mapTree(baseline);
+ if (baselineTree == null) {
+ Activator.logError("Could not resolve quickdiff baseline "
+ + baseline + " corresponding to " + resource + " in "
+ + repository, new Throwable());
+ return;
+ }
+ TreeEntry blobEnry = baselineTree.findBlobMember(gitPath);
if (blobEnry != null) {
Activator.trace("(GitQuickDiffProvider) compareTo: " + baseline);
ObjectLoader loader = repository.openBlob(blobEnry.getId());
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* [PATCH] Make Pthread link flags configurable
From: david.syzdek @ 2008-11-02 23:43 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
From: David M. Syzdek <david.syzdek@acsalaska.net>
FreeBSD 4.x systems use the linker flags `-pthread' instead of the
linker flags `-lpthread' when linking against the pthread library.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 489774d..6737cb0 100644
--- a/Makefile
+++ b/Makefile
@@ -229,6 +229,7 @@ INSTALL = install
RPMBUILD = rpmbuild
TCL_PATH = tclsh
TCLTK_PATH = wish
+PTHREAD_LIBS = -lpthread
export TCL_PATH TCLTK_PATH
@@ -691,6 +692,7 @@ ifeq ($(uname_S),FreeBSD)
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
THREADED_DELTA_SEARCH = YesPlease
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
+ PTHREAD_LIBS = -pthread
NO_UINTMAX_T = YesPlease
NO_STRTOUMAX = YesPlease
endif
@@ -1017,7 +1019,7 @@ endif
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
- EXTLIBS += -lpthread
+ EXTLIBS += $(PTHREAD_LIBS)
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
--
1.6.0.2.GIT
^ permalink raw reply related
* [EGIT PATCH 1/1] Respect background when drawing history in SWT.
From: Robin Rosenberg @ 2008-11-02 23:38 UTC (permalink / raw)
To: Shawn O. Pearce, git
Use transparent text background for drawing text to make the history
look nice when there is a background pattern or effects like alternating
background colors for each row.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/ui/internal/history/SWTPlotRenderer.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
index 23ec255..c4ee282 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
@@ -89,7 +89,7 @@ protected void drawText(final String msg, final int x, final int y) {
final int texty = (y * 2 - textsz.y) / 2;
g.setForeground(cellFG);
g.setBackground(cellBG);
- g.drawString(msg, cellX + x, cellY + texty);
+ g.drawString(msg, cellX + x, cellY + texty, true);
}
protected Color laneColor(final SWTLane myLane) {
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-02 23:24 UTC (permalink / raw)
To: Andy Parkins, git
In-Reply-To: <1225668059-12670-1-git-send-email-pgit@pcharlan.com>
Sorry for the repeat emails....this first-time "git send-email" user was
a little surprised that it appears to always cc git@vger...
<hides behind rock>
--Pete
Pete Harlan wrote:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
^ permalink raw reply
* [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-02 23:20 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
Add configuration option hooks.showrev, letting the user override how
revisions will be shown in the commit email.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
This allows, for example, to show full diffs in the post-receive email
to simply after-the-fact reviewing of commits. Perhaps others would
find this useful also.
contrib/hooks/post-receive-email | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 4136895..a365c3f 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,12 @@
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
+# hooks.showrev
+# The shell command used to format each revision in the email, with
+# "%s" replaced with the commit id. Defaults to "git rev-list -1
+# --pretty %s", displaying the commit id, author, date and log
+# message. To list full patches separated by a blank line, you
+# could set this to "git show -C %s; echo".
#
# Notes
# -----
@@ -390,8 +396,13 @@ generate_update_branch_email()
echo ""
echo $LOGBEGIN
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $oldrev..$newrev
+ git rev-parse --not --branches |
+ grep -v $(git rev-parse $refname) |
+ git rev-list --stdin $oldrev..$newrev |
+ while read onerev
+ do
+ eval $(printf "$showrev" $onerev)
+ done
# XXX: Need a way of detecting whether git rev-list actually
# outputted anything, so that we can issue a "no new
@@ -627,6 +638,7 @@ recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+showrev=$(git config hooks.showrev || echo 'git rev-list -1 --pretty %s')
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2008, #01; Sun, 02)
From: David Syzdek @ 2008-11-02 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David M. Syzdek, pasky
In-Reply-To: <7vbpwx3j7q.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 2, 2008 at 12:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be merged to the maintenance series have "maint-" in their names.
>
> There are backlog patches I'm planning to deal with later today; they do
> not appear in this list.
>
> ----------------------------------------------------------------
> [New Topics]
>
> * mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
> + update-ref --no-deref -d: handle the case when the pointed ref is
> packed
> + git branch -m: forbid renaming of a symref
> + Fix git update-ref --no-deref -d.
> + rename_ref(): handle the case when the reflog of a ref does not
> exist
> + Fix git branch -m for symrefs.
>
> * rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
> - blame: use xdi_diff_hunks(), get rid of struct patch
> - add xdi_diff_hunks() for callers that only need hunk lengths
> - Allow alternate "low-level" emit function from xdl_diff
> - Always initialize xpparam_t to 0
> - blame: inline get_patch()
>
> * ds/uintmax-config (Sun Oct 26 03:52:47 2008 -0800) 2 commits
> - Add Makefile check for FreeBSD 4.9-SECURITY
> - Build: add NO_UINTMAX_T to support ancient systems
>
> I amended the topmost one to widen the applicability of this new feature
> to all FreeBSD 4.*, not limited to 4.9-SECURITY; testing before this hits
> 'next' is appreciated.
>
> * ds/autoconf (Sun Nov 2 01:04:46 2008 -0700) 2 commits
> - DONTMERGE: fixup with a convenience macro
> - autoconf: Add link tests to each AC_CHECK_FUNC() test
>
> The topmost one is my attempt to simplify the new way of checking; the
> resulting configure.ac produces the identical configure script with or
> without it, so I think it is Ok, but testing before this hits 'next' is
> appreciated. If all goes well, I think the two should be squashed into
> one patch.
I tested the above changes on FreeBSD. The changes worked on FreeBSD
4.9 worked.
However pthread is linked on FreeBSD 4.x by using `-pthread' instead
of `-lpthread'. The current pu branch forces the use of Pthreads and
links using an invalid flag. I am working on a patch now.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox