* Re: question concerning branches
From: Jakub Narebski @ 2009-08-20 14:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ingo Brueckl, Linus Torvalds, git
In-Reply-To: <4A8D53F3.3050500@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ingo Brueckl schrieb:
> > In a branch, I learned, I have to commit or stash before I return to master
> > for push/pull to follow the project. If I forget, I'm screwed, because files
> > have changed due to the rewrite (in that branch), I won't get a warning until
> > my first commit (in that branch) and commits (in master) will conflict.
Errr... if having unknown files in status info when comitting doesn't
clue you in that you have spurious uncomitted changes,
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: somefile
and neither commit diff summary
n files changed, kk insertions(+), ll deletions(-)
doesn't clue you in, then you have more serous problems!
Second, you can use git-aware prompt to tell you if you have
uncomitted changes, so you will know when switching branches that you
have some changes that don't belong to branch you switch from.
>
> You are obviously of a CVS or SVN mindset, where making a commit is such
> an important operation that you don't dare to make it until your work is
> *completed*.
>
> With a git mindset, it won't happen that you "forget" whether you have
> anything uncommitted; you simply never have because committing half-baked
> stuff is the rule, not the exception. That is, before you get a cup of
> coffee, you commit; before you answer a phone call, you commit; before you
> turn your attention away, you commit. (That may be exaggerated, perhaps it
> even isn't, but you get the point.)
>
> When you have completed your work, you go back to make your commit history
> look nice, comprehensible, and bisectable.
...with "git rebase --interactive" or patch management interface
(StGit, Guilt), or topic branch management interface (TopGit).
>
> And only then comes the heavy operation: You publish your work for
> consumption by interested parties. This may be even only you yourself:
> "Consumption" would be to merge the work into your release branch. This is
> the right time to care about upstream again.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb and symbolic links
From: Jakub Narebski @ 2009-08-20 15:03 UTC (permalink / raw)
To: Marco Gualtieri; +Cc: git
In-Reply-To: <2367E9DF-6FB1-48E6-AC9A-73E84C9D54E1@math.utoronto.ca>
Marco Gualtieri <mgualt@math.utoronto.ca> writes:
> Hello,
>
> I am wondering about a possibly easy bug which you may be aware of.
>
> For some reason if I place a symbolic link in a directory under the
> project root, gitweb is no longer able to find the project. I was
> looking through the .cgi file but I don't know enough perl to fix the
> problem myself.
>
> Let me know if this makes sense.
WORKSFORME. I have gitweb setup so some of repositories are in
$projectroot directory via symlink, either to repository itself, or
with symlinked earlier part of path, and it works correctly and shows
all those repositories.
I suspect that your web server is configured to not follow symbolic
links, or your user account used by web server is not allowed (doesn't
have permissions) to follow symbolic links.
P.S. You should look into source file gitweb/gitweb.perl, not
installed script gitweb.cgi
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Sparse checkout
From: Jakub Narebski @ 2009-08-20 15:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1250776033-12395-1-git-send-email-pclouds@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-16be, Size: 1805 bytes --]
Nguyþÿ\x1eÅn Thþÿ
> Welcome to the fourth round of sparse checkout this year, dubbed "The
> mummy^W^W^W^W^Wno-checkout returns", although the bit now comes under
> a new name "skip-worktree" [1]. This series has two parts: sparse
> worktree and sparse checkout. Details will be given below.
>
> For brave users of this series: I have pushed it to my sparse-checkout
> branch [2] so you can just clone it and test away. Visible changes:
>
> - the spec is now .git/info/sparse-checkout
> - the spec is positive matching, that is it matches what _is_ in
> worktree, not what is out of worktree like the last series
> - you need to set core.sparsecheckout no additional command argument
> is needed.
[...]
> [1] There are a few reasons behind this rename:
> - there is nothing about "checkout" in the first part, it's about
> "sparse worktree"
> - the double negation issue with "no-" part of "no-checkout"
> - new name makes cache.h diff align beautifully
Well, on one hand side it is more clear what is checked out,
and perhaps more common case of checking out only selected files
is simpler.
On the other hand if it was .git/info/no-checkout or checkout-exclude,
or worktree-exclude, empty file or lack of such file would mean full
checkout. Then core.sparsecheckout (or core.sparsefile) would be
needed only for performance reasons (no need to examine
checkout-exclude file) even if we decide to ship example file with
comments describing its syntax, in templates/info--checkout-exclude
But that is just bikeshedding, don't let it distract you from the real
issue of this series...
--
Jakub Narþÿ\x01\x19bski
In related news: there is really no question that bike sheds should be
painted red. Really.
(Johannes Schindelin, on git mailing list)
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Sparse checkout
From: Matthieu Moy @ 2009-08-20 15:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <m3ocqamrz6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Content-Type: text/plain; charset=utf-16be
^^^^^^^^
I don't know what it should have been, but not UTF-16 ;-)
(readable message below)
> Nguyen Thai
>> Welcome to the fourth round of sparse checkout this year, dubbed "The
>> mummy^W^W^W^W^Wno-checkout returns", although the bit now comes under
>> a new name "skip-worktree" [1]. This series has two parts: sparse
>> worktree and sparse checkout. Details will be given below.
>>
>> For brave users of this series: I have pushed it to my sparse-checkout
>> branch [2] so you can just clone it and test away. Visible changes:
>>
>> - the spec is now .git/info/sparse-checkout
>> - the spec is positive matching, that is it matches what _is_ in
>> worktree, not what is out of worktree like the last series
>> - you need to set core.sparsecheckout no additional command argument
>> is needed.
> [...]
>
>> [1] There are a few reasons behind this rename:
>> - there is nothing about "checkout" in the first part, it's about
>> "sparse worktree"
>> - the double negation issue with "no-" part of "no-checkout"
>> - new name makes cache.h diff align beautifully
>
> Well, on one hand side it is more clear what is checked out,
> and perhaps more common case of checking out only selected files
> is simpler.
>
> On the other hand if it was .git/info/no-checkout or checkout-exclude,
> or worktree-exclude, empty file or lack of such file would mean full
> checkout. Then core.sparsecheckout (or core.sparsefile) would be
> needed only for performance reasons (no need to examine
> checkout-exclude file) even if we decide to ship example file with
> comments describing its syntax, in templates/info--checkout-exclude
>
> But that is just bikeshedding, don't let it distract you from the real
> issue of this series...
>
> --
> Jakub Narebski
>
> In related news: there is really no question that bike sheds should be
> painted red. Really.
> (Johannes Schindelin, on git mailing list)
--
Matthieu
^ permalink raw reply
* Re: [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Brandon Casey @ 2009-08-20 16:59 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <200908201124.54193.johan@herland.net>
Johan Herland wrote:
> On Thursday 20 August 2009, Junio C Hamano wrote:
>> Johan Herland <johan@herland.net> writes:
>>>> - $sub1sha1 sub1 (${sub1sha1:0:7})
>>>> - $sub2sha1 sub2 (${sub1sha1:0:7})
>>>> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
>>>> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
>>> Typo (both in the original, and the patch), should be:
>>> $sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
>>>
>>>> $sub3sha1 sub3 (heads/master)
>>>> EOF
>>> Otherwise:
>>>
>>> Acked-by: Johan Herland <johan@herland.net>
>> Hmm, what does the command use to shorten these object names? It may be
>> safer and more correct to use "rev-parse --short" in case these object
>> names were ambigous in their first 7 hexdigits.
>
> git submodule status (which is what we're testing here) uses
> 'git describe' to generate the short object name (see
> set_name_rev in git-submodule.sh). In this case, it falls back
> to 'git describe --all --always', which calls find_unique_abbrev()
> on the SHA1. 'git rev-parse --short' ends up calling the same
> find_unique_abbrev(), so I guess it is better to use it here.
>
> Try this instead:
>
> From: Johan Herland <johan@herland.net>
>
> Subject: [PATCH] t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
>
> The substring expansion notation is a bashism that we have not so far
> adopted. Use 'git rev-parse --short' instead, as this also handles
> the case where the unique abbreviation is longer than 7 characters.
Works for me.
Maybe it should be mentioned that a typo was fixed too.
-brandon
^ permalink raw reply
* Re: question concerning branches
From: Theodore Tso @ 2009-08-20 17:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Brueckl, git
In-Reply-To: <200908192257.23347.jnareb@gmail.com>
On Wed, Aug 19, 2009 at 10:57:21PM +0200, Jakub Narebski wrote:
> Errr... you are aware that you can use "git stash save <message>" (i.e.
> specify commit message for stash; well, the subject), don't you?
I wasn't aware, but usually I like leaving more notes to myself than
just a single lines' worth of state. I should probably take another
look at "git stash" and see if it's a handy tool for me to use; but so
far I've been happy enough with "git checkout -b topic-name; git
commit".
- Ted
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-20 18:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <200908200937.05412.jnareb@gmail.com>
On Thu, 20 Aug 2009, Jakub Narebski wrote:
> On Wed, 19 Aug 2009, Nicolas Pitre wrote:
> > You'll get the very latest revision for HEAD, and only that. The size
> > of the transfer will be roughly the size of a daily snapshot, except it
> > is fully up to date. It is however non resumable in the event of a
> > network outage. My proposal is to replace this with a "git archive"
> > call. It won't get all branches, but for the purpose of initialising
> > one's repository that should be good enough. And the "git archive" can
> > be fully resumable as I explained.
>
> It is however only 2.5 MB out of 37 MB that are resumable, which is 7%
> (well, that of course depends on repository). Not that much that is
> resumable.
Take the Linux kernel then. It is more like 75 MB.
> > Now to deepen that history. Let's say you want 10 more revisions going
> > back then you simply perform the fetch again with a --depth=10. Right
> > now it doesn't seem to work optimally, but the pack that is then being
> > sent could be made of deltas against objects found in the commits we
> > already have. Currently it seems that a pack that also includes those
> > objects we already have in addition to those we want is created, which
> > is IMHO a flaw in the shallow support that shouldn't be too hard to fix.
> > Each level of deepening should then be as small as standard fetches
> > going forward when updating the repository with new revisions.
>
> You would have the same (or at least quite similar) problems with
> deepening part (the 'incrementals' transfer part) as you found with my
> first proposal of server bisection / division of rev-list, and serving
> 1/Nth of revisions (where N is selected so packfile is reasonable) to
> client as incrementals. Yours is top-down, mine was bottom-up approach
> to sending series of smaller packs. The problem is how to select size
> of incrementals, and that incrementals are all-or-nothing (but see also
> comment below).
Yes and no. Combined with a slight reordering of commit objects, it
could be possible to receive a partial pack and still be able to extract
a bunch of full revisions. The biggest issue is to be able to transfer
revision x (75 MB for Linux), but revision x-1 usually requires only a
few kilobytes, revision x-2 a few other kilobytes, etc. Remember that
you are likely to have only a few deltas from one revision to another,
which is not the case for the very first revision you get. A special
mode to pack-object could place commit objects only after all the
objects needed to create that revision. So once you get a commit object
on the receiving end, you could assume that all objects reachable from
that commit are already received, or you had them locally already.
> In proposal using git-archive and shallow clone deepening as incrementals
> you have this small seed (how small it depends on repository: 50% - 5%)
> which is resumable. And presumably with deepening you can somehow make
> some use from incomplete packfile, only part of which was transferred
> before network error / disconnect. And even tell server about objects
> which you managed to extract from *.pack.part.
yes. And at that point resuming the transfer is just another case of
shallow repository deepening.
> *NEW IDEA*
>
> Another solution would be to try to come up with some sort of stable
> sorting of objects so that packfile generated for the same parameters
> (endpoints) would be always byte-for-byte the same. But that might be
> difficult, or even impossible.
And I don't want to commit to that either. Having some flexibility in
object ordering makes it possible to improve on the packing heuristics.
We certainly should avoid imposing strong restrictions like that for
little gain. Even the deltas are likely to be different from one
request to another when using threads as one thread might be getting
more CPU time than another slightly modifying the outcome.
> Well, we could send the list of objects in pack in order used later by
> pack creation to client (non-resumable but small part), and if packfile
> transport was interrupted in the middle client would compare list of
> complete objects in part of packfile against this manifest, and sent
> request to server with *sorted* list of object it doesn't have yet.
Well... actually that's one of the item for pack V4. Lots of SHA1s are
duplicated in tree and commit objects, in addition to the pack index
file. With pack v4 all those SHA1s would be stored only once in a table
and objects would index that table instead.
Still, that is not _that_ small though. Just look at the size of the
pack index file for the Linux repository to give you an idea.
> Server would probably have to check validity of objects list first (the
> object list might be needed to be more than just object list; it might
> need to specify topology of deltas, i.e. which objects are base for which
> ones). Then it would generate rest of packfile.
I'm afraid that has the looks of something adding lots of complexity to
a piece of git that is already quite complex already, namely
pack-objects. And there is already only a few individuals with their
brain around it.
> > > It would be useful if it was possible to generate part of this rock-solid
> > > file for partial (range, resume) request, without need to generate
> > > (calculate) parts that client already downloaded. Otherwise server has
> > > to either waste disk space and IO for caching, or waste CPU (and IO)
> > > on generating part which is not needed and dropping it to /dev/null.
> > > git-archive you say has this feature.
> >
> > "Could easily have" is more appropriate.
>
> O.K. And I can see how this can be easy done.
>
> > > Next you need to tell server that you have those objects got using
> > > resumable download part ("git archive HEAD" in your proposal), and
> > > that it can use them and do not include them in prepared file/pack.
> > > "have" is limited to commits, and "have <sha1>" tells server that
> > > you have <sha1> and all its prerequisites (dependences). You can't
> > > use "have <sha1>" with git-archive solution. I don't know enough
> > > about 'shallow' capability (and what it enables) to know whether
> > > it can be used for that. Can you elaborate?
> >
> > See above, or Documentation/technical/shallow.txt.
>
> Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
> and "deepen" commands from 'shallow' capability extension to git pack
> protocol (http://git-scm.com/gitserver.txt).
404 Not Found
Maybe that should be committed to git in Documentation/technical/ as
well?
> > > Then you have to finish clone / fetch. All solutions so far include
> > > some kind of incremental improvements. My first proposal of bisect
> > > fetching 1/nth or predefined size pack is buttom-up solution, where
> > > we build full clone from root commits up. You propose, from what
> > > I understand build full clone from top commit down, using deepening
> > > from shallow clone. In this step you either get full incremental
> > > or not; downloading incremental (from what I understand) is not
> > > resumable / they do not support partial fetch.
> >
> > Right. However, like I said, the incremental part should be much
> > smaller and therefore less susceptible to network troubles.
>
> If you have 7% total pack size of git-archive resumable part, how small
> do you plan to have those incremental deepening? Besides in my 1/Nth
> proposal those bottom-up packs werealso meant to be sufficiently small
> to avoid network troubles.
Two issues here: 1) people with slow links might not be interested in a
deep history as it costs them time. 2) Extra revisions should typically
require only a few KB each, therefore we might manage to ask for the
full history after the initial revision is downloaded and salvage as
much as we can if a network outage is encountered. There is no need for
arbitrary size, unless the user decides arbitrarily to get only 10 more
revisions, or 100 more, etc.
> P.S. As you can see implementing resumable clone isn't easy...
I've been saying that all along for quite a while now. ;-)
Nicolas
^ permalink raw reply
* [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Thomas Rast @ 2009-08-20 22:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Björn Steinbrink, Abhijit Menon-Sen
Ideally, we'd like 'git diff C^!' to show the same diff that 'git show C'
does (with log.showroot enabled). This gives easy access to a readable
diff for the commit, irrespective of how many parents it has and without
any trickery to remove the commit message from the git-show output.
cmd_diff relied on telling the various diff invocations apart from
only the number of revisions parsed by setup_revision() (with a twist
for A...B). In the case of C^! this failed on two counts:
* If C has no parents, setup_revision() turns C^! into simply C. This
meant that 'git diff C^!' compared the current worktree to C, which
is certainly not what the user asked for.
* Otherwise setup_revision puts C itself last, i.e., the rev.pending
are ^C^1 ... ^C^N C. So the first revision is uninteresting and in
the case of exactly two parents, the symmetric difference revspec
(diff A...B) case fired, and compared C only to C^1 (instead of
showing a combined diff).
Detect the presence of A...B or C^! style arguments before running
setup_revisions(), so that we know in which case we are in. We can
then dispatch to the right case without peeking at UNINTERESTING
flags.
There's still some complication in builtin_diff_combined() because
0fe7c1d (built-in diff: assorted updates., 2006-04-29) advertises that
'git diff T0 T1 ... Tn' does a combined diff of arbitrary trees where T0
is the merge result, so we have to handle both this case and C^!.
Note that UNINTERESTING is not a good criterion at all, as it is
tacked onto *trees*; if any of the involved revisions share the same
trees, the flags will overwrite each other.
Thanks to Abhijit "crab" Menon-Sen for noticing that 'diff C^!' didn't
work as expected on root commits, and Björn "doener" Steinbrink for
helpful discussions.
---
Error checking is still iffy, but I'm not sure that can be fixed
without throwing out the whole "argument parsing through
setup_revisions" code and handrolling it.
Documentation/git-diff.txt | 10 +++++++-
builtin-diff.c | 54 +++++++++++++++++++++++++++++++++++-------
t/t4013-diff-various.sh | 3 ++
t/t4013/diff.diff_initial^! | 28 ++++++++++++++++++++++
t/t4013/diff.diff_master^! | 29 +++++++++++++++++++++++
t/t4013/diff.diff_side^! | 32 +++++++++++++++++++++++++
6 files changed, 146 insertions(+), 10 deletions(-)
create mode 100644 t/t4013/diff.diff_initial^!
create mode 100644 t/t4013/diff.diff_master^!
create mode 100644 t/t4013/diff.diff_side^!
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 0ac7112..5d0f2a6 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -62,9 +62,17 @@ forced by --no-index.
"git diff $(git-merge-base A B) B". You can omit any one
of <commit>, which has the same effect as using HEAD instead.
+'git diff' [--options] <commit>^{caret}! [--] [<path>...]::
+
+ This shows the changes that <commit> made relative to its
+ parents. For an ordinary commit it is the same as `git diff
+ <commit>{caret} <commit>`. For a root commit it shows a
+ creation patch and for a merge commit it shows a combined
+ diff.
+
Just in case if you are doing something exotic, it should be
noted that all of the <commit> in the above description, except
-for the last two forms that use ".." notations, can be any
+for the two forms that use ".." notations, can be any
<tree-ish>.
For a more complete list of ways to spell <commit>, see
diff --git a/builtin-diff.c b/builtin-diff.c
index ffcdd05..285bf29 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -163,10 +163,17 @@ static int builtin_diff_tree(struct rev_info *revs,
return 0;
}
+enum diff_mode {
+ DIFF_MODE_NORMAL,
+ DIFF_MODE_SYMMETRIC,
+ DIFF_MODE_SHOW
+};
+
static int builtin_diff_combined(struct rev_info *revs,
int argc, const char **argv,
struct object_array_entry *ent,
- int ents)
+ int ents,
+ enum diff_mode mode)
{
const unsigned char (*parent)[20];
int i;
@@ -177,8 +184,18 @@ static int builtin_diff_combined(struct rev_info *revs,
if (!revs->dense_combined_merges && !revs->combine_merges)
revs->dense_combined_merges = revs->combine_merges = 1;
parent = xmalloc(ents * sizeof(*parent));
- for (i = 0; i < ents; i++)
- hashcpy((unsigned char *)(parent + i), ent[i].item->sha1);
+
+ if (mode == DIFF_MODE_SHOW) {
+ /* diff C^!, we exploit knowledge that C is last */
+ for (i = 1; i < ents; i++)
+ hashcpy((unsigned char *)(parent + i),
+ ent[i-1].item->sha1);
+ hashcpy((unsigned char *)(parent),
+ ent[ents-1].item->sha1);
+ } else {
+ for (i = 0; i < ents; i++)
+ hashcpy((unsigned char *)(parent + i), ent[i].item->sha1);
+ }
diff_tree_combined(parent[0], parent + 1, ents - 1,
revs->dense_combined_merges, revs);
return 0;
@@ -254,6 +271,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
struct blobinfo blob[2];
int nongit;
int result = 0;
+ enum diff_mode mode = DIFF_MODE_NORMAL;
/*
* We could get N tree-ish in the rev.pending_objects list.
@@ -292,6 +310,17 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ for (i = 1; i < argc; i++) {
+ if (prefixcmp(argv[i], "--")) {
+ if (strstr(argv[i], "..."))
+ mode = DIFF_MODE_SYMMETRIC;
+ else if (strstr(argv[i], "^!"))
+ mode = DIFF_MODE_SHOW;
+ } else if (!strcmp(argv[i], "--")) {
+ break;
+ }
+ }
+
/* Default to let external and textconv be used */
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
@@ -403,11 +432,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
}
else if (blobs)
usage(builtin_diff_usage);
- else if (ents == 1)
- result = builtin_diff_index(&rev, argc, argv);
- else if (ents == 2)
- result = builtin_diff_tree(&rev, argc, argv, ent);
- else if ((ents == 3) && (ent[0].item->flags & UNINTERESTING)) {
+ else if (mode == DIFF_MODE_SYMMETRIC) {
/* diff A...B where there is one sane merge base between
* A and B. We have ent[0] == merge-base, ent[1] == A,
* and ent[2] == B. Show diff between the base and B.
@@ -415,9 +440,20 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
ent[1] = ent[2];
result = builtin_diff_tree(&rev, argc, argv, ent);
}
+ else if (ents == 1 && mode == DIFF_MODE_SHOW) {
+ /* diff R^! where R is a root commit: creation patch */
+ diff_tree_sha1((const unsigned char *) EMPTY_TREE_SHA1_BIN,
+ ent[0].item->sha1, "", &rev.diffopt);
+ log_tree_diff_flush(&rev);
+ result = 0;
+ }
+ else if (ents == 1)
+ result = builtin_diff_index(&rev, argc, argv);
+ else if (ents == 2)
+ result = builtin_diff_tree(&rev, argc, argv, ent);
else
result = builtin_diff_combined(&rev, argc, argv,
- ent, ents);
+ ent, ents, mode);
result = diff_result_code(&rev.diffopt, result);
if (1 < rev.diffopt.skip_stat_unmatch)
refresh_index_quietly();
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 8b33321..2ce7204 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -273,6 +273,9 @@ diff --no-index --name-status -- dir2 dir
diff --no-index dir dir3
diff master master^ side
diff --dirstat master~1 master~2
+diff initial^!
+diff side^!
+diff master^!
EOF
test_done
diff --git a/t/t4013/diff.diff_initial^! b/t/t4013/diff.diff_initial^!
new file mode 100644
index 0000000..22f6bb7
--- /dev/null
+++ b/t/t4013/diff.diff_initial^!
@@ -0,0 +1,28 @@
+$ git diff initial^!
+diff --git a/dir/sub b/dir/sub
+new file mode 100644
+index 0000000..35d242b
+--- /dev/null
++++ b/dir/sub
+@@ -0,0 +1,2 @@
++A
++B
+diff --git a/file0 b/file0
+new file mode 100644
+index 0000000..01e79c3
+--- /dev/null
++++ b/file0
+@@ -0,0 +1,3 @@
++1
++2
++3
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..01e79c3
+--- /dev/null
++++ b/file2
+@@ -0,0 +1,3 @@
++1
++2
++3
+$
diff --git a/t/t4013/diff.diff_master^! b/t/t4013/diff.diff_master^!
new file mode 100644
index 0000000..ca2eaa1
--- /dev/null
+++ b/t/t4013/diff.diff_master^!
@@ -0,0 +1,29 @@
+$ git diff master^!
+diff --cc dir/sub
+index cead32e,7289e35..992913c
+--- a/dir/sub
++++ b/dir/sub
+@@@ -1,6 -1,4 +1,8 @@@
+ A
+ B
+ +C
+ +D
+ +E
+ +F
++ 1
++ 2
+diff --cc file0
+index b414108,f4615da..10a8a9f
+--- a/file0
++++ b/file0
+@@@ -1,6 -1,6 +1,9 @@@
+ 1
+ 2
+ 3
+ +4
+ +5
+ +6
++ A
++ B
++ C
+$
diff --git a/t/t4013/diff.diff_side^! b/t/t4013/diff.diff_side^!
new file mode 100644
index 0000000..6d4378a
--- /dev/null
+++ b/t/t4013/diff.diff_side^!
@@ -0,0 +1,32 @@
+$ git diff side^!
+diff --git a/dir/sub b/dir/sub
+index 35d242b..7289e35 100644
+--- a/dir/sub
++++ b/dir/sub
+@@ -1,2 +1,4 @@
+ A
+ B
++1
++2
+diff --git a/file0 b/file0
+index 01e79c3..f4615da 100644
+--- a/file0
++++ b/file0
+@@ -1,3 +1,6 @@
+ 1
+ 2
+ 3
++A
++B
++C
+diff --git a/file3 b/file3
+new file mode 100644
+index 0000000..7289e35
+--- /dev/null
++++ b/file3
+@@ -0,0 +1,4 @@
++A
++B
++1
++2
+$
--
1.6.4.363.g2183a
^ permalink raw reply related
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Junio C Hamano @ 2009-08-20 22:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <86d1201d8adf53c1f48c0f3526d8e81475b18244.1250806019.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Ideally, we'd like 'git diff C^!' to show the same diff that 'git show C'
> does (with log.showroot enabled). This gives easy access to a readable
> diff for the commit, irrespective of how many parents it has and without
> any trickery to remove the commit message from the git-show output.
Not interested yet, as the "git show" discussion is not convincing at all.
Is the message annoying enough to warrant this change?
If that is indeed the case and if it is a common thing to ask, isn't it
more productive to teach "show" a way to do so in a simpler way than
doing, say,
$ git show --pretty=format: HEAD
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Jeff King @ 2009-08-20 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <7vab1up1gz.fsf@alter.siamese.dyndns.org>
On Thu, Aug 20, 2009 at 03:25:16PM -0700, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > Ideally, we'd like 'git diff C^!' to show the same diff that 'git show C'
> > does (with log.showroot enabled). This gives easy access to a readable
> > diff for the commit, irrespective of how many parents it has and without
> > any trickery to remove the commit message from the git-show output.
>
> Not interested yet, as the "git show" discussion is not convincing at all.
>
> Is the message annoying enough to warrant this change?
I thought the same thing when I saw his message, but reading further,
the current output is nonsensical. So if not this patch, we should
probably at least complain about bogus input and die (though if it is
easy to make it work, why not...).
-Peff
^ permalink raw reply
* Re: [PATCH JGIT] Ensure created test repositories use canonical paths
From: Robin Rosenberg @ 2009-08-20 22:35 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Shawn O. Pearce, git
In-Reply-To: <1250687891-17916-1-git-send-email-fonseca@diku.dk>
onsdag 19 augusti 2009 15:18:11 skrev Jonas Fonseca <fonseca@diku.dk>:
> Fixes breakage in the RepositoryCacheTest when running tests using:
>
> mvn -f ./jgit-maven/jgit/pom.xml test
>
> which in turn will lead to test repositories using paths, such as:
>
> /path/to/jgit/./jgit-maven/jgit/trash/trash1250647279819.186/.git
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> .../org/spearce/jgit/lib/RepositoryTestCase.java | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
> index b1adde9..d1aef78 100644
> --- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
> @@ -217,7 +217,7 @@ public void setUp() throws Exception {
> final String name = getClass().getName() + "." + getName();
> recursiveDelete(trashParent, true, name, false); // Cleanup old failed stuff
> trash = new File(trashParent,"trash"+System.currentTimeMillis()+"."+(testcount++));
> - trash_git = new File(trash, ".git");
> + trash_git = new File(trash, ".git").getCanonicalFile();
> if (shutdownhook == null) {
> shutdownhook = new Thread() {
> @Override
> @@ -307,7 +307,7 @@ protected Repository createNewEmptyRepo() throws IOException {
> protected Repository createNewEmptyRepo(boolean bare) throws IOException {
> final File newTestRepo = new File(trashParent, "new"
> + System.currentTimeMillis() + "." + (testcount++)
> - + (bare ? "" : "/") + ".git");
> + + (bare ? "" : "/") + ".git").getCanonicalFile();
> assertFalse(newTestRepo.exists());
> final Repository newRepo = new Repository(newTestRepo);
> newRepo.create();
We use getCanonicalFile here and Repository.gitDir is initialized with getAbsoluteDir. Does this work on all platforms?
Seems linux normalized things when you do things like, but I'm not sure that happens everywhere.
ln -s JGIT x;cd x;pwd;jev 'System.out.println(System.getProperty("user.dir"));'
/home/me/SW/x
/home/me/SW/JGIT
-- robin
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Thomas Rast @ 2009-08-20 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <7vab1up1gz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > Ideally, we'd like 'git diff C^!' to show the same diff that 'git show C'
> > does (with log.showroot enabled). This gives easy access to a readable
> > diff for the commit, irrespective of how many parents it has and without
> > any trickery to remove the commit message from the git-show output.
>
> Not interested yet, as the "git show" discussion is not convincing at all.
Well, it is currently half-supported, diff doesn't complain about it,
yet it does something wildly different from what people expect in the
zero- and two-parent cases.
And yes, people expect this to work; searching the #git logs (I won't
link here as it takes a fair while even for one request) shows that
people such as Dscho, Thiago, Jakub and Björn have recommended this
syntax in the context of diff.
> Is the message annoying enough to warrant this change?
>
> If that is indeed the case and if it is a common thing to ask, isn't it
> more productive to teach "show" a way to do so in a simpler way than
> doing, say,
>
> $ git show --pretty=format: HEAD
That still doesn't get rid of the stray newline.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Continue git clone after interruption
From: Sam Vilain @ 2009-08-20 22:57 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nicolas Pitre, Tomasz Kontusz, git, Johannes Schindelin,
nick edelen
In-Reply-To: <200908200937.05412.jnareb@gmail.com>
On Thu, 2009-08-20 at 09:37 +0200, Jakub Narebski wrote:
> You would have the same (or at least quite similar) problems with
> deepening part (the 'incrementals' transfer part) as you found with my
> first proposal of server bisection / division of rev-list, and serving
> 1/Nth of revisions (where N is selected so packfile is reasonable) to
> client as incrementals. Yours is top-down, mine was bottom-up approach
> to sending series of smaller packs. The problem is how to select size
> of incrementals, and that incrementals are all-or-nothing (but see also
> comment below).
I've defined a way to do this which doesn't have the complexity of
bisect in GitTorrent, making the compromise that you can't guarantee
each chunk is exactly the same size... I'll have a crack at doing it
based on the rev-cache code in C instead of the horrendously slow
Perl/Berkeley solution I have at the moment to see how well it fares.
> Another solution would be to try to come up with some sort of stable
> sorting of objects so that packfile generated for the same parameters
> (endpoints) would be always byte-for-byte the same. But that might be
> difficult, or even impossible.
delta compression is not repeatable enough for this.
This was an assumption made by the first version of GitTorrent, that
this would be an appropriate solution.
So, first you have to sort the objects - that's fine, --date-order is a
good starting point, then I reasoned that interleaving new objects for
each commit with commit objects would be a useful sort order. You also
need to tie-break for commits with the same commit date; I just used the
SHA-1 of the commit for that. Finally, when making packs to avoid
excessive transfer you have to try to make sure that they are "thin"
packs.
Currently, thin packs can only work starting at the beginning of history
and working forward, which is opposite to what happens most of the time
in packs. I think this is the source of much of the inefficiency caused
by chopping up the object lists mentioned in my other e-mail. It might
be possible, if you could also know which earlier objects were using
this object as a delta base, to try delta'ing against all those objects
and see which one results in the smallest delta.
> Well, we could send the list of objects in pack in order used later by
> pack creation to client (non-resumable but small part), and if packfile
> transport was interrupted in the middle client would compare list of
> complete objects in part of packfile against this manifest, and sent
> request to server with *sorted* list of object it doesn't have yet.
> Server would probably have to check validity of objects list first (the
> object list might be needed to be more than just object list; it might
> need to specify topology of deltas, i.e. which objects are base for which
> ones). Then it would generate rest of packfile.
Mmm. It's a bit chatty, that. Object lists add another 10-20% on,
which I think should be avoidable if the thin pack problem, plus the
problem of some objects ending up in more than one of the thin packs
that are created, should be reduced to very little.
Sam
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Junio C Hamano @ 2009-08-20 23:01 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, git, Björn Steinbrink,
Abhijit Menon-Sen
In-Reply-To: <20090820223424.GA5843@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Aug 20, 2009 at 03:25:16PM -0700, Junio C Hamano wrote:
>
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>> > Ideally, we'd like 'git diff C^!' to show the same diff that 'git show C'
>> > does (with log.showroot enabled). This gives easy access to a readable
>> > diff for the commit, irrespective of how many parents it has and without
>> > any trickery to remove the commit message from the git-show output.
>>
>> Not interested yet, as the "git show" discussion is not convincing at all.
>>
>> Is the message annoying enough to warrant this change?
>
> I thought the same thing when I saw his message, but reading further,
> the current output is nonsensical. So if not this patch, we should
> probably at least complain about bogus input and die (though if it is
> easy to make it work, why not...).
Ok.
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Junio C Hamano @ 2009-08-20 23:03 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <200908210042.05802.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> If that is indeed the case and if it is a common thing to ask, isn't it
>> more productive to teach "show" a way to do so in a simpler way than
>> doing, say,
>>
>> $ git show --pretty=format: HEAD
>
> That still doesn't get rid of the stray newline.
And the reason you don't want that newline, especially when you know there
always is one so if you really wanted to you could easily sed it out,
is...?
^ permalink raw reply
* Re: [PATCH 3/6] Make diff -w handle trailing-spaces on incomplete lines.
From: Thell Fowler @ 2009-08-20 23:09 UTC (permalink / raw)
To: Thell Fowler; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.2.00.0908191725440.2012@GWPortableVCS>
Thell Fowler (git@tbfowler.name) wrote on Aug 19, 2009:
> - When processing trailing spaces with --ignore-all-space a diff
> would be found whenever one side had 0 spaces and either (or both)
> sides was an incomplete line. xdl_recmatch should process the
> full length of the record instead of assuming both sides have a
> terminator.
>
> @@ -191,14 +191,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
> int i1, i2;
>
> if (flags & XDF_IGNORE_WHITESPACE) {
> - for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
> + for (i1 = i2 = 0; i1 <= s1 && i2 <= s2; ) {
> if (isspace(l1[i1]))
> - while (isspace(l1[i1]) && i1 < s1)
> + while (isspace(l1[i1]) && i1 <= s1)
The change from '<' to <=' obviously did do jack-diddly-squat, which I
should have noticed earlier.
> i1++;
> if (isspace(l2[i2]))
> - while (isspace(l2[i2]) && i2 < s2)
> + while (isspace(l2[i2]) && i2 <= s2)
Here too.
> i2++;
> - if (i1 < s1 && i2 < s2 && l1[i1++] != l2[i2++])
> + if (i1 <= s1 && i2 <= s2 && l1[i1++] != l2[i2++])
> return 0;
> }
> return (i1 >= s1 && i2 >= s2);
>
Those will be corrected for v2.
--
Thell
^ permalink raw reply
* Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache
From: Nick Edelen @ 2009-08-20 23:22 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908200543h74fdb07dm7f30cee4fedef8c5@mail.gmail.com>
Ok we actually have a small problem, semi-related to the object
listing. By default rev-list will list everything not seen in each
tree, whereas rev-cache will only list object introduced in a given
commit. This becomes problematic if you have two different files with
the same content in the same tree: rev-cache will show the name of the
youngest file; vanilla rev-list will list the name soonest encountered
in the tree (which can even change if, e.g., a subdir is renamed so as
to be list in a different order).
In fact, even if they're not in the same tree we could have a similar
problem. Commits are stored topologically in cache slices, so output
is always in topo order. If the same object is introduced in parallel
branches under different names, the outputted name with `rev-list
--all --objects` (vanilla) could be different from `rev-list --all
--objects` (cached) could be different from `rev-list --all
--topo-order --objects`.
This isn't feasably changable in rev-cache, as a) the cached position
(and hence final output order) is effectively unrelated to tree
structure, and b) commits _have_ to be ordered topologically for
rev-cache to function.
The descrepency strikes me as something of a non-issue with
pack-objects' deltafication, as the object will fit with either of its
names. It will mean that the (already sorta finicky) object names
won't have garuanteed consistency between cached/non-cached calls to
rev-list. This is something of a corner case and dosn't strike me as
a huge issue, but I figured I should consult you all before presuming
things about git's interface.
- Nick
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Junio C Hamano @ 2009-08-20 23:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <86d1201d8adf53c1f48c0f3526d8e81475b18244.1250806019.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> * If C has no parents, setup_revision() turns C^! into simply C. This
> meant that 'git diff C^!' compared the current worktree to C, which
> is certainly not what the user asked for.
>
> * Otherwise setup_revision puts C itself last, i.e., the rev.pending
> are ^C^1 ... ^C^N C. So the first revision is uninteresting and in
> the case of exactly two parents, the symmetric difference revspec
> (diff A...B) case fired, and compared C only to C^1 (instead of
> showing a combined diff).
I actually have a vague recollection that this ugly syntax C^! (and I am
entitled to call it ugly as it was my invention) was advertised as a way
to get "diff C^..C", not the combined diff, iow, this could be deliberate
and people may depend on it.
In that light, I would say the first one (showing the root commit as root)
may be a good change, but the latter one is moderately iffy.
> @@ -292,6 +310,17 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
> /* Otherwise, we are doing the usual "git" diff */
> rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
>
> + for (i = 1; i < argc; i++) {
> + if (prefixcmp(argv[i], "--")) {
> + if (strstr(argv[i], "..."))
> + mode = DIFF_MODE_SYMMETRIC;
> + else if (strstr(argv[i], "^!"))
> + mode = DIFF_MODE_SHOW;
> + } else if (!strcmp(argv[i], "--")) {
> + break;
> + }
> + }
> +
This is too ugly beyond words.
We already mark the left side commit "..." with SYMMETRIC_LEFT bit, so you
should be able to detect it from the setup_revisions() result. If we were
to formerly add some special meaning (other than being a short-hand of
^C^n C) to the ugly C^! syntax, I would suggest marking the result of in a
similar way to allow you to detect it from the result.
But I do mean moderately strong negativeness when I say "if we _were_"
above.
As far as I recall, there were only two reasons C^! was invented for
(actually, one that was invented for, and another that was found to be
useful).
One was so that you can say "The traversal should stop around this commit,
but I want the commit itself to be included in the result".
$ git log v1.6.3^! v1.6.3.1
This is much less useful than it used to be back when C^! was invented, as
we can ask for --boundary these days.
The other utility later found was "to view diff with its first parent". I
think it is a useful mode of operation, and we should add a simpler way to
ask for it to "git show", as people often ask to view a merge not in the
combined way, but a simple diff relative to the merged-to commit, to get
an overview of the work done by the side branch.
So if anything, I'm actually for deprecating C^! syntax and removing it
before we hit 1.7.0.
^ permalink raw reply
* Issue with gitweb + tag + branch of the same name from master branch commit
From: Nicholas A. Bellinger @ 2009-08-20 23:30 UTC (permalink / raw)
To: git; +Cc: J.H., H. Peter Anvin
Greetings git folks,
I have recently been trying to make a tag and branch of the same name
from a previous <COMMIT> on a master branch on a kernel.org tree using
the following commands:
# Create the tag:
git tag -a lio-x.y <COMMIT>
# Push the tags:
git push --tags origin
# Fetch to be sure
git fetch origin
# Make tagged branch:
git checkout -b lio-x.y <COMMIT>
# Make <NEW_COMMIT> to lio-x.y and commit
git commit frob
# Switch back to master branch
git checkout master
# Push local branch to origin
git push origin refs/heads/lio-x.y
At this point after pushing to origin, I can do a fresh clone of the
tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
and the logs and blobs look as expected..
However, after checking gitweb log for branch lio-x.y on kernel.org, I
only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
lio-x.y still reference the original <COMMIT>, et al.
John Hawley has been helping to resolve the issue (I am just going to
use different tag/branch names instead), and hpa asked me to report this
as it is easy to reproduce with the gitweb version on kernel.org..
Here is a bit of the IRC log:
22:30 < nab> Hmm, I wonder if the fact that I was tagging a commit from master, and then branching using the same
commit ID to a tag of the same name as the branch..?
22:33 < warthog9> not use the same name, I think what your doing is fine just the identical naming is whats
causing the problem
22:33 < warthog9> like tag-lio-3.0
22:33 < nab> Ahhhhhh
22:33 < warthog9> and branch: lio-3.0
22:34 < warthog9> since I think somewhere in git it's got two different orders of preference for tag vs. branch
22:34 < nab> Ok, so I should just delete the branch and tags and redo with diff names..?
22:34 < warthog9> one operation is using the tag, one is using the branch and we are seeing the conflicting
results
<SNIP> warthog9 makes somechanges to git repo with gitweb issues </SNIP>
22:40 < warthog9> that *looks* right to me now?
22:40 < nab> Yep, looks correct
22:41 < warthog9> so yeah, git is getting confused
22:41 < warthog9> ok so my theory is right, it's getting confused between the tag / branch
22:41 < nab> the blob for the ./autoconfigure is correct as well..
22:42 < nab> Ok, I have no problem using different names.. :-)
22:42 < warthog9> I would got show this to the git people, it *could* just be an old bug in gitweb (ours is not
particularly up to date) but if I can replicate it here easily enough I'm guessing there's
still a bug elsewhere
Many thanks for your most valuable of time,
--nab
^ permalink raw reply
* Re: [PATCH] Make 'diff C^!' show the same diff as 'show C'
From: Junio C Hamano @ 2009-08-20 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Björn Steinbrink, Abhijit Menon-Sen
In-Reply-To: <7vocqanjua.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We already mark the left side commit "..." with SYMMETRIC_LEFT bit, so you
> should be able to detect it from the setup_revisions() result. If we were
> to formerly add some special meaning (other than being a short-hand of
blush. I meant "formally".
> ^C^n C) to the ugly C^! syntax, I would suggest marking the result of in a
> similar way to allow you to detect it from the result.
>
> But I do mean moderately strong negativeness when I say "if we _were_"
> above.
^ permalink raw reply
* Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache
From: Nicolas Pitre @ 2009-08-21 0:05 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908201622o7d69681ftda0ca63c5a915f4b@mail.gmail.com>
On Fri, 21 Aug 2009, Nick Edelen wrote:
> Ok we actually have a small problem, semi-related to the object
> listing. By default rev-list will list everything not seen in each
> tree, whereas rev-cache will only list object introduced in a given
> commit. This becomes problematic if you have two different files with
> the same content in the same tree: rev-cache will show the name of the
> youngest file; vanilla rev-list will list the name soonest encountered
> in the tree (which can even change if, e.g., a subdir is renamed so as
> to be list in a different order).
>
> In fact, even if they're not in the same tree we could have a similar
> problem. Commits are stored topologically in cache slices, so output
> is always in topo order. If the same object is introduced in parallel
> branches under different names, the outputted name with `rev-list
> --all --objects` (vanilla) could be different from `rev-list --all
> --objects` (cached) could be different from `rev-list --all
> --topo-order --objects`.
>
> This isn't feasably changable in rev-cache, as a) the cached position
> (and hence final output order) is effectively unrelated to tree
> structure, and b) commits _have_ to be ordered topologically for
> rev-cache to function.
>
> The descrepency strikes me as something of a non-issue with
> pack-objects' deltafication, as the object will fit with either of its
> names. It will mean that the (already sorta finicky) object names
> won't have garuanteed consistency between cached/non-cached calls to
> rev-list. This is something of a corner case and dosn't strike me as
> a huge issue, but I figured I should consult you all before presuming
> things about git's interface.
The name is actually used only as a clue to delta similar objects
together. So this is indeed a non issue, as long as the discrepency is
well understood and, more importantly, properly documented. The above
is certainly a good start.
Nicolas
^ permalink raw reply
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
From: Junio C Hamano @ 2009-08-21 0:19 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: git, J.H., H. Peter Anvin
In-Reply-To: <1250811031.26147.42.camel@haakon2.linux-iscsi.org>
"Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
> 22:33 < warthog9> not use the same name, I think what your doing is fine just the identical naming is whats
> causing the problem
> 22:33 < warthog9> like tag-lio-3.0
> 22:33 < nab> Ahhhhhh
> 22:33 < warthog9> and branch: lio-3.0
> 22:34 < warthog9> since I think somewhere in git it's got two different orders of preference for tag vs. branch
I do not speak for gitweb but we typically favor tags over heads. The
only place "branch name" take precedence is where the command expects to
see a name of a branch, when it can also take any arbitrary object name,
and changes behaviour. I.e. "git checkout X", when X is a branch name,
checks out the branch so that the next commit advances the tip of that
branch.
^ permalink raw reply
* Re: [PATCH v2] Fix symlink __stdcall problem at MSVC
From: Frank Li @ 2009-08-21 2:42 UTC (permalink / raw)
To: git, msysgit, Johannes Schindelin; +Cc: Frank Li
In-Reply-To: <1250778072-4324-1-git-send-email-lznuaa@gmail.com>
>
> int symlink(const char *oldpath, const char *newpath)
> {
> - typedef BOOL WINAPI (*symlink_fn)(const char*, const char*, DWORD);
> + typedef BOOL (WINAPI *symlink_fn)(const char*, const char*, DWORD);
> static symlink_fn create_symbolic_link = NULL;
> if (!create_symbolic_link) {
> create_symbolic_link = (symlink_fn) GetProcAddress(
> --
> 1.6.4.msysgit.0
>
This is new patch for latest devel branch mingw.c.
^ permalink raw reply
* What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 2:48 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
--------------------------------------------------
[New Topics]
* aj/fix-read-tree-from-scratch (2009-08-17) 1 commit
(merged to 'next' on 2009-08-20 at 7a04133)
+ read-tree: Fix regression with creation of a new index file.
* as/maint-graph-interesting-fix (2009-08-18) 1 commit.
- graph API: fix bug in graph_is_interesting()
* jc/1.7.0-status (2009-08-15) 7 commits
- git-status: adjust tests
- git status: not "commit --dry-run" anymore
- git stat -s: short status output
- git stat: pathspec limits, unlike traditional "git status"
- git stat: show traditional status headers and trailers as well
- git stat: honor relative paths setting
- git stat: the beginning
(this branch uses jc/shortstatus.)
* jc/maint-checkout-index-to-prefix (2009-08-16) 1 commit
(merged to 'next' on 2009-08-20 at 2f6aea2)
+ check_path(): allow symlinked directories to checkout-index --prefix
* jc/maint-unpack-objects-strict (2009-08-13) 1 commit.
- Fix "unpack-objects --strict"
* jh/submodule-foreach (2009-08-20) 9 commits
(merged to 'next' on 2009-08-20 at 671bea4)
+ git clone: Add --recursive to automatically checkout (nested) submodules
+ t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
(merged to 'next' on 2009-08-18 at f4a881d)
+ git submodule status: Add --recursive to recurse into nested submodules
+ git submodule update: Introduce --recursive to update nested submodules
+ git submodule foreach: Add --recursive to recurse into nested submodules
+ git submodule foreach: test access to submodule name as '$name'
+ Add selftest for 'git submodule foreach'
+ git submodule: Cleanup usage string and add option parsing to cmd_foreach()
+ git submodule foreach: Provide access to submodule name, as '$name'
* jl/submodule-summary-diff-files (2009-08-15) 2 commits
(merged to 'next' on 2009-08-15 at 165bd8e)
+ Documentaqtion/git-submodule.txt: Typofix
(merged to 'next' on 2009-08-14 at a702e78)
+ git submodule summary: add --files option
* lh/short-decorate (2009-08-15) 1 commit
(merged to 'next' on 2009-08-18 at b8c1d96)
+ git-log: allow --decorate[=short|full]
* oa/stash-na (2009-08-11) 1 commit
(merged to 'next' on 2009-08-14 at 12c2e2b)
+ git stash: Give friendlier errors when there is nothing to apply
* sr/gfi-options (2009-08-13) 3 commits
- fast-import: test the new option command
- fast-import: add option command
- fast-import: put option parsing code in seperate functions
--------------------------------------------------
[Graduated to "master"]
* bc/maint-am-email (Thu Aug 6 20:08:13 2009 -0500) 2 commits
+ git-am: print fair error message when format detection fails
+ am: allow individual e-mail files as input
It seems that the "not mbox but a single piece of e-mail" format was
something many people relied on. Hopefully this can also be sent
to 'maint'.
* js/maint-cover-letter-non-ascii (Mon Aug 10 18:22:22 2009 +0200) 2 commits
+ Correctly mark cover letters' encodings if they are not pure ASCII
+ Expose the has_non_ascii() function
* jk/maint-merge-msg-fix (Sun Aug 9 06:02:51 2009 -0400) 3 commits
+ merge: indicate remote tracking branches in merge message
+ merge: fix incorrect merge message for ambiguous tag/branch
+ add tests for merge message headings
* jc/maint-clean-nested-dir-safety (Tue Jun 30 15:33:45 2009 -0700) 1 commit
+ clean: require double -f options to nuke nested git repository and
work tree
--------------------------------------------------
[Stalled]
* cc/sequencer-rebase-i (2009-08-05) 8 commits.
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add comments about reset_almost_hard()
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: free memory used in "make_patch" function
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
More sequencer updates. I didn't look at the latest round that had a
handful "oops, fix that earlier botch" patches, expecting a cleaner
reroll (which hasn't happened yet).
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
* db/vcs-helper (2009-08-09) 17 commits
- Allow helpers to request marks for fast-import
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- transport-helper_init(): fix a memory leak in error path
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Use a clearer style to issue commands to remote helpers
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
There was a discussion that suggests that the use of colon ':' before vcs
helper name needs to be corrected. Nothing happened since.
* je/send-email-no-subject (2009-08-05) 1 commit
- send-email: confirm on empty mail subjects
This seems to break t9001. Near the tip of 'pu' I have a iffy
workaround.
--------------------------------------------------
[Cooking]
* ld/p4 (2009-07-30) 1 commit
(merged to 'next' on 2009-08-14 at 36d310d)
+ git-p4: stream from perforce to speed up clones
Should graduate to 'master' soon.
* mr/gitweb-xz (2009-08-06) 3 commits
(merged to 'next' on 2009-08-14 at b63b8e6)
+ gitweb: add support for XZ compressed snapshots
+ gitweb: update INSTALL regarding specific snapshot settings
+ gitweb: support to globally disable a snapshot format
Should graduate to 'master' soon.
* jh/cvs-helper (2009-08-18) 7 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package
in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
(this branch uses db/vcs-helper.)
Builds on db/vcs-helper. The testing of Python part seemed to be
still fragile even with the latest fix on one of my boches with an
earlier round already installed, but I didn't look very deeply before
removing the older installation.
* jc/verify-pack-stat (2009-08-07) 1 commit
(merged to 'next' on 2009-08-10 at f80d0e9)
+ verify-pack --stat-only: show histogram without verifying
* lt/block-sha1 (2009-08-17) 4 commits
(merged to 'next' on 2009-08-18 at 67a1ce8)
+ remove ARM and Mozilla SHA1 implementations
+ block-sha1: guard gcc extensions with __GNUC__
+ make sure byte swapping is optimal for git
+ block-sha1: make the size member first in the context struct
Finishing touches ;-) There were a few Solaris portability patches
floated around that I didn't pick up, waiting for them to finalize.
* nd/sparse (2009-08-11) 8 commits
. --sparse for porcelains
. Support sparse checkout in unpack_trees() and read-tree
. unpack-trees.c: generalize verify_* functions
. dir.c: export excluded_1() and add_excludes_from_file_1()
. excluded_1(): support exclude "directories" in index
. Read .gitignore from index if it is assume-unchanged
. Avoid writing to buffer in add_excludes_from_file_1()
(merged to 'next' on 2009-08-20 at ea167d7)
+ Prevent diff machinery from examining assume-unchanged entries on worktree
The first one was an independent fix; the rest will be discarded and
replaced with the "return of no-checkout" series.
* bc/mailsplit-cr-at-eol (2009-08-04) 4 commits
(merged to 'next' on 2009-08-06 at 6bc7c5c)
+ Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
+ builtin-mailsplit.c: remove read_line_with_nul() since it is no longer used
+ builtin-mailinfo,builtin-mailsplit: use strbufs
+ strbuf: add new function strbuf_getwholeline()
Will merge.
* gb/apply-ignore-whitespace (2009-08-04) 1 commit
(merged to 'next' on 2009-08-06 at 59e2c86)
+ git apply: option to ignore whitespace differences
Will merge.
* cc/replace (2009-05-27) 14 commits.
(merged to 'next' on 2009-08-02 at b9c4bc0)
+ t6050: check pushing something based on a replaced commit
+ Documentation: add documentation for "git replace"
+ Add git-replace to .gitignore
+ builtin-replace: use "usage_msg_opt" to give better error messages
+ parse-options: add new function "usage_msg_opt"
+ builtin-replace: teach "git replace" to actually replace
+ Add new "git replace" command
+ environment: add global variable to disable replacement
+ mktag: call "check_sha1_signature" with the replacement sha1
+ replace_object: add a test case
+ object: call "check_sha1_signature" with the replacement sha1
+ sha1_file: add a "read_sha1_file_repl" function
+ replace_object: add mechanism to replace objects found in "refs/replace/"
+ refs: add a "for_each_replace_ref" function
Will merge.
* jc/1.7.0-diff-whitespace-only-status (2009-05-23) 2 commits.
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
For 1.7.0. This changes exit code from "git diff --ignore-whitespace" and
friends when there is no actual output. It is a backward incompatible
change, but we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
For 1.7.0.
* jn/gitweb-blame (2009-08-06) 3 commits
- gitweb: Create links leading to 'blame_incremental' using JavaScript
- gitweb: Incremental blame (WIP)
- gitweb: Add optional "time to generate page" info in footer
* jc/shortstatus (2009-08-15) 11 commits
(merged to 'next' on 2009-08-15 at 7e40766)
+ git commit --dry-run -v: show diff in color when asked
+ Documentation/git-commit.txt: describe --dry-run
(merged to 'next' on 2009-08-12 at 53bda17)
+ wt-status: collect untracked files in a separate "collect" phase
+ Make git_status_config() file scope static to builtin-commit.c
+ wt-status: move wt_status_colors[] into wt_status structure
+ wt-status: move many global settings to wt_status structure
+ commit: --dry-run
(merged to 'next' on 2009-08-06 at fe8cb94)
+ status: show worktree status of conflicted paths separately
+ wt-status.c: rework the way changes to the index and work tree are summarized
+ diff-index: keep the original index intact
+ diff-index: report unmerged new entries
(this branch is used by jc/1.7.0-status.)
Will cook for a bit more and then merge.
* jh/notes (2009-07-29) 8 commits.
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- First draft of notes tree parser with support for fanout subtrees
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
The cvs-helper series depends on this one.
* tr/reset-checkout-patch (2009-08-18) 8 commits.
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
There was a discussion on better DWIMmery to (1) forbid "git stash save
--anything-with-dash" and (2) redirect with any option "git stash --opt"
to "git stash save --opt", to keep it flexible and safe at the same time.
I think it is a sane thing to do.
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
--------------------------------------------------
[I have been too busy to purge these]
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ne/rev-cache (2009-08-17) 6 commits
. support for path name caching of blobs/trees in rev-cache
. full integration of rev-cache into git's revision walker, completed test suite
. administrative functions for rev-cache, and start of integration into git
. non-commit object support for rev-cache
. bare minimum revision cache system, no integration with git
. revision caching documentation: man page and technical discussion
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
^ permalink raw reply
* Re: [PATCH v2] Fix symlink __stdcall problem at MSVC
From: Frank Li @ 2009-08-21 2:57 UTC (permalink / raw)
To: git, msysgit, Johannes Schindelin; +Cc: Frank Li
In-Reply-To: <1250778072-4324-1-git-send-email-lznuaa@gmail.com>
>
> int symlink(const char *oldpath, const char *newpath)
> {
> - typedef BOOL WINAPI (*symlink_fn)(const char*, const char*, DWORD);
> + typedef BOOL (WINAPI *symlink_fn)(const char*, const char*, DWORD);
> static symlink_fn create_symbolic_link = NULL;
> if (!create_symbolic_link) {
> create_symbolic_link = (symlink_fn) GetProcAddress(
> --
> 1.6.4.msysgit.0
>
This is new patch for latest devel branch mingw.c.
^ 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