* Re: Newbie questions regarding jgit
From: Shawn O. Pearce @ 2008-11-12 19:29 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B18C4.2070000@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> So far I have figured out how to get the treeWalk for the path filter as
> shown below.
> Now I am lost as to how to get the blob associated with the treeWalk.
> TIA for your help.
>
> /**
> * Gets the content of specified file in git Repo.
> *
> * @parameter relativePath the relative path in jitRepo for desired
> file to get
> * @parameter versionName the versionName for the desired file. It
> will be unmarshalled from String to ObjectId.
> * @return the content of the desired file version packaged as a
> DataHandler.
> */
> public DataHandler get(String relativePath, String versionName) throws
> RepositoryException {
> ObjectId retrieveStart = repository.resolve(versionName);
> RevWalk revWalk = new RevWalk(repository);
> RevCommit entry = revWalk.parseCommit(retrieveStart);
> RevTree revTree = entry.getTree();
>
> TreeWalk treeWalk = TreeWalk.forPath(repository,
> relativePath, revTree);
>
> //Not sure how to get the blob next
if (treeWalk.next()) {
// Path exists
if (treeWalk.getFileMode(0).getObjectType() == Constants.OBJ_BLOB) {
ObjectId blob = treeWalk.getObjectId(0);
} else {
// Not a blob, its something else (tree, gitlink)
}
} else {
// Path not found
}
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 19:29 UTC (permalink / raw)
To: Jeff King
Cc: Avery Pennarun, Johannes Schindelin, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112191512.GA21401@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 12, 2008 at 10:39:21AM -0500, Avery Pennarun wrote:
>
>> > I thought about that at first, too, but the working tree is even more
>> > painful. You would have to hash every changed file on the filesystem to
>> > create the tree object.
>>
>> Is that so bad? You have to read all those files anyway in order to
>> do a diff.
>
> I don't know for sure, as I haven't tried it. But you would need to read
> them twice (once to hash, and then once to diff) plus the extra
> computation time of hashing. So assuming you have a decent cache, you
> pay the disk access only once.
>
> Maybe it would be negligible, but I would have to see numbers to be
> convinced either way.
I think you guys are barking up a wrong tree.
The staged state, the work tree state and the committed states are three
conceptually different things. Making them stand out as distinct entities
at the UI level is a _good thing_.
Introducing STAGED or WORKTREE psuedonym to deliberately muddy the
distinction goes against helping the users form a clear vision of what
s/he is working on at the conceptual level.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 19:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Avery Pennarun, Johannes Schindelin, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <7vljvooi8w.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 11:29:35AM -0800, Junio C Hamano wrote:
> I think you guys are barking up a wrong tree.
>
> The staged state, the work tree state and the committed states are three
> conceptually different things. Making them stand out as distinct entities
> at the UI level is a _good thing_.
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").
But again, I would not be convinced this is a good direction until I
saw:
- the actual design, especially to what degree any ugliness is exposed
when we realize that they _aren't_ trees. IOW, how badly does this
abstraction leak?
- numbers showing that it isn't going to perform significantly worse
And I'm still not volunteering to work on it, so somebody else will have
to come up with those things. ;)
-Peff
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vprl0oiw6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
[...]
> Yeah, it was meant to allow:
>
> git clone -n $there $here
> cd $here
> git checkout
>
> and was not taking care of the case to switch branches when the initial
> checkout is made.
That specific sequence does work. I guess that's why I hadn't noticed
the issue for so long (I guess git's test suite has some tests using
"clone -n", and perhaps they're of that form).
> Perhaps this would help.
Works for me.
[...]
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Miguel de Icaza @ 2008-11-12 19:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Git Mailing List, Shawn Pearce, monodevelop-list,
Michael Hutchinson
In-Reply-To: <491AAE6D.8030304@op5.se>
Hello,
> 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).
Miguel.
^ permalink raw reply
* Re* Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Junio C Hamano @ 2008-11-12 19:52 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Michael J Gruber, git
In-Reply-To: <7vprl0oiw6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Looks like a deliberate change with (what seems to me to be) an
>> unfortunate interaction with "git clone -n"
>
> Yeah, it was meant to allow:
>
> git clone -n $there $here
> cd $here
> git checkout
>
> and was not taking care of the case to switch branches when the initial
> checkout is made.
>
> Perhaps this would help.
> ...
Here is a more involved but hopefully more maintainable fix.
-- >8 --
Subject: checkout: Fix "initial checkout" detection
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 3 +--
builtin-read-tree.c | 2 +-
cache.h | 2 ++
read-cache.c | 5 +++++
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index 05eee4e..25845cd 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -269,8 +269,7 @@ static int merge_working_tree(struct checkout_opts *opts,
}
/* 2-way merge to the new branch */
- topts.initial_checkout = (!active_nr &&
- (old->commit == new->commit));
+ topts.initial_checkout = is_cache_unborn();
topts.update = 1;
topts.merge = 1;
topts.gently = opts->merge;
diff --git c/builtin-read-tree.c w/builtin-read-tree.c
index 0706c95..38fef34 100644
--- c/builtin-read-tree.c
+++ w/builtin-read-tree.c
@@ -206,7 +206,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
break;
case 2:
opts.fn = twoway_merge;
- opts.initial_checkout = !active_nr;
+ opts.initial_checkout = is_cache_unborn();
break;
case 3:
default:
diff --git c/cache.h w/cache.h
index a1e4982..3960931 100644
--- c/cache.h
+++ w/cache.h
@@ -255,6 +255,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define read_cache() read_index(&the_index)
#define read_cache_from(path) read_index_from(&the_index, (path))
+#define is_cache_unborn() is_index_unborn(&the_index)
#define read_cache_unmerged() read_index_unmerged(&the_index)
#define write_cache(newfd, cache, entries) write_index(&the_index, (newfd))
#define discard_cache() discard_index(&the_index)
@@ -360,6 +361,7 @@ extern int init_db(const char *template_dir, unsigned int flags);
/* Initialize and use the cache information */
extern int read_index(struct index_state *);
extern int read_index_from(struct index_state *, const char *path);
+extern int is_index_unborn(struct index_state *);
extern int read_index_unmerged(struct index_state *);
extern int write_index(const struct index_state *, int newfd);
extern int discard_index(struct index_state *);
diff --git c/read-cache.c w/read-cache.c
index 967f483..525d138 100644
--- c/read-cache.c
+++ w/read-cache.c
@@ -1239,6 +1239,11 @@ unmap:
die("index file corrupt");
}
+int is_index_unborn(struct index_state *istate)
+{
+ return (!istate->cache_nr && !istate->alloc && !istate->timestamp);
+}
+
int discard_index(struct index_state *istate)
{
istate->cache_nr = 0;
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 19:57 UTC (permalink / raw)
To: Jeff King
Cc: Avery Pennarun, Johannes Schindelin, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112193747.GA21567@coredump.intra.peff.net>
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.
And we are _not_ treating each of them like a tree. We might be treating
them as collection of paths (and the range operator is about commits).
> But again, I would not be convinced this is a good direction until I
> saw:
> ...
> And I'm still not volunteering to work on it, so somebody else will have
> to come up with those things. ;)
Even if they would, I do not think it is a good direction to go. It makes
the UI less intuitive and harder to learn.
^ permalink raw reply
* Re: hosting git on a nfs
From: Brandon Casey @ 2008-11-12 20:31 UTC (permalink / raw)
To: Julian Phillips; +Cc: Thomas Koch, git, dabe
In-Reply-To: <alpine.LNX.2.00.0811121006400.23345@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> On Wed, 12 Nov 2008, Thomas Koch wrote:
>
>> Hi,
>>
>> finally I managed to convince a critical mass of developers (our chief
>> dev :-) in our company so that we are starting to migrate to GIT.
>>
>> The final question is, whether GIT will life peacefully on our cluster
>> fileservers. The GIT repository dir (/var/cache/git) should be mounted
>> via NFS via PAN on top of DRBD (so I was told).
>>
>> Are there any known problems with this setup? We're asking, because
>> there are problems with SVN on such a setup[1].
>>
>> [1] http://subversion.tigris.org/faq.html#nfs
>
> I've been running git on NFS for years (though it's only NFS exported
> software RAID), and the only issue I've encountered is that it's not
> quite as blisteringly fast as running git on a local disk.
ditto. (except for the years part)
-brandon
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Junio C Hamano @ 2008-11-12 20:47 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0811101543q612917b5ib83e7e657d17ef3c@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> On Fri, Nov 7, 2008 at 4:26 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> Implement git-pull --quiet and git-pull --verbose by
>> adding the options to git-pull and fixing verbosity
>> handling in git-fetch.
>
> Junio,
>
> is there anything still missing in this patch?
> Maybe the name of the test-case is bad.
It seems to break t7600.
^ permalink raw reply
* Re: [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Junio C Hamano @ 2008-11-12 21:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Nelson, git
In-Reply-To: <alpine.LFD.2.00.0811121255330.27509@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> @@ -2103,11 +2107,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> continue;
> }
> if (!prefixcmp(arg, "--max-pack-size=")) {
> - char *end;
> - pack_size_limit_cfg = 0;
> - pack_size_limit = strtoul(arg+16, &end, 0) * 1024 * 1024;
> - if (!arg[16] || *end)
> + if (!git_parse_ulong(arg+16, &pack_size_limit))
> usage(pack_usage);
> + else
> + pack_size_limit_cfg = 0;
> continue;
> }
> if (!prefixcmp(arg, "--window=")) {
Hmm, an unrelated funniness here is why the code even needs to futz with
the value read from the configuration. Later in the code we have:
if (!pack_to_stdout && !pack_size_limit)
pack_size_limit = pack_size_limit_cfg;
and the intent seems to be:
- if there is nothing on the command line, use config;
- if there is something on the command line, ignore config.
But if you have a configured limit and would want to override from the
command line, this won't work.
I will apply the wraparound avoidance as a separate "pure fix" patch to
'maint' first.
Besides, --max-pack-size has been defined as megabytes for the entirety of
its existence, and I am a bit worried about changing the semantics at this
point without any warning. I realize that I am worried too much for
people with a script that give an explicit --max-pack-size=1 to obtain a
set of split packs that would fit on floppies, who probably would not
exist ;-)
^ permalink raw reply
* Re: overly smart rebase - bug or feature?
From: Fedor Sergeev @ 2008-11-12 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman.Shaposhnick, git
In-Reply-To: <7vod0n41i5.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 10, 2008, Junio C Hamano wrote:
> Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:
> >> You might be able to work this around by forcing rebase not to use the
> >> simplified 3-way merge, by saying "rebase -m".
> >
> > Yeah, it worked.
> > ...
> > CONFLICT (delete/modify): Makefile deleted in master and modified in HEAD~0. Version HEAD~0 of Makefile left in tree.
> > ...
> >
> > Though it does make me wonder why *simplified* 3-way merge is smarter than git merge ;)))
>
> Simplified one is not _smarter_. It is merely _faster_, exactly because
> it only looks at the paths between A^..A and nothing else.
I seem to start getting grasp on it.
Please, correct me if I'm wrong:
- by default rebase uses "simplified" merge, which (roughly speaking)
simply goes around patching parent with changes from either branches A and B
- rebase -m applies 'recursive' merge (default merge strategy) which is
kind of smarter and determines a conflict in my case
- literally the same happens when I do merge instead of rebase
- cherry-pick fails just because "patch B" can not apply to A and that is
literally why rebase started falling out to *some* merge first hand
If the above is true then can you, please, answer the following questions:
- is there any merge strategy that can do "simplified" merge just like that in rebase?
(not that I need it, but just for educational purpose)
- does rebase perform simplified merge only because of speed considerations?
(e.g. are there any correctness/usability issues with using smarter merge algo on rebase)
- is there any .git/config variable that affects which merge to use upon rebase?
best regards,
Fedor.
^ permalink raw reply
* Re: [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Nanako Shiraishi @ 2008-11-12 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jon Nelson, git
In-Reply-To: <7vk5b8q1l4.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I think --max-pack-size is what should be fixed to use git_parse_ulong()
> to match the configuration, if you find the discrepancy disturbing.
But doesn't that break existing scripts and habits?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: overly smart rebase - bug or feature?
From: Junio C Hamano @ 2008-11-12 22:04 UTC (permalink / raw)
To: Roman.Shaposhnick; +Cc: git
In-Reply-To: <20081112213920.GB5018@sun.com>
Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:
> Please, correct me if I'm wrong:
>
> - by default rebase uses "simplified" merge, which (roughly speaking)
> simply goes around patching parent with changes from either branches A and B
>
> - rebase -m applies 'recursive' merge (default merge strategy) which is
> kind of smarter and determines a conflict in my case
>
> - literally the same happens when I do merge instead of rebase
If "the same" means "always use 'recursive' merge, without 'am -3'
(mis)behaviour seen in rebase", then yes.
> - cherry-pick fails just because "patch B" can not apply to A and that is
> literally why rebase started falling out to *some* merge first hand
I do not know about this part. Rebase _conceptually_ does cherry-pick but
uses a different implementation.
> If the above is true then can you, please, answer the following questions:
I'll answer the one that cannot be answered without knowing history. I
suspect answers to your other questions are found in the doc set.
> - does rebase perform simplified merge only because of speed considerations?
Historical accident. Originally rebase was only "format-patch | am",
i.e. lift a patch from the commits to be rebased, apply them in order.
Later, "am -3" was invented that allows you to apply patches with fuzz by
using 3-way merge at the content level, which was successfull and rebase
was taught about using it.
^ 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
* 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: [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
* 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
* 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
* 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
* 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: 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: 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: [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: 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: 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
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