Junio C Hamano gits...@pobox.com 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 option to let
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.version-control.git/89400/focus=90659
Ævar Arnfjörð Bjarmason ava...@gmail.com 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-log(1) and in
http
On Wed, Aug 5, 2015 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com 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
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.conf option
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
A' -- file
check_result 'I B A' --topo-order -- file
check_result 'H' --first-parent -- another-file
+check_result 'E C B A' --full-history E -- lost
+test_expect_success 'full history simplification without parent' '
+ printf %s\n E C B A expect
+ git log --pretty=$FMT --full-history E
a 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, leaving it as a normal commit marked
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi 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
Kevin Bracey ke...@bracey.fi writes:
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi 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
Kevin Bracey ke...@bracey.fi 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 ==
A' -- file
check_result 'I B A' --topo-order -- file
check_result 'H' --first-parent -- another-file
+check_result 'E C B A' --full-history E -- lost
+test_expect_success 'full history simplification without parent' '
+ printf %s\n E C B A expect
+ git log --pretty=$FMT --full-history E
a 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, leaving it as a normal commit marked
A' -- file
check_result 'I B A' --topo-order -- file
check_result 'H' --first-parent -- another-file
+check_result 'E C B A' --full-history E -- lost
+test_expect_success 'full history simplification without parent' '
+ printf %s\n E C B A expect
+ git log --pretty=$FMT --full-history E
a 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, leaving it as a normal commit marked
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
On 25/04/2013 04:59, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
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's get
the --full-history change into a good shape first and worry about
the more complex
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 acceptable? I'm
really not happy with it - it was fine for an initial proof-of-concept,
but it's an obvious
.
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 acceptable? I'm
really not happy with it - it was fine
Kevin Bracey ke...@bracey.fi 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
merge
note E
echo Yet another elif
@@ -110,4 +115,16 @@ check_result 'I B A' -- file
check_result 'I B A' --topo-order -- file
check_result 'H' --first-parent -- another-file
+check_result 'E C B A' --full-history E -- lost
+test_expect_success 'full history simplification
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. And it avoided breaking a test -
specifically t6016.7
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 only if it is TREESAME
)
+ 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 change.
And the condition is !simplify_history and !simplify_merges, which
would cover --full-history, but I am
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 branch heads
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
27 matches
Mail list logo
