* Re: git commit -v does not removes the patch
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here's a patch series that at least improves the situation by turning
> off the diff-stripping if we never put in a diff in the first place.
> That way only people who actually _use_ "-v" will have to pay for it.
> It has the fix I sent to Santi earlier, as well as some related
> cleanups.
>
> 1/5: define empty tree sha1 as a macro
> 2/5: wt-status: refactor initial commit printing
> 3/5: status: show "-v" diff even for initial commit
> 4/5: commit: loosen pattern for matching "-v" diff
> 5/5: commit: only strip diff from message in verbose mode
Makes sense. Thanks, will queue for 'master' with minor futzing to lift
minimum fix to 'maint'.
^ permalink raw reply
* Re: [PATCH] Remove the period after the git-check-attr summary
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1226060815-7548-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The period at the end of the git-check-attr summary causes there to be
> two periods after the summary in the git(1) manual page.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Thanks. I think what you wrote after the --- marker is a perfect
justification of this change, so I lifted them up.
^ permalink raw reply
* Re: git integration with monodevelop
From: Miguel de Icaza @ 2008-11-13 1:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: monodevelop-list, Andreas Ericsson, Git Mailing List,
Shawn Pearce
In-Reply-To: <m33ahwio3v.fsf@localhost.localdomain>
> I assume that results of Mono's Google Summer of Code 2008 projects
> to create managed git implementation in C# (git#)[1][2] were not
> very successfull? Taking into account that JGit isn't yet full git
> implementation, after much longer development...
They were a complete disaster, one student was going to focus on the
front-end, the other on the back-end.
Nothing came out of it.
>
> [1] http://code.google.com/soc/2008/mono/appinfo.html?csaid=E6D8A717A88A7632
> [2] http://code.google.com/soc/2008/mono/appinfo.html?csaid=F2E71A4D93E7EF37
>
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Junio C Hamano @ 2008-11-13 1:38 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Jeff King, git
In-Reply-To: <85647ef50811120508j5074f892p1e2a95acfae8c0a8@mail.gmail.com>
"Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
> BTW for some reason --pretty=raw is affected by encoding option on the
> command line.
Unfortunately, that is what you get for reading from a Porcelain output,
which is meant for, and are subject to improvement for, human consumption.
If you want bit-for-bit information, you can always ask "git cat-file".
^ permalink raw reply
* [PATCH] t7700: test that 'repack -a' packs alternate packed objects
From: Brandon Casey @ 2008-11-13 0:50 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59At-5jc1rZU5GaB35sb1epRZ6zwd7IMw9V94SQyEliIEyriM4J5j3AM@cipher.nrlssc.navy.mil>
Previously, when 'repack -a' was called and there were no packs in the local
repository without a .keep file, the repack would fall back to calling
pack-objects with '--unpacked --incremental'. This resulted in the created
pack file, if any, to be missing the packed objects in the alternate object
store. Test that this specific case has been fixed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Here is a test to demonstrate what
[PATCH 5/6] repack: do not fall back to incremental repacking with [-a|-A]
fixes.
This should apply cleanly to next since it includes
a836cfa3 t7700: demonstrate mishandling of loose objects in an alternate ODB
which has a few context lines showing through in the diff below.
-brandon
t/t7700-repack.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 960bff4..3f602ea 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -53,5 +53,21 @@ test_expect_success 'loose objects in alternate ODB are not repacked' '
test -z "$found_duplicate_object"
'
+test_expect_success 'packed obs in alt ODB are repacked even when local repo is packless' '
+ mkdir alt_objects/pack
+ mv .git/objects/pack/* alt_objects/pack &&
+ git repack -a &&
+ myidx=$(ls -1 .git/objects/pack/*.idx) &&
+ test -f "$myidx" &&
+ for p in alt_objects/pack/*.idx; do
+ git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
+ done | while read sha1 rest; do
+ if ! ( git verify-pack -v $myidx | grep "^$sha1" ); then
+ echo "Missing object in local pack: $sha1"
+ return 1
+ fi
+ done
+'
+
test_done
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re* [take 2] git send-email updates
From: Junio C Hamano @ 2008-11-13 0:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes. For such a usage,
> Documentation/ should not be taken as a maildir. If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
>
> - can it be a rev?
>
> - is it a tracked path (either blob or a leading dir)?
>
> - is it a file/dir that is not tracked?
>
> The first two would be format-patch candidate. The last one is the
> traditional mail source. Because the latter two are disjoint set, and
> because it does not matter if you have a tracked file 'master' and a
> branch 'master' in your repo (either will be passed to format-patch
> anyway), the actual disambiguity is reduced, but it still is different
> from what you have in your patch, I suspect.
>
> As to options, how about doing this:
>
> --no-format-patch means never ever run format-patch, behave exactly as
> before;
>
> --format-patch means what you have in your patch. guess and favor
> format-patch parameter when ambiguous;
>
> without either option, guess and favor mbox/maildir but still run
> format-patch if remaining parameters and options need to
> (e.g. "send-email my-cover-letter origin/master..master" will find
> my-cover-letter which is not tracked and take it as mbox, and grab
> patches from commits between origin/master..master, and send all of
> them).
This patch on top of your [2/4] illustrates what I had in mind (it also
removes the "print foo" while at it).
git-send-email.perl | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git c/git-send-email.perl w/git-send-email.perl
index 6f5a613..9aa3500 100755
--- c/git-send-email.perl
+++ w/git-send-email.perl
@@ -152,7 +152,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
-my $format_patch;
+my $format_patch = 'unspecified';
my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
# Variables with corresponding config settings
@@ -243,6 +243,15 @@ unless ($rc) {
usage();
}
+if ($format_patch && $format_patch eq 'unspecified') {
+ # No --format-patch nor --no-format-patch on the command line
+ $format_patch = 0;
+} elsif (!$format_patch) {
+ $format_patch = undef;
+} else {
+ $format_patch = 1;
+}
+
# Now, let's fill any that aren't set in with defaults:
sub read_config {
@@ -374,11 +383,27 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
# returns 1 if the conflict must be solved using it as a format-patch argument
sub check_file_rev_conflict($) {
my $f = shift;
+
+ if (!defined $format_patch) {
+ # The command line explicitly forbids acting as a wrapper
+ return 0;
+ }
+
+ # If it is a tracked path it can't be tracking the e-mails you
+ # are going to send out to describe the change to this repository.
+ eval {
+ $repo->command(['ls-files', '--error-unmatch', $f],
+ { STDERR => 0 });
+ };
+ if (!$@) {
+ return 1;
+ }
+
+ # Can it be interpreted as a rev?
try {
$repo->command('rev-parse', '--verify', '--quiet', $f);
- if (defined($format_patch)) {
- print "foo\n";
- return $format_patch;
+ if ($format_patch) {
+ return 1;
}
die(<<EOF);
File '$f' exists but it could also be the range of commits
@@ -408,6 +433,8 @@ while (my $f = pop @ARGV) {
closedir(DH);
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
push @files, $f;
+ } elsif (!defined $format_patch) {
+ die("--no-format-patch was given but $f is not a valid send-email argument");
} else {
push @rev_list_opts, $f;
}
^ permalink raw reply related
* git svn branch
From: yb_Art @ 2008-11-12 23:47 UTC (permalink / raw)
To: git
I'm using the binary from google code on my mac os-x leopard machine,
and it doesn't have git svn branch. How can I work around this
issue? Is there anyway to create a branch on the svn repository using
git?
^ permalink raw reply
* Re: git integration with monodevelop
From: Govind Salinas @ 2008-11-13 0:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List, Shawn Pearce, Michael Hutchinson
In-Reply-To: <491AB078.6020208@op5.se>
On Wed, Nov 12, 2008 at 4:31 AM, Andreas Ericsson <ae@op5.se> wrote:
> Andreas Ericsson wrote:
>>
>> Recently, I've started learning C#. More for fun than anything else,
>> but one of the mono core devs sniffed me out and said they've been
>> thinking of porting jgit to C# to get a working IDE integration in
>> monodevelop. Currently, the only option available (with IDE
>> integration anyways) to the poor C# devs is either Microsoft's
>> crappy VSS, or the less crappy but still far from fantastic
>> Subversion.
>>
>> So in an effort to learn C#, I've decided to play along with this
>> (hopefully with some help from the MonoDevelop team), but it seems
>> to me that the best place to start is the fledgling libgit2 and link
>> that with git-sharp. The primary reason for this is ofcourse that I
>> think it'd be a terrible waste to have yet another from-scratch
>> implementation of git in a new language (ruby, java, C#, C...). The
>> secondary reason is that it would be neat to have more OSS projects
>> use my favourite scm.
>>
>> Besides, getting something to rely on libgit2 early on is probably
>> the best way to get more people interested in making development of
>> it proceed rapidly.
>>
>> Thoughts anyone?
>>
>> Please reply-to-all as this goes cross-list
>> (currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
>> m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
>> header).
>>
>
> Ouch. Scratch monodevelop-list from that Cc list. It appears to be
> members-only (although not listed as such on their list-server).
>
Hi,
I started working on a C# UI a long time ago but I abandoned it due
to lack of interest from others and time constraints. You are welcome
to take it and build on it if you like. It wraps the C git binaries and the UI
is separate from the "plumbing".
http://repo.or.cz/w/Widgit.git
-Govind
^ permalink raw reply
* Re: git integration with monodevelop
From: Michael Hutchinson @ 2008-11-12 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: monodevelop-list, Git Mailing List, Shawn Pearce
In-Reply-To: <491AAE6D.8030304@op5.se>
On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@op5.se> wrote:
> Recently, I've started learning C#. More for fun than anything else,
> but one of the mono core devs sniffed me out and said they've been
> thinking of porting jgit to C# to get a working IDE integration in
> monodevelop. Currently, the only option available (with IDE
> integration anyways) to the poor C# devs is either Microsoft's
> crappy VSS, or the less crappy but still far from fantastic
> Subversion.
I'm glad you're interested :-)
We do have an interface in MD for integrating VCS providers, and
although the only existing one is SVN, I believe some users are
working on bzr and perforce addins. I'd prefer to see git get
established as the default (D)VCS ...
Currently, to implement a VCS provider one needs to subclass
VersionControlSystem, as demonstrated by the SVN provider:
http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
We may need to extend the interfaces in order to expose more
DVCS-specific features, but I think it's best to find and fix these as
needed rather than speculatively implementing things.
> So in an effort to learn C#, I've decided to play along with this
> (hopefully with some help from the MonoDevelop team), but it seems
> to me that the best place to start is the fledgling libgit2 and link
> that with git-sharp. The primary reason for this is ofcourse that I
> think it'd be a terrible waste to have yet another from-scratch
> implementation of git in a new language (ruby, java, C#, C...). The
> secondary reason is that it would be neat to have more OSS projects
> use my favourite scm.
That's actually one of the reasons we'd like a full managed
implementation --it'd be trivial to include to with cross-platform
Mono-based apps without worrying about architecture, C dependencies,
etc. For example, Tomboy could use git to store its notes, so users
would have a versioned history and better synch/merge. Then, for
example, you could build a Silverlight version that would have full
history in local storage.
> Besides, getting something to rely on libgit2 early on is probably
> the best way to get more people interested in making development of
> it proceed rapidly.
>
> Thoughts anyone?
I hadn't heard of libgit2 (it looks pretty recent) but it looks
interesting -- at least stable APIs would no longer be a worry.
However, I think fully managed is the way to go, from the point of
view of much easier dependencies (on windows, mac, silverlight and
older linux distros) and licensing.
--
Michael Hutchinson
http://mjhutchinson.com
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 23:42 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Jeff King, Johannes Schindelin,
Björn Steinbrink, David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811121439tbfc54aeq2999dbebf149d5bc@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> I assume the reason is that "git diff tree1..tree2" works with the
> differences between tree1 and tree2, much like "git log tree1..tree2"
> does.
Actually, that perception is already confused. The analogue to "log A..B"
is expressed as "diff A...B", and not "diff A..B".
That is one of the reasons why I tend to teach against using "diff A..B"
unless you know what it is doing. I'd suggest to get out of that habit
before you confuse yourself even more ;-).
The _only_ reason diff takes A..B and A...B syntax is because the command
line parameter parser was easy to write that way. IOW, it was an artifact
of the implementation convenience.
^ permalink raw reply
* Re: [PATCH] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 23:27 UTC (permalink / raw)
To: piyo; +Cc: msysgit, git, Eric Wong
In-Reply-To: <1f748ec60811121406j7ac72c7eqcfbe68132b2ebfc0@mail.gmail.com>
Hi,
Clifford Caoile wrote:
> Hi Marten Svanfeldt:
>
> On Wed, Nov 12, 2008 at 11:28 PM, Marten Svanfeldt (dev)
> <developer@svanfeldt.com> wrote:
..
> I suppose if I wanted to used ${workingdir}/.git instead of
> ${workingdir}, I should replace the $tmpdir line above with $tmpdir =
> $self->repo_path() . "/.git" ?
No. repo_path() is the path to the repository, so the .git directory. If
you instead want within the working directory it is wc_path().
>
> Best regards,
> Clifford Caoile
-Marten Svanfeldt
^ permalink raw reply
* Re: fixing duplicated history
From: Felipe Balbi @ 2008-11-12 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: me, git
In-Reply-To: <7vod0klfng.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 02:53:55PM -0800, Junio C Hamano wrote:
> Felipe Balbi <me@felipebalbi.com> writes:
>
> > I have a git tree which history is completely messed up with duplicated
> > entries. By reading git man pages I saw that it might be possible to
> > delete those duplicated entries with git reflog delete, am I reading it
> > right ?
> >
> > If so, would it cause any problems to the users who already cloned the
> > original tree ? I mean, will git see it as a different history line and
> > try a merge or will it figure it's the same tree with the duplicated
> > entries removed ?
>
> I assume that you meant "commit" by "entry", and also I assume that you
> read "git filter-branch" not "git reflog delete". Then you are right.
>
> And rewriting history with filter-branch will cause problems to the
> downstream users.
Yes, you got me right. Hmm, so if it'll cause problems to the downstream
users I can't do anything, unfortunately :-(
Unless they wanna clone the tree again :-p
Thanks for the info Junio.
--
balbi
^ permalink raw reply
* Re: fixing duplicated history
From: Junio C Hamano @ 2008-11-12 22:53 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
Felipe Balbi <me@felipebalbi.com> writes:
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
>
> If so, would it cause any problems to the users who already cloned the
> original tree ? I mean, will git see it as a different history line and
> try a merge or will it figure it's the same tree with the duplicated
> entries removed ?
I assume that you meant "commit" by "entry", and also I assume that you
read "git filter-branch" not "git reflog delete". Then you are right.
And rewriting history with filter-branch will cause problems to the
downstream users.
^ permalink raw reply
* Re: fixing duplicated history
From: Robin Rosenberg @ 2008-11-12 22:52 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
onsdag 12 november 2008 23:23:51 skrev Felipe Balbi:
> Hi,
>
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
No. The reflog is not the history, except your very local log of what
the heads pointed to. You do not see the reflog unless you ask for it,
and nobody else can see it (i.e. *your* reflog).
What looks like duplicate entries may commit that have been cherry
picked into one or more branches that have been merged thereafter. If
you look carefully they have different id's.
-- robin
^ permalink raw reply
* Re: Why is TreeWalk.forPath(...) returning null
From: Farrukh Najmi @ 2008-11-12 22:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081112224236.GX2932@spearce.org>
Shawn O. Pearce wrote:
> Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
>> My "git status" command shows:
>>
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: xml/minDB/SubmitObjectsRequest_CMSScheme.xml
>>
>> The file above was committed and then modified. I want to use jgit to
>> find the comitted version of that file.
>>
>> When I do the following code I get a null treeWalk? Why is that? What
>> should I specify for path instead?
>>
>> String path = "xml/minDB/SubmitObjectsRequest_CMSScheme.xml";
>> String versionName = Constants.HEAD;
>>
>> Commit commit = repository.mapCommit(versionName);
>>
>> if (commit == null) {
>> log.trace("Did not find Commit. versionName:" +
>> versionName);
>> } else {
>> ObjectId[] ids = {commit.getTree().getId()};
>> TreeWalk treeWalk = TreeWalk.forPath(repository, path, ids);
>> }
>>
>
> Huh. That should have worked.
>
> TreeWalk.forPath returns null if the path doesn't get found. So
> it sounds like jgit isn't matching the path. Its a pretty simple
> operation, I'm not sure why its failing here. I'd run it through
> a debugger to try and see why the TreeWalk didn't match your path.
>
> Your code is logically the same as:
>
> git rev-parse HEAD:$path
>
> so it should find the blob if Git would have found it.
>
>
My bad. I had a type in the path in my junit test :-[
Its working as expected. Thanks.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 22:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <7vbpwkogxq.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 2:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> I'm not sure I agree. They _are_ different things, but in the case of
>> diff, you are really treating each of them like a tree (which makes
>> range operators a little silly, but then that is a silliness already
>> present in "git diff tree1..tree2").
>
> It is not _little_ silly, but quite silly. It is a historical accident
> and I personally suggest against using it when I teach git to others.
I assume the reason is that "git diff tree1..tree2" works with the
differences between tree1 and tree2, much like "git log tree1..tree2"
does. On the other hand, "git log tree1 tree2" is something
completely different.
So at least in my mental model, it's "git diff tree1 tree2" that's out
of place, not really the one with the range specifier.
Apparently what's intuitive to one person isn't always intuitive to the next.
Avery
^ permalink raw reply
* Re: EGIT branch checkout errors
From: Robin Rosenberg @ 2008-11-12 22:48 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: git
In-Reply-To: <491AFB40.4000800@oanda.com>
onsdag 12 november 2008 16:50:24 skrev Chris Dumoulin:
> Using EGIT in Eclipse, I'm able to create a new branch, but not able to
> checkout a branch. When I try Team->Branch...->Checkout, nothing
> happens, so I launched Eclipse from a terminal to see any output it
> might be giving. Here's what I got:
Something is wrong in the WorkDirCheckout class. Could you send these
things
git ls-tree -r HEAD
git-ls-tree -r branch-you-try-to-switch-to
git diff --name-only
Then post it to http://code.google.com/p/egit/issues/list
-- robin
^ permalink raw reply
* Re: Why is TreeWalk.forPath(...) returning null
From: Shawn O. Pearce @ 2008-11-12 22:42 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B579E.6050408@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> My "git status" command shows:
>
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: xml/minDB/SubmitObjectsRequest_CMSScheme.xml
>
> The file above was committed and then modified. I want to use jgit to
> find the comitted version of that file.
>
> When I do the following code I get a null treeWalk? Why is that? What
> should I specify for path instead?
>
> String path = "xml/minDB/SubmitObjectsRequest_CMSScheme.xml";
> String versionName = Constants.HEAD;
>
> Commit commit = repository.mapCommit(versionName);
>
> if (commit == null) {
> log.trace("Did not find Commit. versionName:" +
> versionName);
> } else {
> ObjectId[] ids = {commit.getTree().getId()};
> TreeWalk treeWalk = TreeWalk.forPath(repository, path, ids);
> }
Huh. That should have worked.
TreeWalk.forPath returns null if the path doesn't get found. So
it sounds like jgit isn't matching the path. Its a pretty simple
operation, I'm not sure why its failing here. I'd run it through
a debugger to try and see why the TreeWalk didn't match your path.
Your code is logically the same as:
git rev-parse HEAD:$path
so it should find the blob if Git would have found it.
--
Shawn.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Robin Rosenberg @ 2008-11-12 22:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Farrukh Najmi, git
(resend without HTML)
tisdag 11 november 2008 22:37:40 skrev Jonas Fonseca:
> On Tue, Nov 11, 2008 at 21:44, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
> > Hi all,
>
> Hello,
>
> > I am git newbie and looking to use jgit in a servlet endpoint.
>
> Sounds interesting. I have been thinking about how hard it would be to
> write a very simpe jgitweb kind of thing and am very interested to
> hear more about your experiences.
Consider this:
http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT-jee.git;a=shortlog;h=rr/jeegitweb
It's an toy experiment with taglibs. Unfortunately the JSP doesn't even compile (!) anymore,
maybe someone can spot the error. Something very close to this did work a while ago.
The example jsp is here:
http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT-jee.git;a=blob;f=org.spearce.jeegit web/WebContent/index.jsp;h=d065d9f5a725a161a640e58e3be4d5b3a0666b5e;hb=fabffb50f0a020ff9b1653c090675bbd56dcc80a
-- robin
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Robin Rosenberg @ 2008-11-12 22:36 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
(resend without HTML)
tisdag 11 november 2008 22:12:58 skrev Farrukh Najmi:
>
> I should clarify that I am not using eclipse nor am I using any GUI. My
> objective is to have Java API access to git from within a servlet using
> jgit. At present, all I have to go on is javadoc and its not clear where
> to begin if I simply wish to create, read and update files in a git repo
> from within the servlet java code.
>
We do not have a tutorial. The JUnit tests are the best examples on
how to use the API today. I did some experiement wit J2EE and created
some jsp tags, but that's for JSP only and mostly experimental. To
comply with the JEE spec one should create a resource manager for
Git to deal with scalability when many users try to access repos.
> > I am git newbie and looking to use jgit in a servlet endpoint.
> >
> > Where can I find a public maven repo for gjit? It seems there is one
> > somewhere because of the following file in src tree:
> >
> > jgit-maven/jgit/pom.xml
We do not use maven ourselves right now, though that might change, so
there is not public maven repository for jgit just yet. What do I need to
do to set it up?
> >
> > For now I have built the jar using /make_jgit.sh and installed the pom
> > manually using m
> >
> > mvn install:install-file -DpomFile=jgit-maven/jgit/pom.xml
> > -Dfile=jgit.jar
The pom.xml works for building jgit. cd to the mave dir and type mvn
and watch it build (and run unit tests if you ask it to).
-- robin
^ permalink raw reply
* fixing duplicated history
From: Felipe Balbi @ 2008-11-12 22:23 UTC (permalink / raw)
To: git
Hi,
I have a git tree which history is completely messed up with duplicated
entries. By reading git man pages I saw that it might be possible to
delete those duplicated entries with git reflog delete, am I reading it
right ?
If so, would it cause any problems to the users who already cloned the
original tree ? I mean, will git see it as a different history line and
try a merge or will it figure it's the same tree with the duplicated
entries removed ?
Thanks in advance for the help
--
balbi
^ permalink raw reply
* Why is TreeWalk.forPath(...) returning null
From: Farrukh Najmi @ 2008-11-12 22:24 UTC (permalink / raw)
To: git
My "git status" command shows:
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: xml/minDB/SubmitObjectsRequest_CMSScheme.xml
The file above was committed and then modified. I want to use jgit to
find the comitted version of that file.
When I do the following code I get a null treeWalk? Why is that? What
should I specify for path instead?
String path = "xml/minDB/SubmitObjectsRequest_CMSScheme.xml";
String versionName = Constants.HEAD;
Commit commit = repository.mapCommit(versionName);
if (commit == null) {
log.trace("Did not find Commit. versionName:" +
versionName);
} else {
ObjectId[] ids = {commit.getTree().getId()};
TreeWalk treeWalk = TreeWalk.forPath(repository, path, ids);
}
Thanks.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins
In-Reply-To: <7v3ahwq043.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Michael Adam <obnox@samba.org> writes:
>
> > Junio C Hamano wrote:
> >> Michael Adam <obnox@samba.org> writes:
> >>
> >> > This changes the behaviour of post-receive-email when a list of recipients
> >> > (separated by commas) is specified as hooks.mailinglist. With this modification,
> >> > an individual mail is sent out for each recipient entry in the list, instead
> >> > of sending a single mail with all the recipients in the "To: " field.
> >>
> >> Why can that be an improvement?
> >
> > My use case is that I have a repository where I want to send
> > commit messages to an "official" mailing list and to a private
> > recipient list that might not want to be seen on the official
> > mailing list.
>
> Ah. What you want is a capability to add Bcc:, not a misfeature to run
> the log formatter repeatedly wasting cycles only to generate the same
> message contents.
The intent was to send out the mail not to a (large) list of
individual recipients but to some (few) mailing lists separately.
A Bcc would be a partial solution. I also thought about that, but
I did not like it since it might make those recipients in the bcc
field feel strange because they seem to be getting mail from a
list they might not be subscribed to. Group-replying to such
mails may also cause confusion...
Of course my patch could be optimized for not wasting cycles by
only running generate_email_header() multiple times and caching
the results of the log formatter and generate_email_footer().
But I understand that my problem is a very specific one and that
generally no benefit but only disadvantage is seen in the
modification I suggested. -- Sorry for the noise. :-)
Cheers - Michael
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Jakub Narebski @ 2008-11-12 22:19 UTC (permalink / raw)
To: Miguel de Icaza
Cc: Andreas Ericsson, Git Mailing List, Shawn Pearce,
monodevelop-list, Michael Hutchinson
In-Reply-To: <1226519288.4483.176.camel@erandi.site>
Miguel de Icaza <miguel@ximian.com> writes:
> Andreas Ericsson <ae@op5.se> writes
>
> > So in an effort to learn C#, I've decided to play along with this
> > (hopefully with some help from the MonoDevelop team), but it seems
> > to me that the best place to start is the fledgling libgit2 and link
> > that with git-sharp. The primary reason for this is ofcourse that I
> > think it'd be a terrible waste to have yet another from-scratch
> > implementation of git in a new language (ruby, java, C#, C...). The
> > secondary reason is that it would be neat to have more OSS projects
> > use my favourite scm.
> >
> > Besides, getting something to rely on libgit2 early on is probably
> > the best way to get more people interested in making development of
> > it proceed rapidly.
> >
> > Thoughts anyone?
>
> We would still like to see a port of jgit to C# as a fully managed
> implementation, one that does not make P/Invoke calls into C code can
> run on the sandboxed versions of .NET (Like the one available in
> SecondLife, Unity3D, Silverlight and Mesh).
I assume that results of Mono's Google Summer of Code 2008 projects
to create managed git implementation in C# (git#)[1][2] were not
very successfull? Taking into account that JGit isn't yet full git
implementation, after much longer development...
[1] http://code.google.com/soc/2008/mono/appinfo.html?csaid=E6D8A717A88A7632
[2] http://code.google.com/soc/2008/mono/appinfo.html?csaid=F2E71A4D93E7EF37
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [msysGit] [PATCH] Git.pm: Make _temp_cache use the repository directory
From: Clifford Caoile @ 2008-11-12 22:06 UTC (permalink / raw)
To: developer; +Cc: msysgit, git, Eric Wong
In-Reply-To: <491AE80A.5060807@svanfeldt.com>
Hi Marten Svanfeldt:
On Wed, Nov 12, 2008 at 11:28 PM, Marten Svanfeldt (dev)
<developer@svanfeldt.com> wrote:
>
> Update the usage of File::Temp->tempfile to place the temporary files
> within the repository directory instead of just letting Perl decide what
> [snip]
> +
> + my $tmpdir;
> + if (defined $self) {
> + $tmpdir = $self->repo_path();
> + }
> +
I suppose if I wanted to used ${workingdir}/.git instead of
${workingdir}, I should replace the $tmpdir line above with $tmpdir =
$self->repo_path() . "/.git" ?
Best regards,
Clifford Caoile
^ 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