Junio C Hamano writes:
> Heh, in 2008 we already had more than a few dozen.
>
> I think
>
> (1) It is perfectly OK to add an UI option to let the web visitor
> choose between simplified and full history at runtime,
> optionally with a new gitweb.conf opti
than a few dozen.
I think
(1) It is perfectly OK to add an UI option to let the web visitor
choose between simplified and full history at runtime,
optionally with a new gitweb.conf option to let the project
owner choose which one is the default;
(2) It is also OK to add gitweb.co
On Wed, Aug 5, 2015 at 6:54 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> When you look at the history for a file via "git log" we don't show
>> --full-history by default, but the Gitweb UI does so, which can be very
>> confusing fo
Ævar Arnfjörð Bjarmason writes:
> When you look at the history for a file via "git log" we don't show
> --full-history by default, but the Gitweb UI does so, which can be very
> confusing for all the reasons discussed in "History Simplification" in
> git-lo
When you look at the history for a file via "git log" we don't show
--full-history by default, but the Gitweb UI does so, which can be very
confusing for all the reasons discussed in "History Simplification" in
git-log(1) and in
http://thread.gmane.org/gmane.comp.versio
I'm trying to import our team's old subversion repository to git, but
I'd like to retain the commit history. I tried 'git svn clone' but
that only retrieves commits from the last copy onwards.
Because the svn setup is really bad, there is no way I can reproduce
the "stdlayout" structure that 'git
change, as if by "-s
ours", then:
git log -m -p --full-history -Schange file
would successfully locate "change"'s addition but would not locate the
merge that resolved against it.
Futher, simplify_merges could drop the actual parent that a commit
was TREESAME to, leav
;
note C &&
@@ -37,7 +40,9 @@ test_expect_success setup '
test_tick && git commit -m "Add another file" &&
note D &&
- test_tick && git merge -m "merge" master &&
+ test_tick &&
Kevin Bracey writes:
> On 06/05/2013 23:45, Junio C Hamano wrote:
>> Kevin Bracey writes:
>>
>>> +struct treesame_state {
>>> + unsigned int nparents;
>>> + unsigned char treesame[FLEX_ARRAY];
>>> +};
>> I have been wondering if we want to do one-bit (not one-byte) per
>> parent but no biggi
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey writes:
+struct treesame_state {
+ unsigned int nparents;
+ unsigned char treesame[FLEX_ARRAY];
+};
I have been wondering if we want to do one-bit (not one-byte) per
parent but no biggie ;-)
I did start down that path, beca
Kevin Bracey writes:
> diff --git a/revision.c b/revision.c
> index a67b615..c88ded8 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -429,10 +429,100 @@ static int rev_same_tree_as_empty(struct rev_info
> *revs, struct commit *commit)
> return retval >= 0 && (tree_difference == REV_TREE_
change, as if by "-s
ours", then:
git log -m -p --full-history -Schange file
would successfully locate "change"'s addition but would not locate the
merge that resolved against it.
Futher, simplify_merges could drop the actual parent that a commit
was TREESAME to, leav
;
note C &&
@@ -37,7 +40,9 @@ test_expect_success setup '
test_tick && git commit -m "Add another file" &&
note D &&
- test_tick && git merge -m "merge" master &&
+ test_tick &&
change, as if by "-s
ours", then:
git log -m -p --full-history -Schange file
would successfully locate "change"'s addition but would not locate the
merge that resolved against it.
Futher, simplify_merges could drop the actual parent that a commit
was TREESAME to, leav
;
note C &&
@@ -37,7 +40,9 @@ test_expect_success setup '
test_tick && git commit -m "Add another file" &&
note D &&
- test_tick && git merge -m "merge" master &&
+ test_tick &&
On 25/04/2013 21:19, Junio C Hamano wrote:
How many decorations are we talking about here? One for each merge
commit in the entire history? Do we have a cue that can tell us when
we are really done with a commit that lets us discard the associated
data as we go on digging, keeping the size of o
getting TREESAME precise is key.
>> It is perfectly fine to do things one step at a time. Let's get
>> the --full-history change into a good shape first and worry about
>> the more complex case after we are done.
>
> So do you see the rerun of try_to_simplify_commit() as
. Let's get
the --full-history change into a good shape first and worry about
the more complex case after we are done.
So do you see the rerun of try_to_simplify_commit() as acceptable? I'm
really not happy with it - it was fine for an initial proof-of-concept,
but it's an obvio
test, but it seems
>> that I was too greedy ;-)
> Thanks for the test addition. Maybe we will be able to satisfy your
> greed in this series. There could be more worth doing here, and I
> think getting TREESAME precise is key.
It is perfectly fine to do things one step at a time. Let
On 25/04/2013 04:59, Junio C Hamano wrote:
Junio C Hamano writes:
So, given all that, revised patch below:
I tried to squeeze the minimum test I sent $gmane/220919 to the test
suite. I think the "do not use --parents option for this test"
switch needs to be cleaned up a bit more, but it fail
note D &&
- test_tick && git merge -m "merge" master &&
+ test_tick &&
+ test_must_fail git merge -m "merge" master &&
+ >lost && git commit -a -m "merge" &&
note E &&
Kevin Bracey writes:
> If simplify_history is set, and we do want ancestry, then it doesn't
> matter about the TREESAME definition because it shows all merges,
> regardless of the TREESAME flag. Thus adding "--parents" to the above
> command means it can find it, but only because it drags _every_
and !simplify_merges, which
> would cover --full-history, but I am not sure if requiring
> !simplify_merges is correct.
You're right, it isn't correct. Logically, the test should be for
simplify_history. The original patch was overly cautious about
limiting it to --full-history. A
+
> + if (!revs->simplify_history && !revs->simplify_merges)
> + return;
So in addition to "have some change and there is no same parent"
case, under _some_ condition we avoid marking a merge not worth
showing (i.e. TREESAME) if there is any
ot;-s ours", then:
git log -m -p --full-history -Schange file
would successfully locate "change"'s addition but would not locate the
merge that resolved against it.
This patch changes the simplification so that when --full-history is
specified, a merge is treated as TREESAME
ess to the
server. In fact it would be using rsync, (which can be resumed)
clone from the rsynced copy and thenmanually change the url of origin.
Problem 2: Full history but only required data
---
Very often I would only need a few versions (some br
Hi,
I can publish the stuff on monday from a university nearby.
---
total blob objects = 228384
total tree objects = 172507
total commit objects = 55877
The "empty" changesets which are noting merges are omitted at the
moment. Is it of interest to include them ??
It might also be interes
27 matches
Mail list logo
