* 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
* 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: [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: 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: 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: [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: 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] 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* 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: [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: 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: [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: [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: 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 v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Jeff King @ 2008-11-12 19:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <7vzlk4q38q.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 09:10:45AM -0800, Junio C Hamano wrote:
> > Hmm. I'm not sure what happened, but the version in 'next' has "head -n
> > -1" in it.
>
> You mean this one?
>
> commit 31d92611e45d1286b805e362dbc451936af24121
Yes, exactly.
-Peff
^ 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:15 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Michael J Gruber, git
In-Reply-To: <80r65gon3m.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
> [...]
>
>> Bisecting gives:
>>
>>
>> 5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
>> commit 5521883490e85f4d973141972cf16f89a79f1979
>> Author: Junio C Hamano <gitster@pobox.com>
>> Date: Sun Sep 7 19:49:25 2008 -0700
>>
>> checkout: do not lose staged removal
>
> I got the same, which is reassuring.
>
> 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.
builtin-checkout.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index 05eee4e..d2265df 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 = !active_nr;
topts.update = 1;
topts.merge = 1;
topts.gently = opts->merge;
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 19:15 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811120739t95455d8n9b8056a8033491c3@mail.gmail.com>
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.
-Peff
^ permalink raw reply
* running out of memory when doing a clone of a large repository?
From: Paul E. Rybski @ 2008-11-12 18:49 UTC (permalink / raw)
To: git
Hi,
I've recently started evaluating git for use on one of my projects. I
used git-svn to convert a fairly large subversion repository and one of
its branches into two separate git repositories following the
instructions found here:
http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>From that, I created a 1.5G repository from the trunk of the subversion
repo and a 1.1G repository from one of the branches. I then tried to
clone the repositories from one machine to another via ssh and the
smaller 1.1G repository of the subversion branch (with 1932 commits)
came over just fine but the larger 1.5G repository of the subversion
trunk (5865 commits) died with the following error:
remote: Counting objects: 48415, done.
remote: warning: suboptimal pack - out of memory
error: git-upload-pack: git-pack-objects died with error.
fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
Is this simply because the git repository is too large for the machine
that's trying to send it over ssh? Is there a way to restrict the
memory usage of git or do I need to get more RAM or somehow not import
the full subversion history of my original trunk?
I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
of git version 1.5.4.3. The machine holding the repository is a 5-year
old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm
cloning the repository on is a more recent Intel Dual Core Quad Q6600
with 4GRAM and 64-bit Ubuntu.
Any advice would be greatly appreciated.
Thanks!
-Paul
--
Paul E. Rybski, Ph.D., Systems Scientist
The Robotics Institute, Carnegie Mellon University
Phone: 412-268-7417, Fax: 412-268-7350
Web: http://www.cs.cmu.edu/~prybski
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-12 18:30 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B18C4.2070000@wellfleetsoftware.com>
On Wed, Nov 12, 2008 at 18:56, 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.
For ideas take a look at how the NetBeans git plugin accomplishes some
of the most common git tasks take a look at the GitCommand.java file.
It contains code for adding and removing files, committing updates to
the index. There is also some code trying to get "git-status"
information, but it is not very smart or clean. Something equivalent
to "git cat-file" (getting the blob data) can be seen at line 120:
- http://github.com/myabc/nbgit/tree/master/src/org/nbgit/util/GitCommand.java#L120
Sorry, I should have suggested this earlier.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Nicolas Pitre @ 2008-11-12 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Nelson, git
In-Reply-To: <7vk5b8q1l4.fsf@gitster.siamese.dyndns.org>
First, pack.packSizeLimit and --max-pack-size didn't use the same base
unit which was confusing. They both use suffixable value arguments now.
Also, if the limit was sufficiently low, having a single object written
could bust the limit (by design), but caused the remaining allowed size
to go negative for subsequent objects, which for an unsigned variable is
a rather huge limit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 12 Nov 2008, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > First, pack.packSizeLimit and --max-pack-size didn't use the same base
> > unit which was confusing. They both use MiB now.
> >
> > Also, if the limit was sufficiently low, having a single object written
> > could bust the limit (by design), but caused the remaining allowed size
> > to go negative for subsequent objects, which for an unsigned variable is
> > a rather huge limit.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
>
> > @@ -1844,7 +1848,7 @@ static int git_pack_config(const char *k, const char *v, void *cb)
> > return 0;
> > }
> > if (!strcmp(k, "pack.packsizelimit")) {
> > - pack_size_limit_cfg = git_config_ulong(k, v);
> > + pack_size_limit_cfg = git_config_ulong(k, v) * 1024 * 1024;
>
> The fix to tweak the limit for subsequent split pack is a good thing to
> have, but this change would break existing repositories where people
> specified 20971520 (or worse yet "20m") to limit the size to 20MB.
>
> 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.
Fair enough.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 1c4fb43..d60409a 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -104,10 +104,11 @@ base-name::
default.
--max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
+ Maximum size of each output packfile.
If specified, multiple packfiles may be created.
The default is unlimited, unless the config variable
- `pack.packSizeLimit` is set.
+ `pack.packSizeLimit` is set. The size can be suffixed with
+ "k", "m", or "g".
--incremental::
This flag causes an object already in a pack ignored
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 0c4649c..9c4333b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -75,7 +75,7 @@ static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
static int window = 10;
-static uint32_t pack_size_limit, pack_size_limit_cfg;
+static unsigned long pack_size_limit, pack_size_limit_cfg;
static int depth = 50;
static int delta_search_threads = 1;
static int pack_to_stdout;
@@ -245,8 +245,12 @@ static unsigned long write_object(struct sha1file *f,
type = entry->type;
/* write limit if limited packsize and not first object */
- limit = pack_size_limit && nr_written ?
- pack_size_limit - write_offset : 0;
+ if (!pack_size_limit || !nr_written)
+ limit = 0;
+ else if (pack_size_limit <= write_offset)
+ limit = 1;
+ else
+ limit = pack_size_limit - write_offset;
if (!entry->delta)
usable_delta = 0; /* no delta */
@@ -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=")) {
^ permalink raw reply related
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-12 18:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jeff King, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <7v7i78q0go.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Jeff King wrote:
>>> On Mon, Nov 03, 2008 at 02:37:05PM -0600, Brandon Casey wrote:
>>>
>>>> This version replaces the use of 'head -n -1' with a grep, and should work on
>>>> all platforms.
>>>
>>> Hmm. I'm not sure what happened, but the version in 'next' has "head -n
>>> -1" in it.
>>
>> Well, there were so many revisions, I probably should have re-rolled the
>> whole series....
>> ...
>> if that's the way we want to go. I'm not partial to the phrase honor-pack-keep,
>> but I don't think ignore-pack-keep is appropriate, and it's the best I've come
>> up with.
>
> Ok, care to send in a series in incremental updates format, please?
Nah, nevermind. I see you already sent a replacement series overriding what
is in 'next'.
^ 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