On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon Freeman wrote:
Hello guys, im Gordon.
I have a question about workflow with git that i dont know if im doing
it right.
I have 1 repo with 2 branchs the
, Dec 2, 2013 at 5:03 PM, Matěj Cepl mc...@redhat.com wrote:
On 30/11/13 09:54, Jon Seymour wrote:
I have seen this behaviour, though never determined the root cause
.Probably the simplest thing you can do without access to the server
is to put your git svn fetch into a bash while loop, like so
From the perspective of topic there had been no change to the
definition of bar(), hence there was no change to contribute to the
eventual merge with master.
One way to avoid this kind of problem is to avoid making (or
cherry-picking) the same change on different branches, but instead use
a merge
I have seen this behaviour, though never determined the root cause
.Probably the simplest thing you can do without access to the server
is to put your git svn fetch into a bash while loop, like so:
while ! git svn fetch; do :; done;
jon
On Sat, Nov 30, 2013 at 10:14 AM, Matěj Cepl
I am getting some unexpected results from a merge and I'd like to
understand why.
I have two commits X and Y that I want to merge.
git merge-base X Y # yields B
git diff B X -- F # is empty
git diff B Y -- F # contains the change I want merged
git rev-list X ^B -- F # is empty
git rev-list Y
that sometimes
occurs when git-svn pulls merges back from SVN.
jon.
On Wed, Jul 31, 2013 at 8:14 PM, Jon Seymour jon.seym...@gmail.com wrote:
I am getting some unexpected results from a merge and I'd like to
understand why.
I have two commits X and Y that I want to merge.
git merge-base X Y # yields B
Ah, answering my own question
I can see git svn reset does exactly what I need.
jon.
On Mon, Mar 18, 2013 at 4:03 PM, Jon Seymour jon.seym...@gmail.com wrote:
G'day,
I managed to lose sync between the git-svn repo that I am using to
track an svn repo. In particular, the git-svn repo
On Fri, Sep 28, 2012 at 2:58 PM, Jon Seymour jon.seym...@gmail.com wrote:
G'day
An svn developer created a branch from a subdirectory of the trunk
rather than by copying trunk itself.
I want to avoid pulling this branch into my git repo with git svn
fetch because the re-rooting pulls in too
G'day Junio,
Jon, do we really need bignum to do the flow computation? From
a quick glance, it appears to me that the fraction manipulation
part is quite well isolated. Do you think adding the support
for using other bignum implementation be reasonable (assuming
you do need to use bignum
This seems reasonable to me. I have thought this would be useful on
several occasions and haven't yet conceived of a counterexample where
it would break something.
On 7/11/05, Junio C Hamano [EMAIL PROTECTED] wrote:
When we allow a tag object in place of a commit object, we only
dereferenced
of --merge-order can be maintained.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Paul, could you review this patch and if you agree, ack it.
The rationale for changing gitk to use --topo-order is that git-rev-list will
produce the same order for --topo-order irrespective of the order of the
start list
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b = ord(b) ord(a)
Signed-off-by: Jon
is weaker than the --merge-order invariant, but is cheaper
to calculate (assuming the list has been identified) and will serve any
purpose where only a minimal topological order guarantee is required.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Note: this patch currently has no observable
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |5 -
1 files changed, 4
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c |8
commit.h |6 +-
epoch.c
of the code.
This change also makes --show-breaks imply --merge-order rather than require
it as before. There was no advantage to the previous strict argument
checking.
A subsequent change will take advantage of this pattern to introduce a
topological sort switch.
Signed-off-by: Jon Seymour [EMAIL
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad thing
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
This patch series introduces tests
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755 t/t6002
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen [EMAIL PROTECTED]
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
I've applied this to the code
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
This patch is known designed to apply on top of:
[PATCH 1/6] Temporary fixup
This patch passes the test case in the first patch of this series.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
e4f793b932b30a7bee16610e311630515fe88330
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -612,7
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6000-lib.sh
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
The problem is fixed by a subsequent patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6001-rev-list-merge-order.sh
This patch passes the test case introduced by the previous patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
6f7f90901ec4aafd12ac4179110b78fc426395cd
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -612,7
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen [EMAIL PROTECTED]
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
I've applied this to the code
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad thing
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755 t/t6002
git-rev-list --topo-order HEAD HEAD
caused a segmentation violation.
This has now been fixed.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c | 15 +++
commit.h |3 +++
epoch.h| 13 ++---
rev-list.c |8
4 files changed, 24
of --merge-order can be maintained.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Paul, could you review this patch and if you agree, ack it.
The rationale for changing gitk to use --topo-order is that git-rev-list will
produce the same order for --topo-order irrespective of the order of the
start list
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b = ord(b) ord(a)
Signed-off-by: Jon
I have re-issued the patches I have created in the last day after checking
that they apply correctly when applied in this order to the
current Linus HEAD (b43d44779bf98977b211256f936d0edda8a9625a)
Introduction of --topo-order and tidy up of rev-list.c
[PATCH 1/13] Temporary fixup to rev-list.c
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |5 -
1 files changed, 4
of the code.
This change also makes --show-breaks imply --merge-order rather than require
it as before. There was no advantage to the previous strict argument
checking.
A subsequent change will take advantage of this pattern to introduce a
topological sort switch.
Signed-off-by: Jon Seymour [EMAIL
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
commit.c |8
commit.h |6 +-
epoch.c
.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
t/t6000-lib.sh | 12 +++-
t/t6001-rev-list-merge-order.sh |9 -
t/t6002-rev-list-bisect.sh | 10 --
t/t6003-rev-list-topo-order.sh |9 -
4 files changed, 7 insertions(+), 33 deletions
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: the last test fails with --topo-order at the moment. I haven't
seen your most recent changes, so it may still fail for trivial
reasons even then. If so, I'll post an update.
t/t6003-rev-list-topo-order.sh | 417
This change ensures that git-rev-list --merge-order produces the same result
irrespective of what position the --merge-order argument appears in the argument
list.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
Linus: if you'd prefer to fix this a different way, that's fine by me!
---
rev
Now that duplicates are elided early, there is no need for the
SHOWN flag.
This patch removes the SHOWN flag and its uses from rev-list.c
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |4 +---
1 files changed, 1 insertions(+), 3 deletions
that one and, for completeness,
BOUNDARY and DISCONTINUITY too.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
epoch.c| 14 --
epoch.h|4 +---
rev-list.c |5 ++---
3 files changed, 11 insertions(+), 12 deletions(-)
54a391ba7e4f96ce08ecb7da82941519b8a14c30
diff --git
Since --merge-order is the only thing that cares about the rev-list
parse order, change the rev-list list to match the parse order
and remove the corresponding compensating reversal from epoch.c.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
[PATCH] Move SEEN flag into epoch.h, replace use
Applied the --merge-order, --max-age fix to fix
the --topo-order problem demonstrated by the test
case in the previous patch.
Signed-off-by: Jon Seymour [EMAIL PROTECTED]
---
rev-list.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8238686fd422959dae50a908b3761aa545be1c4f
diff
Hi,
I've recently posted the following patches, in this order:
These ones are tidy ups:
[PATCH] Remove use of SHOWN flag
[PATCH] Move SEEN flag into epoch.h, replace use of VISITED flag with SEEN flag
[PATCH] Simplification - remove unnecessary list reversal from epoch.c
This series contains a
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/5/05, Petr Baudis [EMAIL PROTECTED] wrote:
Any reason why this was not applied? It appears kind of cool. Well, I
will probably take it and extend cg-mkpatch with it so I don't need it
in Git, but I'm so altruistic and want to bring at least a bit of light
to the gloomy dark world of the
G'day Linus,
Is there some reason why this didn't get applied?
jon.
On 7/5/05, Jon Seymour [EMAIL PROTECTED] wrote:
A recent change to rev-list altered the order in which start points
are presented to the merge-order sort algorithm. This caused
breaks in the t/t6001 unit tests
On 4/22/05, Christian Meder [EMAIL PROTECTED] wrote:
Comments ? Ideas ? Other feedback ?
I'd suggest serving XML rather than HTML and using client side XSLT to
transform it into HTML. Client-side XSLT works well in IE 6 and all
versions of Firefox, so there is no question that it is a mature
On 4/22/05, Petr Baudis [EMAIL PROTECTED] wrote:
Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
where Jon Seymour [EMAIL PROTECTED] told me that...
On 4/22/05, Christian Meder [EMAIL PROTECTED] wrote:
Comments ? Ideas ? Other feedback ?
I'd suggest serving XML
On 4/21/05, Kay Sievers [EMAIL PROTECTED] wrote:
On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote:
It's working now:
http://ehlo.org/~kay/gitweb.pl
Kay + Christian + Ken,
That looks really great!.
One suggestion: when drilling down through the tree it would be nice
if
On 4/20/05, Linus Torvalds [EMAIL PROTECTED] wrote:
I converted my git archives (kernel and git itself) to do the SHA1 hash
_before_ the compression phase.
Linus,
Am I correct to understand that with this change, all the objects in
the database are still being compressed (so no net
The main point is not about trying different compression
techniques but that you don't need to compress at all just
to calculate the hash of some data. (to know if it is
unchanged for example)
Ah, ok, I didn't understand that there were extra compresses being
performed for that reason.
I disagree. This already forces you to have two branches (one to pull
from to get the data, mirroring the remote branch, one for your real
work) uselessly and needlessly.
...
These naming issues may appear silly but I think they matter big time
for usability, intuitiveness, and learning
52 matches
Mail list logo
