On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson
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 first is the master of
n.
On Mon, Dec 2, 2013 at 5:03 PM, Matěj Cepl 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 w
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 wrote:
> Hi,
>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
oblem that sometimes
occurs when git-svn pulls merges back from SVN.
jon.
On Wed, Jul 31, 2013 at 8:14 PM, Jon Seymour 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-b
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 ^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 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 lo
On Fri, Sep 28, 2012 at 2:58 PM, Jon Seymour 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
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 b
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
Ack - sorry I didn't notice that side effect.
jon.
-
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
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
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
> This series contains a big fix, but assumes the tidy ups above have
> been applied:
That'd be a _bug_ fix
jon.
-
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
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(-)
8238686fd422959dae50a908b3761aa545be1c4
Uncommented a test case that shows a --topo-order, --max-age break.
A subsequent patch witll fix this defect
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6003-rev-list-topo-order.sh | 20 ++--
1 files changed, 10 insertions(+), 10 del
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, repla
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
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 del
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
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
.
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 del
This invariant 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 n
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 +-
e
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 chan
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 <[EM
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 t
--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
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-b
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
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 chang
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
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 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/e
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-mer
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-
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] Tempora
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/e
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 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
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 intr
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
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 <[EM
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 +-
e
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 chan
This invariant 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 n
--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
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-b
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
> brea
On 7/6/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> PB> Any reason why this was not applied? It appears kind of cool.
>
> FYI, the one in <[EMAIL PROTECTED]> is
> newer than what you quoted.
>
> One thing _I_ am unhappy about what it d
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
I ack the patch, though --show-breaks could use the same treatment.
jon.
On 7/5/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> The --merge-order flag does not take parameter so there is no
> point doing strncmp with the length.
>
> Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
> ---
>
> r
unchanged from
the immediately preceding behaviour for non --merge-order sorts).
The order in which arguments are presented to the merge-order
sort algorithm is significant, since left-most arguments
are expected to sort last so as to be consistent with
how left-most parents sort.
Signed-off-by: Jon
This patch fixes up the t/t5300 unit tests which were broken by the changes in:
Make the name of a pack-file depend on the objects packed there-in.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t5300-pack-object.sh | 30 +++---
1 files chang
> >
> > >From the point of view of a specification, though, I think it would be
> > useful to focus on an XML content model rather than the details of one
> > particular HTML model - get the XML model right and you can do
> > whatever you like with the HTML model at any time after that.
>
> Actuall
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:
> > >
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 mat
On 4/22/05, lode leroy <[EMAIL PROTECTED]> wrote:
> I wonder if anyone is interested in using git on windows / cygwin.
> It almost compiles out of the box... just this one little thinggy
> that's glibc-specific (struct dirent . d_type)
>
I wonder if a cygwin compile of GIT should be forced to st
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 ni
> 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.
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 n
> 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 learn
On 19 Apr 2005 08:31:42 +0300, Marc Girod <[EMAIL PROTECTED]> wrote:
> > "KS" == Kevin Smith <[EMAIL PROTECTED]> writes:
>
> KS> "what's so special about files ?" where the author suggests that
> KS> existing SCM systems are so blinded by the tradition of file
> KS> orientation that they can't
63 matches
Mail list logo
